Mac OS 9 Development Requests (OS Level Items)

[nanopico]

The following thread was started to gauge interest in updates to various parts of OS 9.
There has been a lot of great input from many.

http://macos9lives.com/smforum/index.php?topic=2727.msg17839;

As I'm starting to get to a point where I can even start to develop some basic functionality I need to get a better idea of needs/requests.
I can not guarantee any of this will be implemented but I would like the input.
Once I've gotten these requests I will make a poll so that you can vote on what would be most important and I will use that come up with a development road plan.

This thread is for requests that are os level updates.

Here are some examples of OS Level items.
Support for newer logic board chipsets/controllers
New bus architectures (PCI-E, Firewire 800, USB 2)
Improved memory management
Better Multi-tasking
Low level drivers required for boot.
Pretty much anything that would belong in the Toolbox or System folder.

[nanopico]

https://en.wikipedia.org/wiki/Mac_OS_9

Apple billed Mac OS 9 as including "50 New Features" and heavily marketed its Sherlock 2 software, which introduced a 'channels' feature for searching different online resources and introduced a QuickTime-like metallic appearance. Mac OS 9 also featured integrated support for Apple’s suite of Internet services known as iTools (later re-branded as .Mac, then MobileMe, which was replaced by iCloud) and included improved TCP/IP functionality with Open Transport 2.5.

Other features new to Mac OS 9 include:[5]

    Integrated support for multiple user accounts without using At Ease.
    Support for voice login through VoicePrint passwords.
    Keychain, a feature allowing users to save passwords and textual data encrypted in protected keychains.
    A Software Update control panel for automatic download and installation of Apple system software updates.
    A redesigned Sound control panel and support for USB audio.
    Speakable Items 2.0, also known as PlainTalk, featuring improved speech synthesis and recognition along with AppleScript integration.[6]
    Improved font management through FontSync.
    Remote Access Personal Server 3.5, including support for TCP/IP clients over Point-to-Point Protocol (PPP).
    An updated version of AppleScript with support for TCP/IP.
    Personal File Sharing over TCP/IP.
    USB Printer Sharing, a control panel allowing certain USB printers to be shared across a TCP/IP network.
    128-bit file encryption in the Finder.
    Support for files larger than 2 GB.
    Unix volume support.
    CD Burning in the Finder (introduced in Mac OS 9.1).
    Addition of a 'Window' menu to the Finder (introduced in Mac OS 9.1)

See also https://en.wikipedia.org/wiki/Mac_OS_9#Version_history
[/quote]

Here's a good definition of some of the things that are OS Level to help you understand what is allowed here.

[MacTron]

@ Os level:
- Override the 1.5 Gb RAM limitation.
- Override the 2040 year limitation.
- G5 motherboard support.

@ User level:
- Quicktime H264 codec.
- USB 2.0 drivers.
- Drivers for faster video cards.
- HTML5 video suport.

[nanopico]

I'm going to remove this one from the list of options people can vote on as this will be a good first attempt at patching the os.
So consider this one as being worked on.

- Override the 2040 year limitation.

[GaryN]

Let's hope it doesn't take 25 years!

[nanopico]

Let's hope it doesn't take 25 years!

I'm hoping not 25 but maybe like 24?

[Front 424]

I don't know, one thing i thought of earlier is maybe better error/application crash recovery, so the entire computer doesn't need to be rebooted so much.  It seems to me that a total freeze up happened more in OS 9 than later editions, although even if you could successfully exit a program, it was mostly wise to reboot anyway.

Anyone have any input on this?  I am not totally sure about it.  It wouldn't be a high priority anyway, I thought I would mention. 
Having used OS X and multiple Windows versions, it always seemed that an application crash was much more prone in classic OS to lock up the system requiring a restart of some kind. 

Thoughts?

EDIT: I've heard some talk about poor memory management around here.  Is this possibly related to that?
Something about RAM not being cleared out properly?

[nanopico]

I don't know, one thing i thought of earlier is maybe better error/application crash recovery, so the entire computer doesn't need to be rebooted so much.  It seems to me that a total freeze up happened more in OS 9 than later editions, although even if you could successfully exit a program, it was mostly wise to reboot anyway.

Anyone have any input on this?  I am not totally sure about it.  It wouldn't be a high priority anyway, I thought I would mention. 
Having used OS X and multiple Windows versions, it always seemed that an application crash was much more prone in classic OS to lock up the system requiring a restart of some kind. 

Thoughts?

EDIT: I've heard some talk about poor memory management around here.  Is this possibly related to that?
Something about RAM not being cleared out properly?

