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...
Thread beginning with comment 20927
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: One small? problem
by jchildrose on Sun 21st Aug 2005 15:55 UTC in reply to "One small? problem"
jchildrose
Member since:
2005-07-06

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 used to be the best OE for x86 hands down. A lot of the features it had in the very early 90's didn't show up in Windows until WIndows 95 or even 98, and some of the features in it's office suite took until Office 97 to be duplicated. Still, it's horribly outdated.

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. The biggest problem is it's API - it's a lot more difficult to program for than other OSes.

Reply Parent Score: 1

RE[2]: One small? problem
by Robert Escue on Sun 21st Aug 2005 16:23 in reply to "RE: One small? problem"
Robert Escue Member since:
2005-07-08

Geos and Geoworks Ensemble was written in Assembly language, a skill that has almost become a black art due to its complexity and lack of popularity. So I don't think Open Sourcing it is going to help it all that much.

As someone who used Geos in the past on a Tandy 1000 SX and an Epson 286, it worked rather well given the limitations of hardware resources of the time. Unfortunately I don't agree, I think it is an idea that has came and went.

Reply Parent Score: 3

RE[3]: One small? problem
by japail on Mon 22nd Aug 2005 04:34 in reply to "RE[2]: One small? problem"
japail Member since:
2005-06-30

I wouldn't go so far as to suggest that programming in assembly is a "black art," but the "popularity" in the sense that extending a non-portable fringe project is not going to be all that appealing to the stray programmer would certainly be an issue. The overall popularity of programming some assembly, though, is easily greater than programming in Haskell.

Reply Parent Score: 1

RE[2]: One small? problem
by edwdig on Mon 22nd Aug 2005 02:41 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