English Amiga Board


Go Back   English Amiga Board > Support > support.Apps

 
 
Thread Tools
Old 08 July 2018, 12:57   #1
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,118
3 Workbench 3.9 issues never fixed

Some Workbench bugs, in 2018:
  1. C:Copy 40.1 crashes copying in RAM: files >83 chars (using PFS3 or SFS that have 107 char limit, or from a shared Windows dir in WinUAE)
  2. RAD: supports max 30 chars file names (annoying ancient limitation…)
  3. text.datatype 45.14 (and all previous 44-45, except original 40.3) is buggy and won't properly display Underlined text (e.g. see my edited Banshee docs, Pick Ups section, scroll in Multiview up/down)
...so, I wonder if there are still some active programmers that could be interested in patching and fixing these issues once and for all, for a modern and smooth WB3.9 everyday use.
In the good old days I can remember programmers fixing these kind of bugs like Flavio Stanchina (see Aminet)… Is there someone still "active", interested in fixing OS bugs?
hexaae is offline  
Old 09 July 2018, 01:55   #2
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 1,567
1. Did you update ram-handler?
2. Did you change filesystem for RAD?

Thomas Richter aka ThoR is the one fixing most bugs.
kolla is offline  
Old 09 July 2018, 02:32   #3
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,118
1. yep, 44.23
2. do you have an example of alternative RAD mountlist with another fs?
hexaae is offline  
Old 09 July 2018, 02:54   #4
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,407
It seems that all these little bugs really like you and feel happy on your system.

I don't know if it helps but there is a copy replacement written by Dirk Stoecker. You could try that. http://aminet.net/package/util/sys/CopyReplace

Usually, the maximal name length is more a filesystem limitation. The DOS fileinfoblock has a limit of 107 characters + Null. You need "DOS\6" or "DOS\7" for 107 characters, all older versions are limited to 30 characters.

Try amber-ram-handler http://aminet.net/package/util/sys/AmberRAM
I have no problems with the Amber RamDisk and the normal Copy v40.1 with up to 107 chars. Copied a file from Windows to RAM: and back to another Windows dir. Or should I copy it 100+ times to get a crash? For icon support you need WBCTRL MNL=102.

3. could also be a console window (KingCon) refresh problem, but who needs underlined text?

Last edited by PeterK; 09 July 2018 at 03:50.
PeterK is offline  
Old 09 July 2018, 09:52   #5
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,118
@PeterK
Thanks for checking.
Did you try on a clean BB2 3.9 installation, with 040-060 (no MMU), and P96 Z3 RTG?
Will check out in different config modes if you say you can't reproduce the Copy to RAM: exec.library corruption on a clean system without patches/3rd party tools….

Please, try these exact steps:
(PFS3 or SFS partitions, WB3.9 BB2)
  • open a shell (I use KingCON, but I tried also with normal CON)
  • create a jpg or txt with a very long file name in your DH1
  • then "copy Work:t/239475-brian-the-lion-starring-in-rumble-in-the-jungle-amiga-front-cover78981234.jpg ram:" 2-3 times
  • then open RAM:, refresh contents, and double-click on "239475-brian-the-lion-starring-in-rumble-in-the-jungle-amiga-front-cover78981234.jpg" to open it…
I usually have a Sanity memory check error involving exec.library, or Memory header not located error caused by "CON" task, but only after using old Copy v40.1 with file names longer than 83 chars (including extension). Under 84 chars works fine. I will re-test it on a fresh 3.9BB2 install HDF, but I'm 99% sure...

Yes I'm currently using that CopyReplace, that doesn't make system crash (this is a clue to me).

As for AmberRam I know it, but can't see a real advantage in using it… and don't like the "volume full never displayed" misfeature.

The text.datatype is a known bug. Was also fixed in some previous "add search feature to text dt" patches on Aminet in the past, but ignored with v44-45 release… Only v40.3 is 100% reliable with ESC formatting codes visualization, which is a pity since 45.14 has some useful mark+search features built-in working also from simple Multiview's menu (!). Would be great a small patch-fix.

EDIT:
Checked the old Copy to RAM: on 020 no FPU and still being able to reproduce it...