Yes it is very annoying when the lock up like that.  There is a way to exit out cleanly with Macsbug, so it's possible to build something in.
It would have to be a patch actually to the process manager. The memory management issues stem around allocating 512 MB to the finder when you have 2 GB installed and the fact that there is no protected memory (which is probably part of the source of apps crashing).  When an app has crashed the process manager (which allocates the heap and stack for an app) should release those resources better and also check for open files so they are not left hanging in an opened state.  You would probably lose any data that had not been saved but that would be an issue in just about any system. It might be useful to identify apps that tend to crash more than others and also when it happens what else is running.  It would be easier to analyze the system to figure out the best way to tackle the problem. 
But yes I would agree it could go on the list of potential items.

[Front 424]

Yes it is very annoying when the lock up like that.  There is a way to exit out cleanly with Macsbug, so it's possible to build something in.

I remember fiddling around with Macsbug a few times, just to do it.  I think I recall what you're speaking of, being able to exit a normally fatal crash without having to reboot, but that's been years ago.  I take it you could find out using Macsbug what exactly the chain of events are that lead to such a crash?

It would have to be a patch actually to the process manager. The memory management issues stem around allocating 512 MB to the finder when you have 2 GB installed and the fact that there is no protected memory (which is probably part of the source of apps crashing).  When an app has crashed the process manager (which allocates the heap and stack for an app) should release those resources better and also check for open files so they are not left hanging in an opened state.  You would probably lose any data that had not been saved but that would be an issue in just about any system. It might be useful to identify apps that tend to crash more than others and also when it happens what else is running.  It would be easier to analyze the system to figure out the best way to tackle the problem. 
But yes I would agree it could go on the list of potential items.

Thanks for clarifying!  I probably should have gathered that from some of the other conversations, since I realize now what you're talking about, the 1.5g limit. 

Another question, for you or anyone, about the RAM disk workaround.  You posted this over here http://macos9lives.com/smforum/index.php?topic=2860.0

Then use MacsBug to verify it is there.  If that works then it tells us that the memory is addressable and the potential of some sort of ram disk up there is possible (though not necessarily easy in any way).
Just thought I'd share this bit of info.

What exactly is the plan with that RAM disk? 

[Front 424]

Also, I've seen this mentioned in here and it is in nanopico's list in the first post about

Better Multi-tasking

What would that encompass and how would one go about it?  What functionality do people want to see out of that?  Question for anyone

[Mat]

Anyone have any input on this?  I am not totally sure about it.  It wouldn't be a high priority anyway, I thought I would mention. 
Having used OS X and multiple Windows versions, it always seemed that an application crash was much more prone in classic OS to lock up the system requiring a restart of some kind. 

Thoughts?

Well, I am 100% sure that our "feelings" about it is highly influenced about Apples "propaganda" in early X versions, telling us at every program crash that the system "does not have to be restarted".

Thats not a kind of provokation or to start a endless debate, but I truely belive so.
Cooperative multitasking is not that bad at all, and I see no huge problems at desktop systems using cooperative multitasking instead of symmetric multitasking.
I see some problems with Mac OS 9.x especially 9.2.2 which became more unstable. Some months ago I learned here that the Carbonized programs may be a cause. That fits to my own memories. Mac OS 8.6 was the most stable OS I ever used. Rock solid, and not comparable to Win NT/2000/Millenium or early Mac OS X versions up to 10.4.11. I even got the feeling that user application at recent Ubuntu/Linux MiNT computers crash more often than at Mac OS 8.6 (but that might be just a feeling again, influenced by my "love" to the Mac OS).

About new features for the Mac OS, I am sure that drivers are most needed recently. USB 2 is the main drawback in everyday usage. Graphiccards are not such a huge problem in my opinion. There was for example the ROM for flashing PC ATI Radeons 9000 and 9200 cards to Mac ones. If someone would adapt this Roms and make it possible to use the whole 256MB Ram of these cards, that are still in production, we could equip every PCI-Mac with a very good card with verry well 3d possibilities for our systems - for about 25 Euros - brand new.

Another good example for "drivers" is Intecs HD-Speedtools possibility to use discs bigger than 128MB at every built in Mac IDE controller, even if it was told to be impossible by Apple.


In general I am not missing much with Mac OS 9. Most things are at a user level:

-) modern PDF Viewer - could be quickly done with the existing Ghostscript & MacGSView
-) Improved Classilla
-) Possibility to use .odt/xml textfiles
-) some modern Video Codecs (best would be a PCI decodercard like the Wired4DVD was for MPG2)

What I would really like to see at OS level at 9 machines is the possibility to use both CPU at Dual computers in general. Something like "1 program at this CPU the other one at the other". Cameron Kaiser made some tests int his directions (he tried to use the 2nd CPU for JavaScript) but stopped at some point.

