3 Workbench 3.9 issues never fixed

[gulliver]

Thank you both hexaae and PeterK.
Bug and proposed solution has been reported to the dev team.

If anyone else wishes to report any other unknown bug, now it is the time to do it, as I can relay them back to the AmigaOS 3.1.4 devs.

[PeterK]

@hexaae
What has happened to my little CopyFix on the way to Aminet ?

Instead of the freely distributable spatch from SAS/C it now comes with a WPatch utility which has nothing to do with WPatch.lha on Aminet as stated.

The creation date of the new Copy 40.2 command is now suddenly (9.7.18) and not (10.7.18). This is a fake of facts!

The CopyUpdate script has a "FailAt 1" instruction in the 1. line which makes the "If WARN" construction pretty useless, and the output window is closed on failure after a short delay instead of waiting for the user to read the message and close it. - The readme has no icon and default tool.

... but at least it should still work. Never mind, it's out now and that's alright.

[hexaae]

http://aminet.net/package/util/cli/WDelta ouch… listed wrong archive… Will contact Aminet admins.

Yes, I preferred to reduce hex-editing and keep $VER: string spacing, 1 day before it's not a problem
Yep, was done a bit in a hurry. FailAt 1 was required in case WPatch can't patch mismatching C:Copy as I've experienced testing (returns $RC = 3 instead of usual 5+)... even though at that point if warn was useless.
Forgot to add WINDOW=CON://///WAIT/CLOSE at the end. Noticed the moment after I already uploaded it!

I can update it to 1.1 but hey… installation does work fine also like this even if a bit rough

[PeterK]

Originally Posted by hexaae

http://aminet.net/package/util/cli/WDelta ouch… listed wrong archive… Will contact Aminet admins.

Yes, I preferred to reduce hex-editing and keep $VER: string spacing, 1 day before it's not a problem

Yes, WDelta fits better to your WPatch. Was there a problem with the missing space after the $VER:? Usually, it's suppressed anyway by the version command and you can only see the remaining string.

Wait for the reaction of the users who may get confused when finding two versions of Copy v40.2 with different dates in the net and will ask you which one to install now.

...
I can update it to 1.1 but hey… installation does work fine also like this even if a bit rough

No, not required, I just want to have fun ...

[hexaae]

LOL, did you already share it? Remove link please, let's keep the Aminet version only

Okay, okay, just reupped fixed 1.1 version LOL

[PeterK]

Ok, I've killed my baby ...

[hexaae]

As a proud Amiga user I've upped it using AmFTP from AmigaOS… eh eh
Having fun in this Amiga Retro Summer for me!

[PeterK]

layers.library: Can you provide a sample guide so I can test this bug?

Found the reason for the AmigaGuide (i.e. MMU.guide) window resizing freezes now:

It only happens when VisualPrefs and ThoR's layers.library and his rtg.library are coming together. If one of these 3 components is missing, everything works fine. I already played with some ENV:VisualPrefs variables like SaftyLevel=2, MinStackSize=3000 and Special=0x020 for a different Semaphore handling, but it didn't fix the freezes yet.

PS: Btw, what is the CD "" good for? The CopyUpdate script also works without it. But the CopyFix is okay now.

[hexaae]

Originally Posted by PeterK

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.

Mmmh, today I tried to patch only one instance of the two AllocVec() and works fine as well with >83 filenames. Better minimal changes to avoid potential mem-leaks?

[PeterK]

Originally Posted by hexaae

Mmmh, today I tried to patch only one instance of the two AllocVec() and works fine as well with >83 filenames. Better minimal changes to avoid potential mem-leaks?

Do you know how AllocVec() and FreeVec() are working? No ... ?

AllocVec() adds 4 bytes to the requested size and sends it together with the attributes to AllocMem(). When it gets the memblock from AllocMem() it stores the size in the first longword and then returns the address of the second longword as result of the function call.

FreeVec() takes the address of the memblock, subtracts 4 bytes and reads the full size from the first longword before it passes this to FreeMem(). So, the program never has to keep track of the memblock size.

