Classic Mac OS Software (Discussions on Applications) > Hacking the System, Mac OS 9.3, and Beyond !

Mac OS 9 Development Requests (OS Level Items)

<< < (3/17) > >>

Mat:

--- Quote from: Front 424 on November 17, 2015, 09:35:48 PM ---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?

--- End quote ---
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:

--- Quote from: Front 424 on November 20, 2015, 12:24:47 AM ---
--- Quote from: nanopico on November 18, 2015, 06:20:47 AM ---
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.
--- End quote ---

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?


--- Quote from: nanopico on November 18, 2015, 06:20:47 AM ---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.

--- End quote ---

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


--- Quote ---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.
--- End quote ---


What exactly is the plan with that RAM disk?

--- End quote ---
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:

--- Quote from: Mat on November 20, 2015, 01:52:59 AM ---
--- Quote from: Front 424 on November 17, 2015, 09:35:48 PM ---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?

--- End quote ---
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".


--- End quote ---

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.


--- Quote from: Mat on November 20, 2015, 01:52:59 AM ---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).

--- End quote ---




--- Quote from: Mat on November 20, 2015, 01:52:59 AM ---
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.

--- End quote ---

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.


--- Quote from: Mat on November 20, 2015, 01:52:59 AM ---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.

--- End quote ---

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:

--- Quote from: MacTron on November 12, 2015, 12:13:33 PM ---- Override the 2040 year limitation.

--- End quote ---

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

nanopico:

--- Quote from: IIO on November 20, 2015, 08:26:43 PM ---
--- Quote from: MacTron on November 12, 2015, 12:13:33 PM ---- Override the 2040 year limitation.

--- End quote ---

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


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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version