Last edited by hexaae; 09 July 2018 at 11:35. Reason: repro steps
hexaae is offline  
Old 09 July 2018, 11:55   #6
DamienD
Global Moderator

DamienD's Avatar
 
Join Date: Aug 2005
Location: London / Sydney
Age: 42
Posts: 12,807
Quote:
Originally Posted by PeterK View Post
It seems that all these little bugs really like you and feel happy on your system.

<snip>

Or should I copy it 100+ times to get a crash?
Reply of the day!!! Hahahahaha

...sorry hexaae, burst into laughter when I read PeterK's post, couldn't help it
DamienD is offline  
Old 09 July 2018, 11:56   #7
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,407
Now, I tried to copy to and from the original OS 3.9 RamDisk (no amber-ram-handler) and some Windows Temp dirs on the other side.

No problems with my 68020 configuration. Not even with a 68040 CPU concerning the copying, but I opened the shell window (KingCon) to full screen size (1280x800) and after the window was filled with lots of copy instructions I tried to scroll it. No problem on my 68020, but just garbage text with the 68040.

Sorry, I don't use any FFS, PFS3, SFS or other filesystems, just WinUAE on Windows directories. I don' like HDFs.

Also copied the screenshot PNG file with a long name (102 chars) from Windows to RAM:.
Very stange: When the last characters were "...78.png" there was no problem with the copying and displaying the PNG, but when the name ends with "...789012" I had a memory corruption and crashes during the copying, even with 68020.
Attached Thumbnails
Click image for larger version

Name:	CopyTest.png
Views:	86
Size:	33.6 KB
ID:	58771  

Last edited by PeterK; 09 July 2018 at 12:48.
PeterK is offline  
Old 09 July 2018, 12:16   #8
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,118
Quote:
Originally Posted by DamienD View Post
Reply of the day!!! Hahahahaha

...sorry hexaae, burst into laughter when I read PeterK's post, couldn't help it
Don't worry, I don't care: when I report bugs, 99% are proven real in the end but there are many variables, so I'm used to report things others can't find… It's always just a matter of time to understand WHERE is the problem for me, eh eh eh

Will deep test also this strange case… be sure

Last edited by hexaae; 09 July 2018 at 12:49.
hexaae is offline  
Old 09 July 2018, 12:49   #9
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,407
Updated my previous post.
PeterK is offline  
Old 09 July 2018, 12:50   #10
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,118
Bingo! :P
hexaae is offline  
Old 09 July 2018, 13:14   #11
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,407
Same crash with amber-ram-handler.
PeterK is offline  
Old 09 July 2018, 15:08   #12
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 40
Posts: 1,745
Hi hexaae,

Please make a precise test case for issue number 1 (c:copy), and I will report the bug to AmigaOS 3.1.4 developers.

It could be very helpful if others could also confirm this issue.
gulliver is offline  
Old 09 July 2018, 15:58   #13
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,118
@gulliver
please, report also request for RAD: ramdrive.device limited to 30 chars filenames (unacceptable in 2018), and text.datatype 45.17 issue with ESC formatting controls and Underlined text which is a (minor) bug as well.

As written in msg #5:

Please, try these exact steps:
(PFS3 or SFS partitions for long file names, WB3.9 BB2)
  • open a shell (I use KingCON, but I tried also with normal CON)
  • create a jpg or txt with a very long file name in your DH1
  • then "copy Work:t/239475-brian-the-lion-starring-in-rumble-in-the-jungle-amiga-front-cover78981234.jpg ram:" 2-3 times (n.d.Hexaae: please, use this exact file name, the bug seems characters specific with the digits at the end of filename!)
  • then open RAM:, refresh contents, and double-click on "239475-brian-the-lion-starring-in-rumble-in-the-jungle-amiga-front-cover78981234.jpg" to open it…
I usually have a Sanity memory check error involving exec.library, or Memory header not located error caused by "CON" task, but only after using old Copy v40.1 with file names longer than 83 chars (including extension). Under 84 chars works fine and there is no mem corruption.

P.S.:
Is user 'thor' on EAB Thomas Richter?

