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.

[DieHard]

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

After working with Macs and PCs since the inception, to be honest this approach absolutely sucks. I strongly recommend against any "low level" drivers or "dynamic drive overlays" as they used to call them in the PC world. The main issue is that they will, in the end, lead to data loss. if there are any issues, whatsoever, these "low level" overlays will cause major problems if you move the drive to another system for data recovery.  Remember, if the overlay does not load, then the drive will appear "foreign" to all over systems it is connected to.  I have personally seen, many instances of a client loosing everything.  some go to inexperienced PC/Mac repair places that tell them their drive is "empty" or worse yet, format it, since they "assumed" it was empty because they did not realized it had an overlay to see the drive partitions and stuck it in another Mac or PC without booting to it... which is common when you are having a boot problem and you bring your computer in for service.

As a big advocate Hard disk speed tools for many of their tools, I still do NOT recommend using this feature. 

Lastly, as a side note, I have also seen some volumes not mountable in macs that do not have HD Speed Tools installed when you add a hard drive as a secondary drive (that had HDTS installed) to a G4, even though the source MDD and destination MDD both supported large IDE drives.  The fix is to install HDTS on the boot volume of the destination MDD, and then everything is fine. Remember, HDTS, updates the original Mac OS 9 driver on the hard drive and assumes you will be booting from a volume that has HDTS installed on it.  Sometimes it is not an issue moving drives to units without HDTS, and sometimes it is... I personally hate random variables, so I suggest using HDTS for it's other cool features and NOT updating the drivers on your hard drives as this can add an unwanted side effect when you need to recover data... just an opinion... do whatever suites your needs

[IIO]

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.

you are right in theory but in practice it is a minor or rare problem. you have to partition anyway to something under 192 for the boot volume, and the original CD installer puts stuff at the front of the volume. also if you use a defragger once per year, the system stuff will end up at the beginning again even if it had been moved for some reason.

of course the alternative is to avoid IDE totally and go for something different via PCI, the size limit for SATA or firewire lies at 2000 mb.

[DieHard]

you are right in theory but in practice it is a minor or rare problem. you have to partition anyway to something under 192 for the boot volume, and the original CD installer puts stuff at the front of the volume. also if you use a defragger once per year, the system stuff will end up at the beginning again even if it had been moved for some reason.

Well as far as rare or minor... having disk problems or a crashed mac, or whatever and connecting the drive to another unit may seem rare to you (maybe you are very lucky), but many users will encounter the need to do so, and as far as having some non-skilled friend or technician whipping out the volume because they are "unaware" of the existence of such configurations (with drivers that load before the OS) is definitely not MINOR in my book. 

[nanopico]

I say we avoid trying to over-riding hardware limits if possible.

[devils_advisor]

can you post any developer docus and stuff somewhere in one place ? i mean everything you wanna give out that can be stored on a hard drive to study ?

[nanopico]

I can post some yes. It will take me a little bit to get them up somewhere.  I've got about 700 mb worth of pdf's I've found from the good old searching on Google.
Plus there is that 4 GB file that archive.org is hosting from the apple developer site (though I know there are somethings missing in that too).
I also have several books on either specific programing language (c, c++, pascal) that are fairly general and one on operating system design.  The books would be a little harder to upload though.

[devils_advisor]

i might have time to study it on and off soon. would be nice to have some lecture on the road and code warrior to test it

[nanopico]

Here we go.  Sorry they are zip files for the moment.  These are what I downloaded from I don't even remember where.  A lot of searching on Google occurred to find these.   I'm sure they aren't exactly unknown, but to find the specific version of Inside Macintosh that corresponded to OS 8 and 9 took a little time.  Most of the ones floating around don't have the addition for those, just up to 7.6.
These outline how the system works, so reading them all is a daunting task, but if you have even a vague understanding of basic OS design, these are absolutely amazing.  They really document a lot of internals and contain info on creating drivers, creating system extensions and non system extensions along with patching the OS.

