Linked by Thom Holwerda on Sun 21st Aug 2005 14:36 UTC, submitted by AlexZOP
OSNews, Generic OSes "Based on an operating system called GEOS that was popular in the late 1980s and early 1990s, Breadbox Ensemble is a small (a full installation weighs in at under 10 MB) and fast suite of incredibly useful programs. While small, Breadbox Ensemble has a graphical user interface that mimics the look and feel of the Windows desktop." Read more...
Permalink for comment 21148
To read all comments associated with this story, please click here.
RE[2]: One small? problem
by edwdig on Mon 22nd Aug 2005 02:41 UTC in reply to "RE: One small? problem"
edwdig
Member since:
2005-08-22

Windows plays no role. It does require DOS, but all Breadbox really needs is a "sys c:" on the drive. It actually uses a lot less of DOS than Windows 9x did.

GEOS uses DOS for one reason: filesystem support. It will use thinks like DOS mouse drivers and memory drivers if you load them, but they are completely unnecessary.

The best thing breadbox could do is to open source this product, and hope that some developers had some real interest in taking GEOS into to the 21st century - like 32 or 64 bit processing, or being able to process more than 256 colors.

Open sourcing the code wouldn't really do anything. The people who know the code well enough to really do something significant with it aren't interested anymore. More importantly, you're talking about a half gigabyte tree of source code, almost entirely written in 8086 assembly code. The code was never moved to 32 bit before because you'd have to rewrite the vast majority of it in the process. Hand written assembly was great for their goal of running well on an XT, but horrible for making any major changes to system.

Last I heard, the kernel was rewritten to run under a DOS extender, but still in 16 bit mode. This eliminated the memory issues with the internet apps, but obviously wasn't a long term solution. Also, no one rewrote the VM scrub thread, which means memory allocations that were no longer needed were never being freed. The kernel would eventually run out of handles to allocate resources and would crash. From what I hear, this meant the web browser ran blazingly fast, but could only load about half a dozen web pages before the system ran out of resources.

Also, the system was capable of handling 24bit color. The only limitation was the UI color scheme was limited to 256 colors. Your default widget colors were limited to 256 colors, but that's the only thing limited. Even that wasn't that big a limitation. I had made a plan to remove that limit right before New Deal ran out of money, but never implemented it...

The biggest problem is it's API - it's a lot more difficult to program for than other OSes.

Quite the contrary. The API is excellent. The problem is the 16 bit memory management. Not being able to alloc more than 64k sucked, but that was a limitation imposed by the hardware available at the time the API was designed. Any UI related API was excellent - far better than any other UI API I've seen. I've long been tempted to reimplement the GEOS UI API on top of X or Win32, but it's a massive project and I don't have the time.

Reply Parent Score: 2