Last edited by hexaae; 09 July 2018 at 16:04.
hexaae is offline  
Old 09 July 2018, 21:14   #14
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 40
Posts: 1,745
@hexaae

I cannot reveal any information due to NDA, which has not been already released by AmigaOS developers. So trust me when I say, the RAD issue you mentioned is not relevant right now.

Also keep in mind that AmigaOS 3.1.4 is an update and minor fix to 3.1, not 3.9. (so text.datatype 45.x is not part of it). I could personally argue about that the word "minor" seems a little bit unrealistic, as so many things have been fixed as it stands right now. I think of it as a 3.1 on steroids. But I digress.

PS: I suppose so. But he is really busy right now, that I wouldnt count on him reading any message.

----

To everyone else:

Please try to reproduce the c:copy bug hexaee mentions, so that we can discard false reports due to other hardware and/or software issues.

I am far away from home right now, and cant do any tests for a while.

Thanks
gulliver is offline  
Old 09 July 2018, 21:30   #15
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,118
Great news in the way….
hexaae is offline  
Old 10 July 2018, 11:56   #16
kolla
Registered User
kolla's Avatar
 
Join Date: Nov 2007
Location: Trondheim, Norway
Posts: 1,567
NDA, huh? Good grief *big roll eyes*
kolla is offline  
Old 10 July 2018, 19:09   #17
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,407
Could you please try out my CopyFix, hexaae. I'm not sure if it works reliable, but I found two AllocVec() instructions for 80 bytes and changed them to allocate 127 bytes now. I didn't check what the code is really doing with these buffers, but since you said the crashes start with 84 characters these buffer could be guilty. AllocVec() needs 4 additional bytes for storing the size and AllocMem() would round up this request to 88 bytes, which would give exactly 84 usable bytes (83 chars + Null) before a buffer overflow occurs. It seems to work now on my system, at least in a first quick test.

Last edited by PeterK; 14 July 2018 at 09:00.
PeterK is offline  
Old 10 July 2018, 21:00   #18
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,118
Works fine now, confirmed! Nice reverse engineering
hexaae is offline  
Old 11 July 2018, 00:39   #19
PeterK
Registered User
 
Join Date: Apr 2005
Location: Hangover
Posts: 2,407
Quote:
Originally Posted by hexaae View Post
text.datatype 45.14 (and all previous 44-45, except original 40.3) is buggy and won't properly display Underlined text ...
No, only 44.5 (by Sebastian Bauer) and 45.x are buggy, 40.3, 44.10 (OS 3.5 BB1) and 44.20 (OS 3.5 BB2) have still correct underlined text, but no marking or searching support. The changelog says that starting with 45.1 the text.datatype has been rewritten completely. In 40.3, 44.10 and 44.20 there are still some subroutines handling the "Esc[*m" sequences, but nothing like that in v45 anymore as far as I can see. Underlined text uses "Esc[4m". I can always make the underlining visible by moving a window over the text and back again, but then it doesn't stop the underling where it should end.

If you think that my CopyFix is working correctly, you can upload it to Aminet. I did only increase the size of these 2 buffers and updated the revision and date. The code is exactly the same as before.
PeterK is offline  
Old 11 July 2018, 04:35   #20
hexaae
Registered User
hexaae's Avatar
 
Join Date: Jul 2006
Location: Italy
Age: 42
Posts: 1,118
Yep, that's the problem 3.
Didn't test BB1 or BB2 versions, thanks for checking. The best would be having new v45 features AND perfectly working ESC formatting codes.

Ok I'll upload the CopyFix on Aminet in next couple of days.
hexaae is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Classic Workbench UAE Speed Issues jonesypeter project.ClassicWB 2 25 April 2017 23:06
well i have update my Workbench to Classic Workbench mcbone Amiga scene 0 02 May 2015 22:22
Amiga 1200 Workbench Issues/Fixes? Spyhunter support.Apps 21 15 September 2012 00:56
[FIXED] Xybots haynor666 HOL data problems 7 25 February 2004 04:56
[Fixed] little little error Marcuz HOL data problems 6 15 December 2002 15:24

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 07:27.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.09315 seconds with 14 queries