http://www.mediafire.com/download/7d87shfbznrxsk4/InsideMacintosh.zip

Then there are a couple that deal with programming for Macintosh both in c and pascal. These are pretty good for how to use specific API's in user applications.

http://www.mediafire.com/download/263p26mdsdlg3o1/ProgrammingMacOS_8_9_en_C.zip
http://www.mediafire.com/download/95xytzue6lx6eb8/ProgrammingMacOS_8_9_en_Pascal.zip

And then some documents on ACI's 4D database suite.   The ACI stuff is useless as it just outlines/documents their product.
But in it there was some Apple documentation as well, that provides some more information than the above files.

http://www.mediafire.com/download/lyud9zlx8s6cvjz/MacOS_8_9_X_4D_Omnis.zip


Besides Codewarrior I would suggest getting MPW with the Pascal Compiler. 

Enjoy. And sorry for uploading zips.  I will try to correct this soon.

[nanopico]

Here's the BOOK E document on the Enhanced ISA for PPC used in Mac OS.

[Protools5LEGuy]

Here we go. 

2nd and 4th post are the same?

Book E is porno for engineers.

[nanopico]

Here we go. 

2nd and 4th post are the same?

Book E is porno for engineers.

Thanks for pointing out the duplicated link. I updated it so it should be right now.

Yes the Book E is porno for engineers.


I also attached here the baseline ISA/dev specs for All PPC.

[nanopico]

And here's a spec for the ELF executable format (only useful for the early boot loader code.)

[Mat]

Guys, do you know that the entire source code of OS 7.1 is out there?
It is not exactly Mac OS 9 in fact it is completely 68k, but many things were still the same later, and it might help to understand some stuff.

If you cannot get it, and think it might be of interrest, drop me a PM.

[nanopico]

Guys, do you know that the entire source code of OS 7.1 is out there?
It is not exactly Mac OS 9 in fact it is completely 68k, but many things were still the same later, and it might help to understand some stuff.

If you cannot get it, and think it might be of interrest, drop me a PM.

I've seen that, but never really dug through it.
Yes a lot of it would remain the same.
Too bad it was from the day with the rom as hardware rather than on the disk, so the boot code would be completely different. Still worth a look.

[nanopico]

So I did dig through 7.1
It does have PPC Patches in it so that would maybe make this 7.1.2 actually. Although it could be earlier as I'm sure they worked on it and code was there prior to release.
I do however find the dev's who worked on this rather hilarious.