[nanopico]

Yes it is very annoying when the lock up like that.  There is a way to exit out cleanly with Macsbug, so it's possible to build something in.

I remember fiddling around with Macsbug a few times, just to do it.  I think I recall what you're speaking of, being able to exit a normally fatal crash without having to reboot, but that's been years ago.  I take it you could find out using Macsbug what exactly the chain of events are that lead to such a crash?

It would have to be a patch actually to the process manager. The memory management issues stem around allocating 512 MB to the finder when you have 2 GB installed and the fact that there is no protected memory (which is probably part of the source of apps crashing).  When an app has crashed the process manager (which allocates the heap and stack for an app) should release those resources better and also check for open files so they are not left hanging in an opened state.  You would probably lose any data that had not been saved but that would be an issue in just about any system. It might be useful to identify apps that tend to crash more than others and also when it happens what else is running.  It would be easier to analyze the system to figure out the best way to tackle the problem. 
But yes I would agree it could go on the list of potential items.

Thanks for clarifying!  I probably should have gathered that from some of the other conversations, since I realize now what you're talking about, the 1.5g limit. 

Another question, for you or anyone, about the RAM disk workaround.  You posted this over here http://macos9lives.com/smforum/index.php?topic=2860.0

Then use MacsBug to verify it is there.  If that works then it tells us that the memory is addressable and the potential of some sort of ram disk up there is possible (though not necessarily easy in any way).
Just thought I'd share this bit of info.

What exactly is the plan with that RAM disk?

I'm still trying to figure out where the actual limitation is.  If it is with the memory management or with the process management.  From what I read and what I'm seeing, memory manager starts first.  When an application launches the memory manager allocates memory (possibly through requests to the process manager) then hands off execution and scheduling to the process manager.  This is just assumptions I've made and haven't verified.

So as far as the ram disk thoughts.  If that goes forward the first thing would probably be to just write a new extension that can address the top portion of ram even if the process manager and memory manager can not and the extension would be just like the regular ram disk.  Since it would be sort of running in the process manager and out of it, the reporting of ram usage would still be as it is now until I can find out where the actual limit resides and patch that so then you could a 1.5 gb ram disk if you wanted using the built in ram disk utilities. Just thoughts though. I haven't really given a lot to the design as I'm trying to figure out where all these limits and configurations reside.

[nanopico]

Anyone have any input on this?  I am not totally sure about it.  It wouldn't be a high priority anyway, I thought I would mention. 
Having used OS X and multiple Windows versions, it always seemed that an application crash was much more prone in classic OS to lock up the system requiring a restart of some kind. 

Thoughts?

Well, I am 100% sure that our "feelings" about it is highly influenced about Apples "propaganda" in early X versions, telling us at every program crash that the system "does not have to be restarted".

I've had multiple occasions where an app crash has forced a restart in OS X.  General it was usually shown as a kernel panic but originated from an application make some sort of system call that failed and triggered the kernel panic.

Thats not a kind of provokation or to start a endless debate, but I truely belive so.
Cooperative multitasking is not that bad at all, and I see no huge problems at desktop systems using cooperative multitasking instead of symmetric multitasking.
I see some problems with Mac OS 9.x especially 9.2.2 which became more unstable. Some months ago I learned here that the Carbonized programs may be a cause. That fits to my own memories. Mac OS 8.6 was the most stable OS I ever used. Rock solid, and not comparable to Win NT/2000/Millenium or early Mac OS X versions up to 10.4.11. I even got the feeling that user application at recent Ubuntu/Linux MiNT computers crash more often than at Mac OS 8.6 (but that might be just a feeling again, influenced by my "love" to the Mac OS).

About new features for the Mac OS, I am sure that drivers are most needed recently. USB 2 is the main drawback in everyday usage. Graphiccards are not such a huge problem in my opinion. There was for example the ROM for flashing PC ATI Radeons 9000 and 9200 cards to Mac ones. If someone would adapt this Roms and make it possible to use the whole 256MB Ram of these cards, that are still in production, we could equip every PCI-Mac with a very good card with verry well 3d possibilities for our systems - for about 25 Euros - brand new.

Another good example for "drivers" is Intecs HD-Speedtools possibility to use discs bigger than 128MB at every built in Mac IDE controller, even if it was told to be impossible by Apple.

All input is welcome at this point.  I'm not going to commit to any of them (except the year 2040 issue).
As for the IDE issue.  Theoretically it's possible.  I've seen on older PC's special drivers for specific drives that can do this.  The bios still thinks it's small, but once the os and driver are loaded it can see all of the drive.  Now a mac isn't a PC so I'm not sure if it's possible or not and how easy or difficult that would be.

