English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   support.Apps (http://eab.abime.net/forumdisplay.php?f=8)
-   -   3 Workbench 3.9 issues never fixed (http://eab.abime.net/showthread.php?t=93302)

hexaae 08 July 2018 12:57

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?

kolla 09 July 2018 01: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 02:32

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

PeterK 09 July 2018 02:54

It seems that all these little bugs really like you and feel happy on your system. :D

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 09: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 11:55

Quote:

Originally Posted by PeterK (Post 1253084)
It seems that all these little bugs really like you and feel happy on your system. :D

<snip>

Or should I copy it 100+ times to get a crash?

Reply of the day!!! Hahahahaha :lol :lol :lol

...sorry hexaae, burst into laughter when I read PeterK's post, couldn't help it :cheese

PeterK 09 July 2018 11:56

1 Attachment(s)
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 12:16

Quote:

Originally Posted by DamienD (Post 1253147)
Reply of the day!!! Hahahahaha :lol :lol :lol

...sorry hexaae, burst into laughter when I read PeterK's post, couldn't help it :cheese

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 12:49

Updated my previous post.

hexaae 09 July 2018 12:50

Bingo! :P

PeterK 09 July 2018 13:14

Same crash with amber-ram-handler.

gulliver 09 July 2018 15: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 15: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 21: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 21:30

Great news in the way…. :D

kolla 10 July 2018 11:56

NDA, huh? Good grief *big roll eyes*

PeterK 10 July 2018 19: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 21:00

Works fine now, confirmed! Nice reverse engineering :)

PeterK 11 July 2018 00:39

Quote:

Originally Posted by hexaae (Post 1252913)
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 04: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.


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

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.

Page generated in 0.05690 seconds with 11 queries