The toolbox routines for handling the system date time are in a file called sexydate and the actual function call that is used is called sexydate as well.
There is also a library called SuperMario Gibbly (that's just funny), a toolbox patch called ToolboxCastration
and a library for internationalization that has a comment on a compare function that specifically says this implementation is terrible for internationalization. 

Developers are pretty much crazy.

[GaryN]

Hey! Nice avatar, nano!

[nanopico]

Hey! Nice avatar, nano!

Thanks!

[Front 424]

Just a question on possible implementation of dual-processor improvement that was mentioned.

Someone mentioned having the launcher alternate each program between processors.  I also thought maybe a rudimentary exercise for testing would be to get the OS and a few other simple items (like basic utilities, text reader etc.) running off the first processor, and relegating
most other user launched apps to the second.  Just a suggestion as to a simple test that probably wouldn't be hard to put into play, and you could test individual items or processes in the second processor at least to see what if any marginal improvements in speed there are. 
Maybe this has already been done, just as a preliminary step to something more extravagant?
I am unsure of what the average overhead of the system is.

I also thought maybe a processor assignment extension/panel with a right-click context menu when launching an app or clicking a specific document where you could specify which processor will run the program might be a next step.  The user would be able to choose to confine low intensity apps to one processor, and maybe a single intensive app to the second.

Another question I had would be about some type of overflow scheme where if a processor was maxed out it could borrow from a second. 

As far as parallel or true multi-processor stuff, I'm not sure how doable just from the OS level it would be to divide tasks between the two processors, since that seems to be dependent on the actual application code, although there might possibly be some workarounds.

Just some thoughts and questions to throw out there for discussion!

 

[nanopico]

Just a question on possible implementation of dual-processor improvement that was mentioned.

Someone mentioned having the launcher alternate each program between processors.  I also thought maybe a rudimentary exercise for testing would be to get the OS and a few other simple items (like basic utilities, text reader etc.) running off the first processor, and relegating
most other user launched apps to the second.  Just a suggestion as to a simple test that probably wouldn't be hard to put into play, and you could test individual items or processes in the second processor at least to see what if any marginal improvements in speed there are. 
Maybe this has already been done, just as a preliminary step to something more extravagant?
I am unsure of what the average overhead of the system is.

I also thought maybe a processor assignment extension/panel with a right-click context menu when launching an app or clicking a specific document where you could specify which processor will run the program might be a next step.  The user would be able to choose to confine low intensity apps to one processor, and maybe a single intensive app to the second.

Another question I had would be about some type of overflow scheme where if a processor was maxed out it could borrow from a second. 

As far as parallel or true multi-processor stuff, I'm not sure how doable just from the OS level it would be to divide tasks between the two processors, since that seems to be dependent on the actual application code, although there might possibly be some workarounds.

Just some thoughts and questions to throw out there for discussion!

These would primarily be tasks for the process manager.  I have not dug deep enough yet to know exactly how the process manager works, but what I have learned is that parts of the memory manager seem to be implemented with in it, it handles loading of applications and cleaning up after they are done.
Any level of assigning an application to a processor  would require a pretty hefty patch to the process manager and some minor ones to the memory manager.

I'll keep it on a list of things that could be possible, but right now with what I know and what I don't know, I just don't feel comfortable even attempting that (right now at least).  I'd like to get a few other things done so that I know I understand the system well enough.  One thing I would like to get done (which would actually be a step to multiprocessor support) would be fixing the 1.5 GB ram limit.  This touches on both the memory manager and process manager and won't require as many changes to either.  After that I would have a better understanding of both and then could revisit this idea.

So it's not off the table yet.

[nanopico]

Just an FYI for Multiprocessor support.

Enabling the second cpu at the OS level will probably break many other applications.
With the cooperative multitasking used, when an app launches, the os can do nothing until the app releases control back to the process manager.  Probably very little would actually be gained from it with in the context of the OS 9 architecture, but again I haven't gotten to far into that area to assess the possibility and gain from it yet.

[MacTron]

I don't think that improving dual processor support must be a priority. I have tested this topic at user level, and eventroug dual CPU can theoretically double the speed of our computers, there is a lot of bottlenecks that dramatically limit the success of multi CPU support. Even the faster 166 Mhz system bus on a MDDs is a bottleneck for most dual CPUs apps, let  aside slow ATA 66 or ATA 100 Hard Disk ...

As I use to tell, if you wish speed on a Classic Mac install a nVidia GeForce4 Ti 4600, a  SSD with a SeriTek 64 bits SATA PCI card into a MDD single 1.25. And finally  add an xServe 1.33 CPU and overclocked it to 1.50 Ghz...

... but don't bore with dual CPU's ... IMHO

[nanopico]

I don't think that improving dual processor support must be a priority. I have tested this topic at user level, and eventroug dual CPU can theoretically double the speed of our computers, there is a lot of bottlenecks that dramatically limit the success of multi CPU support. Even the faster 166 Mhz system bus on a MDDs is a bottleneck for most dual CPUs apps, let  aside slow ATA 66 or ATA 100 Hard Disk ...

As I use to tell, if you wish speed on a Classic Mac install a nVidia GeForce4 Ti 4600, a  SSD with a SeriTek 64 bits SATA PCI card into a MDD single 1.25. And finally  add an xServe 1.33 CPU and overclocked it to 1.50 Ghz...

... but don't bore with dual CPU's ... IMHO

I couldn't agree more.  I think dual cpu support would be something I would only do once I have every other possible thing implemented.  And by that point I'm just not sure about it.

[Front 424]

Hmm.  I wasn't sure about the feasibility or method of implementation if one were to do so regarding multiprocessor, and I guess I'm even less sure now.  It's a neat thought, though, if it were doable. 
If I understand correctly, doesn't OS X have some innate multiprocessor/multicore assignment scheme?  I believe recent Windows versions do the same, utilizing several cores without the application code necessarily being optimized for that.  Or maybe I'm wrong on that?

[Front 424]

As I use to tell, if you wish speed on a Classic Mac install a nVidia GeForce4 Ti 4600, a  SSD with a SeriTek 64 bits SATA PCI card into a MDD single 1.25. And finally  add an xServe 1.33 CPU and overclocked it to 1.50 Ghz...

... but don't bore with dual CPU's ... IMHO

Been interested in a compatible SSD, but I'm just scratching the surface.  So tell me about this SeriTek PCI card, and what kinds of performance increase have you or others experienced with SSD?

Also, I assume the xServe CPU is the fastest currently compatible processor with OS 9?  I saw some discussion on the forum just recently about it.

[devils_advisor]

Dual cpu in our case is very delicate.  You risking stability.  Most of these apps aren't aware of 2 cpus and totally ignore the second one. If you enforce it you will end up with a disaster. I would leave it as it is and focus on other things that can be done without leveraging stability and other stuff that everybody needs. After all how many of you have a dedicated test system at hand to check for incompatibility? By dedicated i mean a fully equipped test system with specs as your first system. And another thing would be how do you think you go about reverse engineering the apps to implement dual cpu support?

[Front 424]

It was mentioned above, and I thought it was interesting.

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.

Assigning an application to one or the other is probably the easiest to achieve, if any usage of dual cpu is possible.  I was just interested and wondering really about how one would go about it if one were to attempt it. 
Nanopico is still trying to fully understand the memory and processor managers, anyway, so this would be down the list.

[devils_advisor]

Yes but keep in mind you can only work or patch the os, the application is still the same as it was before. The program needs to recognize and utilize a second cpu which would mean you have to reverse the app without the blessing of the company. They would never release the source to you.

[nanopico]

 

Yes but keep in mind you can only work or patch the os, the application is still the same as it was before. The program needs to recognize and utilize a second cpu which would mean you have to reverse the app without the blessing of the company. They would never release the source to you.

I think the advantage if it were able to work at the OS level is that you could have two apps running at the same time with out task switching and one having to give control to the other.  But that is in theory.
I believe I'm in agreement with you on this one though.  As even if two app's ran at once, they still could access the same resources and if the multitasking isn't re-written (which would probably break just about every application out there) You would easily get in a dead lock and that would not be fun.

[Protools5LEGuy]

Improving sherlock to include google/yahoo and bing as search engines. Sherlock is in Mac OS 9 included app and should be considered at OS level.

Create plugs for Quicktime to be closer to 2016 standarts. Audio streams/Internet Radio.

Improving disk utility to understand GUID partitions.

[davisdelo]

Improving sherlock to include google/yahoo and bing as search engines. Sherlock is in Mac OS 9 included app and should be considered at OS level.

Here's some pretty good resources for Sherlock plugin creation:
http://www.macos.utah.edu/documentation/general_software_and_utilities/sherlock_utilities.html

http://pwrsearchr.users1.50megs.com/sherlock/srclinks.html

I managed to make a Google.com plugin that looks the part, but I'm not sure if it functions right now because the only thing I have to test it on is Sheepshaver with 8.6, which Sherlock likes to crash every few seconds.  Once I have a monitor for my MDD though I'll be all over this 

[it0uchpods]

Improved right click/CTRL+click menus with Copy, Paste, etc...
Screensavers!

[Front 424]

Improved right click/CTRL+click menus with Copy, Paste, etc...
Screensavers!

I've been thinking about right click menu for a while and glad you mentioned it!
There should be an "open with" when you right click on a file that brings up a submenu for that filetype with a selection of applications that can be modified by a control panel.  And you can modify the default program as well.

I know there are some extensions that are similar, maybe there is already one that does this?

[IIO]

i believe that anything new in that field should indeed use the contextmenu plug-in interface.

there are already plugins like "open with filebuddy" - maybe one should just try to hack one of them to match another app.

p.s. should be possible with applescript, btw.

[IIO]

here it is, voila.

i would have been suprised if something like this was not in my 1000 items strong OS9 extensions collection!

[IIO]

here are two alternatives.

where "open with" will give you all apps scanned, "open with cm" will let you create you a custom list and "open with process" allows the file only to be opened using a currently running program.

have fun!

[IIO]

hint: dont install them all 3 at the same time, or you dont know what you are seeing.

[Front 424]

hint: dont install them all 3 at the same time, or you dont know what you are seeing.

Thanks IIO!  I'm going to try Open With CM first, that sounds like the most desirable for my usage.

[Knezzen]

IIO: Is there any way to make you share your extension collection or parts of it? Would be wonderful to have on Macintosh Garden or here

[Front 424]

I tried out Open With CM.  It works admirably.  I was hoping ultimately for something that is filetype/application dependent, so you can have a separate list for audio/video/text files etc, BUT, it is still an improvement over having nothing at all for sure! 

Thanks IIO!

[Front 424]

IIO: Is there any way to make you share your extension collection or parts of it? Would be wonderful to have on Macintosh Garden or here

I've seen you post over at Macintosh Garden.  Are you a mod over there? 

[Knezzen]

I've seen you post over at Macintosh Garden.  Are you a mod over there?

Me? Im an admin over there. Me and fogWraith host the whole site with downloads and everything. I just havent been that active on the forums historically, more lurching in the background

[WolfpackN64]

I don't know in which capacity Mac OS 9 supports multiprocessor/multicore CPU's (but I thought some rudimentary support was in place.

What I'm really curious about is if Mac OS 9 would be able to support something like Gallium3D to vastly improve GPU support.

[IIO]

you are in the wrong thread.

however, multiprocessor support under macos9 is limited to allow applications to support it.

cubase/nuendo, photoshop/after effects and cinema 4d do supprt it in different ways. there is a athread here somewhere where we tried to list all apps with mp support.

3d hardware supprt is handeled similar, the os has close to nothing to do with that question.
i am not so sure about maya, cinema4d and QVTR-quicktime, so i think that the only apps which support 3d hardware support are games.

[WolfpackN64]

Right, my apologies. I keep forgetting the Kernel itself doesn't handle the drivers. I've been misformed by monolithic designs.

I wonder how these drivers work then. Do the programs need to include them themselves?

[IIO]

i dont think so.

if you remove the multiprocessor extension from your OS9 system folder, cubase stops allowing both of its 2 different MP support options.

it is just so that things like quicktime, networking or the finder always run on the first core only. up to OSX 10.5 in think!

[IIO]

actually an OS which lets all applications run on all cores would be a bit weird - different applications should probably always use a custom way of how they use processors/cores/pipes.

there is a huge difference between nehalem and earlier boards for example, which gives developers room to experiment and optimize.

[Daniel]

I have a mildly achievable OS level development request.

Get rid of the stupid " The document $foo could no be opened because the application program that opened it could no be found" message. Sometimes I get it even when I drag that document onto an application, clearly signaling my intent to open it with that application. Instead, it should open a dialog asking me to pick the application I want to open it with (like what OSX does). The dialog should also have big buttons to use ResEdit and/or BBEdit if you have them on your system(possibly with a control panel that lets you add other options).

Looking at some of the harder to do development requests (specifically, protected memory and multiprocessing), I think I have some ideas on how to do them. It would take a lot of reverse engineering and hard work in general, but it might be possible ( for protected memory, sure. Maybe for multiprocessing).

[nanopico]

I have a mildly achievable OS level development request.

Get rid of the stupid " The document $foo could no be opened because the application program that opened it could no be found" message. Sometimes I get it even when I drag that document onto an application, clearly signaling my intent to open it with that application. Instead, it should open a dialog asking me to pick the application I want to open it with (like what OSX does). The dialog should also have big buttons to use ResEdit and/or BBEdit if you have them on your system(possibly with a control panel that lets you add other options).

This isn't really an OS level thing. It is Finder functionality and although the OS and Finder are pretty good friends, the Finder is still not OS.  OS in this context is being defined as the core kernel and drivers.

Looking at some of the harder to do development requests (specifically, protected memory and multiprocessing), I think I have some ideas on how to do them. It would take a lot of reverse engineering and hard work in general, but it might be possible ( for protected memory, sure. Maybe for multiprocessing).

Both protected memory and multiprocessing are probably not going to happen actually probably shouldn't. There are great many applications that rely on the memory not being protected (they shouldn't but they do) so there would be applications that will no longer work.  Multiprocessing is in the same situation.  The OS uses it, but it is only available to programs that support it.  Love it or hate it, it would break existing apps that rely on timing, such as just about any DAW.  So as far as making the possible, it is a huge undertaking like you say and would have probably a negative payoff in the end.

[WolfpackN64]

The multiprocessing issue isn't really that dire then. If apps can be written to make use of it via cooperative multiprocessing, then I'd say that's basically a non-issue.

[Daniel]

Understood. You are probably right about multiprocessing and protected memory. Still, it would be so cool...

[Protools5LEGuy]

I propose a compromise in the naming schemes. How about we release 9.2.4 for compatablility with more devices and basic stability improvements and the like. We can save 9.3 for major modifications to the core system software(NanoKernal, System Folder, Finder, Etc.). It will probably take a while to get protected memory and multiprocessing working, so these should probably be saved for 9.3. G5 compatablilty and  removal of the 1.5 Gig limit could go in either. I am not sure exactly how much work those would take.

What about upgrading the Carbon Libraries to use some early-OSX apps? Or optimizing Carbon Lib?

[torvan]

I have to second, third or fourth agree (I lost track) on the idea (and near need) of using large drives without having to shell out the money (and the resulting "be damn careful as data loss can happen" warnings) for the Intech Disk SpeedTools driver.

Especially with the move to SSDs happening all over, not to mention replacement mechanical disk drives, all of which are going to get (if not already) impossible to use because all are larger than that which Drive Setup can see and use.  So you are stuck with not being able to use the whole drive.

[IIO]

time to revive this thread.

nano, what is the reason why the unsupported OS cant use the fw 400 ports of the MMD but only the fw 800 port - which means that you only have a single port when you use this machine.

this would be on top of my personal request list, it is one of the three reasons why i dont want to use an MDD here.

[nanopico]

time to revive this thread.

nano, what is the reason why the unsupported OS cant use the fw 400 ports of the MMD but only the fw 800 port - which means that you only have a single port when you use this machine.

this would be on top of my personal request list, it is one of the three reasons why i dont want to use an MDD here.

This is a reason I do not know. Maybe I should take a look at that.

[Daniel]

time to revive this thread.

nano, what is the reason why the unsupported OS cant use the fw 400 ports of the MMD but only the fw 800 port - which means that you only have a single port when you use this machine.

this would be on top of my personal request list, it is one of the three reasons why i dont want to use an MDD here.

Not much is known about the MDDs Firewire 800 chipset.

There is a standard chipset implementation for Firewire, called OHCI (name shared with USB), but it only covered Firewire 400. There was a partial draft for a Firewire 800 OHCI, but it was abandoned and I can't find it anywhere.

The MDDs Firewire claims to be OHCI, except it can't really be OHCI. OHCI doesn't do Firewire 800. It's some kind of magic Apple chipset that is kinda sorta like OHCI and doesn't have any documentation.

Apple does have a bunch of documentation on writing Firewire Interface Modules (FWIMs). Combined with the available standards on Firewire, it looks barely possible to write a FWIM, if we understood the chipset well enough.

We will probably have to reverse engineer the Fcode for this stuff. Not fun.