AmigaOS 3.2 released!

[mfilos]

Yeah but it's not right.
It's awesome that we have these options now, but they need to be done correctly with some minor alterations in order to stop using "dirty" hacks and patches.

[ShK]

I know that CD32 kickrom is experimental but just FYI, when I tested in WinUAE 4.10 with the default CD32 kick (40.60) vs booting from the ModulesCD32_3.2.1.adf, I can see that first row of VideoCD menu title is partially lost with the kick 3.2.1. CD32 is with the Full Motion Video cartridge to play VideoCDs.

[mfilos]

One more question concerning MakeLink command (as I haven't managed to find a reference for that).

I noticed that the comments of the file linked (TO) aren't transferred to the linked file (FROM).
Is that a normal behavior? It would be nice to have the comments of a file as well to the linked file.

[Olaf Barthel]

Originally Posted by mfilos

One more question concerning MakeLink command (as I haven't managed to find a reference for that).

I noticed that the comments of the file linked (TO) aren't transferred to the linked file (FROM).
Is that a normal behavior? It would be nice to have the comments of a file as well to the linked file.

This could be a bug, but it could also be a limitation of the respective file system implementation. For example, ram-handler's handling of hard link metadata prior to AmigaOS 3.1.4 was somewhat inconsistent. For some operations the metadata of the original directory entry was used, for others it was not the case.

This is a knotty problem, if you will: should the hard link and the original directory entry share the same comment, protection flags and modification time or should they be permitted to diverge? What if you change the modification time of the hard link - should the original follow or stay? If you change the original modification time, should the hard link(s) follow?

[mfilos]

Imho, they hardlinks and the actual file should have the same comments/protection flags and timestamps as from what I understand they are like Linux's symbolic links alas a pointer to the actual file.
If the actual file changes or the hardlink changes all changes should imho be represented in both original file and link.

[robinsonb5]

Originally Posted by Olaf Barthel

This is a knotty problem, if you will: should the hard link and the original directory entry share the same comment, protection flags and modification time or should they be permitted to diverge? What if you change the modification time of the hard link - should the original follow or stay? If you change the original modification time, should the hard link(s) follow?

I'd argue that there are two types of data related to a file:
The file's location, the protection bits and file comments fall into one category, so I think these should ideally be allowed to diverge for hard links.


The modification time, however, relates to the file's actual contents, so should be shared between all linked instances of a file.

[Olaf Barthel]

Originally Posted by mfilos

Imho, they hardlinks and the actual file should have the same comments/protection flags and timestamps as from what I understand they are like Linux's symbolic links alas a pointer to the actual file.
If the actual file changes or the hardlink changes all changes should imho be represented in both original file and link.

No, this is not how hard links work on AmigaDOS

What symbolic links accomplish in the Unix domain is implemented by soft links in AmigaDOS. When you access an AmigaDOS soft link, the dos.library will transparently translate the access to the target directory entry or volume (with the help of all the file systems involved).

Well, at least that's the theory because soft link resolution support was almost consistently unreliable in AmigaDOS 2 through 3.1. Which is why hard links saw much more frequent use. At least the file system itself knew where the hard link was pointing and could ensure that its data structures were wholly consistent.

This is why, depending upon the respective file system implementation, a hard link can have its own metadata attributes (name, protection flags, comment, modification time stamp) which may differ from the attributes of the original which the hard link references.

As I mentioned, whether the hard link metadata and the original directory entry metadata are allowed to differ (the name can always be different), depends upon the respective file system implementation.

[mfilos]

Thanks for the clarification Olaf. Definitely made things more clear.
I will comment HardLinks as well since link/actual file share different metadata. Just wanted to be sure what's the case, and if it was actual a bug or a feature

[Michael]

Originally Posted by wiser3

I've also noticed this. My solution of sometimes having a space where i don't want one is to add a space somewhere else so things look balanced. Result isn't how i want it to be but it looks better then having a space in an odd spot.

There is a simpler solution...


Just put your variable names in double quotes " "


eg. (%e "var")


This should do the trick, also with split name variables

[mfilos]

Originally Posted by Michael

There is a simpler solution...
Just put your variable names in double quotes " "
eg. (%e "var")
This should do the trick, also with split name variables

That was indeed a nice idea!
It worked like a charm \o/

[arti040]

I look through the all thread but did not find the answer. Was the issue with Exectutive resolved or it is still needed to add ramlib to exludes?

[shelter]

I'm a bit confused, I was going to do a test with shapeshifter.
However it says I need to run prepareemul first but according to the OS 3.2 FAQ it isn't needed?
I tried copying MuMove4k to c: then I added MuMove4K A1200 NoReboot PrepareEmul at the beginning of the startup-sequence and shapeshifter launcher at least starts now.

So why do I need MuMove4k? Is it because I have MMULib installed?

[daxb]

MacOS needs the first few kilobytes free/reserved. Shapeshifter comes with pepareemul to do the trick but there exists several other patches that do the same. If you are using OS3.2 than there is no need for prepareemul or others because it frees/allocate the first few kilobytes already. It might be possible that not each patch works for you for some reason. In your case there should no need for MuMove4k.

[shelter]

Well, that's what I'm saying, I need to run MuMove4k prepareemul in OS3.2 otherwise shapeshifter won't start at all.

[Thomas Richter]

Originally Posted by shelter

So why do I need MuMove4k? Is it because I have MMULib installed?

No, it's because Shapeshifter requires it, as silly as it sounds. ShapeShifter expects a "magic indicator" in the 32K MacOs "globals" that indicates that these 32K were actually released for Shapeshifter. MuMove4K just provides these magic values there. In principle, a small program would be needed just to deposit the values there.

[shelter]

Originally Posted by Thomas Richter

No, it's because Shapeshifter requires it, as silly as it sounds. ShapeShifter expects a "magic indicator" in the 32K MacOs "globals" that indicates that these 32K were actually released for Shapeshifter. MuMove4K just provides these magic values there. In principle, a small program would be needed just to deposit the values there.

Well that explains it, thanks for the clarification.

[Ami603]

How difficult would be to create a new version that ran exclusively on 68k cpu without using the chipset? It would be ideal for solutions like emu68 using rgt, maybe also draco, casablanca hardware,atari (SCNR).

[CCRider]

Originally Posted by Ami603

How difficult would be to create a new version that ran exclusively on 68k cpu without using the chipset? It would be ideal for solutions like emu68 using rgt, maybe also draco, casablanca hardware,atari (SCNR).

Really.

[bdb]

Originally Posted by Ami603

How difficult would be to create a new version that ran exclusively on 68k cpu without using the chipset? It would be ideal for solutions like emu68 using rgt, maybe also draco, casablanca hardware,atari (SCNR).

You mean emulate the chipset and hardware in software? I ask because I believe I've seen this done before on other CPUs and Operating Systems.

[boemann]

Originally Posted by Ami603

How difficult would be to create a new version that ran exclusively on 68k cpu without using the chipset? It would be ideal for solutions like emu68 using rgt, maybe also draco, casablanca hardware,atari (SCNR).

Well that really depends.

- Not shipping the audio.device would free half of Paula.
- Similarly we could likely ignore serial.device
- The floppy controller part of Paula is more difficult but I guess if you don't care
- CIA have timers we can't really do without, so alternative hardware should somehow provide a timer.device replacement for the kickstart
- A totally slimmed down graphics.library would make Denise obsolete. That would also make copper and blitter more or less obsolete. Obviously you would need some RTG up and running instead.
- But Denise also provides a video timer that we can't do without either.

Finally this is just the OS. Many programs accessing these things directly will obviosuly not work at all.

So yes it would be pretty difficult, but not impossible. I'm sure more problems will be found if one were to try.