I guess, these two buffers are for the input and output strings. Not every buffer overflow causes a trashing in critical memory areas. Did you check your new copy at least with MungWall or WipeOut or other debugging tools? I would not change anything in the CopyFix now. ThoR could do that for OS 3.1.4. And I'm too lazy to examine the Copy code further. I'm busy with a new feature for icon.library.

[DamienD]

Originally Posted by PeterK

Did you check your new copy at least with MungWall or WipeOut or other debugging tools?

...that would require hexaae to test / click at least over 100 times to prove it's a "real" bug on his system

[PeterK]

No, that might not work. I fear hexaae is figthing with a phantom bug now. That's the the worst sort, you can never catch them ...

[hexaae]

Originally Posted by PeterK

Do you know how AllocVec() and FreeVec() are working? No ... ?

No, I'm not a programmer and forgot a lot of things about AmigaOS after all these years

AllocVec() adds 4 bytes to the requested size and sends it together with the attributes to AllocMem(). When it gets the memblock from AllocMem() it stores the size in the first longword and then returns the address of the second longword as result of the function call.

FreeVec() takes the address of the memblock, subtracts 4 bytes and reads the full size from the first longword before it passes this to FreeMem(). So, the program never has to keep track of the memblock size.

Nice. Exactly what I hoped for, thank you for your explanation

I guess, these two buffers are for the input and output strings. Not every buffer overflow causes a trashing in critical memory areas. Did you check your new copy at least with MungWall or WipeOut or other debugging tools? I would not change anything in the CopyFix now. ThoR could do that for OS 3.1.4. And I'm too lazy to examine the Copy code further. I'm busy with a new feature for icon.library.

I had some spare time and just wanted to experiment that...
The single patch seems to work fine for me from WinUAE with 060+MMU and MuForce + MuGuardianAngel (are them reliable under WinUAE?):

As you explained above there is no need to update the patch on Aminet anyway.

[kolla]

Originally Posted by PeterK

I'm busy with a new feature for icon.library.

Wohoo!

[PeterK]

Don't know how good the MuTools are, because I never use the MMU, but I would expect them to do their job even on a WinUAE system.

On the other side, I can't see what could go wrong with a larger buffer, except that it would waste a few bytes of extra memory if it doesn't help. My suspicion is that two buffers with the same size may have similar tasks.

[PeterK]

Originally Posted by kolla

Wohoo!

Just started with it today, but I don't tell you what it is before it is done.

[hexaae]

Originally Posted by PeterK

Found the reason for the AmigaGuide (i.e. MMU.guide) window resizing freezes now:

It only happens when VisualPrefs and ThoR's layers.library and his rtg.library are coming together. If one of these 3 components is missing, everything works fine. I already played with some ENV:VisualPrefs variables like SaftyLevel=2, MinStackSize=3000 and Special=0x020 for a different Semaphore handling, but it didn't fix the freezes yet.

Can't reproduce it here…

[8.Workbench:] ver sys:Classes/DataTypes/amigaguide.datatype
amigaguide 45.6 ( 7-Settembre-01)
[8.Workbench:] ver LIBS:datatypes.library
datatypes.library 44.47 (25-Dicembre-99)
[8.Workbench:] ver sys:Utilities/MultiView
MultiView 45.9 (18-Gennaio-02)
[8.Workbench:] ver LIBS:layers.library
layers.library 45.27 (12-Dicembre-14)
[8.Workbench:] ver LIBS:Picasso96/rtg.library
rtg.library 40.4029 (26-Ottobre-14)
©1991-99 A.Kneer T.Abt


P.S.
ThoR found the reason behind UFO incompatibility with layers.library 45.27 and sent me a patch for InstallClipRegion()

[AMIGASYSTEM]

Originally Posted by hexaae

Can't reproduce it here…

[8.Workbench:] ver sys:Utilities/MultiView
MultiView 45.9 (18-Gennaio-02)

Exists MultiView 45.10 - 2004 and MultiView 1.4 - 2011