3 Workbench 3.9 issues never fixed

hexaae · 08 July 2018, 11:57

Some Workbench bugs, in 2018:

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)
RAD: supports max 30 chars file names (annoying ancient limitation…)
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?

kolla · 09 July 2018, 00:55

1. Did you update ram-handler?
2. Did you change filesystem for RAD?

Thomas Richter aka ThoR is the one fixing most bugs.

hexaae · 09 July 2018, 01:32

1. yep, 44.23
2. do you have an example of alternative RAD mountlist with another fs?

PeterK · 09 July 2018, 01:54

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?

hexaae · 09 July 2018, 08:52

@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...

DamienD · 09 July 2018, 10:55

Quote:

Originally Posted by PeterK

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

PeterK · 09 July 2018, 10:56

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.

hexaae · 09 July 2018, 11:16

Quote:

Originally Posted by DamienD

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

PeterK · 09 July 2018, 11:49

Updated my previous post.

hexaae · 09 July 2018, 11:50

Bingo! :P

PeterK · 09 July 2018, 12:14

Same crash with amber-ram-handler.

gulliver · 09 July 2018, 14:08

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.

hexaae · 09 July 2018, 14:58

@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?

gulliver · 09 July 2018, 20:14

@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

hexaae · 09 July 2018, 20:30

Great news in the way….

kolla · 10 July 2018, 10:56

NDA, huh? Good grief *big roll eyes*

PeterK · 10 July 2018, 18:09

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.

hexaae · 10 July 2018, 20:00

Works fine now, confirmed! Nice reverse engineering

PeterK · 10 July 2018, 23:39

Quote:

Originally Posted by hexaae

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.

hexaae · 11 July 2018, 03:35

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.

08 July 2018, 11:57	#1
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	3 Workbench 3.9 issues never fixed Some Workbench bugs, in 2018: 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) RAD: supports max 30 chars file names (annoying ancient limitation…) 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?

09 July 2018, 01:54	#4
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	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 02:50.

09 July 2018, 10:56	#7
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	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 Last edited by PeterK; 09 July 2018 at 11:48.

09 July 2018, 14:58	#13
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	@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 15:04.

10 July 2018, 18:09	#17
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	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 08:00.

09 July 2018, 00:55	#2
kolla Banned Join Date: Nov 2007 Location: Trondheim, Norway Posts: 1,893	1. Did you update ram-handler? 2. Did you change filesystem for RAD? Thomas Richter aka ThoR is the one fixing most bugs.

09 July 2018, 01:32	#3
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	1. yep, 44.23 2. do you have an example of alternative RAD mountlist with another fs?

09 July 2018, 08:52	#5
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	@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 10:35. Reason: repro steps

09 July 2018, 11:49	#9
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Updated my previous post.

09 July 2018, 11:50	#10
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	Bingo! :P

09 July 2018, 12:14	#11
PeterK Registered User Join Date: Apr 2005 Location: digital hell, Germany, after 1984, but worse Posts: 3,365	Same crash with amber-ram-handler.

09 July 2018, 14:08	#12
gulliver BoingBagged Join Date: Aug 2007 Location: The South of nowhere Age: 46 Posts: 2,358	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.

09 July 2018, 20:14	#14
gulliver BoingBagged Join Date: Aug 2007 Location: The South of nowhere Age: 46 Posts: 2,358	@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

09 July 2018, 20:30	#15
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	Great news in the way….

10 July 2018, 10:56	#16
kolla Banned Join Date: Nov 2007 Location: Trondheim, Norway Posts: 1,893	NDA, huh? Good grief big roll eyes

10 July 2018, 20:00	#18
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	Works fine now, confirmed! Nice reverse engineering

11 July 2018, 03:35	#20
hexaae Bug hunter Join Date: Jul 2006 Location: Italy Age: 48 Posts: 2,161	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.

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

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