In general I am not missing much with Mac OS 9. Most things are at a user level:

-) modern PDF Viewer - could be quickly done with the existing Ghostscript & MacGSView
-) Improved Classilla
-) Possibility to use .odt/xml textfiles
-) some modern Video Codecs (best would be a PCI decodercard like the Wired4DVD was for MPG2)

What I would really like to see at OS level at 9 machines is the possibility to use both CPU at Dual computers in general. Something like "1 program at this CPU the other one at the other". Cameron Kaiser made some tests int his directions (he tried to use the 2nd CPU for JavaScript) but stopped at some point.

I'd like to see better usage of dual CPU's as well.  The Process Manager would probably be need to be updated so that it can control execution of each application and distribute it between the CPU's.  Also I believe protected memory would have to be implemented so to prevent memory corruption between the two CPU's.

As it is right now.  The second CPU is initialized and then set to what equates to an infinite loop.  If an application is designed for multiple CPU's it can use both of them and both can access the ram, but the application decides which processor access which part of the heap.  If the application designer isn't careful with that they could hit a deadlock.

All good input though, thanks.

[IIO]

- Override the 2040 year limitation.

that is the most important thing anway. 2040 is closer than you might think.

[nanopico]

- Override the 2040 year limitation.

that is the most important thing anway. 2040 is closer than you might think.

So I have until February 5th 2040 to get this fixed as that is the last day the system time can address.

[GaryN]

- Override the 2040 year limitation.

that is the most important thing anway. 2040 is closer than you might think.

So I have until February 5th 2040 to get this fixed as that is the last day the system time can address.

Really, I can just see us now - a bunch of really old Luddites hunched over our old duct-taped-together computers with the system clocks set on manual and the dates turned back… pissing and moaning about how hard it is to find 50-year-old software and trying to get Nanopico to write an enabler to control our Apple personal teleportation watches from OS9…

[IIO]

So I have until February 5th 2040 to get this fixed as that is the last day the system time can address.

you have until february 5th 2040 to get all the issues fixed.

[Mat]

As for the IDE issue.  Theoretically it's possible.  I've seen on older PC's special drivers for specific drives that can do this.  The bios still thinks it's small, but once the os and driver are loaded it can see all of the drive.  Now a mac isn't a PC so I'm not sure if it's possible or not and how easy or difficult that would be.

It is possible - for ages. Intec wrote the driver that uses built in IDE controllers that are limited to the 128GB (not MB like I wrote in my last posting), and can use them with virtually any size. So you can use about any disk size in IDE Macs with onboard controllers. See here: http://www.speedtools.com/HDInfo.html

I have myselve a 400GB HD running at a 128 GB limited G4 controller. This was just an example for what can be done with wise driver development! So no need to work in this direction, it is done for more than 10 years
Perhaps you consider such improvements as "OS level"? I would call them "driver" like USB 2 driver that is really needed.

[MacTron]

I have open a new tread to discuss the 2040 issue specifically.

http://macos9lives.com/smforum/index.php?topic=2862.msg18042#msg18042

[nanopico]

As for the IDE issue.  Theoretically it's possible.  I've seen on older PC's special drivers for specific drives that can do this.  The bios still thinks it's small, but once the os and driver are loaded it can see all of the drive.  Now a mac isn't a PC so I'm not sure if it's possible or not and how easy or difficult that would be.

It is possible - for ages. Intec wrote the driver that uses built in IDE controllers that are limited to the 128GB (not MB like I wrote in my last posting), and can use them with virtually any size. So you can use about any disk size in IDE Macs with onboard controllers. See here: http://www.speedtools.com/HDInfo.html

I have myselve a 400GB HD running at a 128 GB limited G4 controller. This was just an example for what can be done with wise driver development! So no need to work in this direction, it is done for more than 10 years
Perhaps you consider such improvements as "OS level"? I would call them "driver" like USB 2 driver that is really needed.

Neat, but two problems with that.
1. The driver cost $60 (okay not a big price, but free is always cool too.  so maybe not a big problem.)
2.  Booting. The driver has to load after the os loads. So you could potentially run into booting issues if any of the system extensions that get loaded prior to the driver get loaded above 128 GB.  This could be worked around by partitioning yes, but you can't assume or require someone to do that.  The other thing the driver could do to handle early boot would be to use a nvram script in open firmware to patch the fcode drivers for the ATA controller.  This would allow open firmware to even access the whole drive to find a bootable system folder.

But I'm glad there is this out there so now I know that it can be done on the Mac side as well.