FWIW a two digit amount of MB is usually at least 16MB (though with low hundreds of MHz it was probably at least 32MB if not 64MB) and most such systems could easily do 1024x768 at 16bit, 24bit or 32bit color. At least my mid-90s PC could :-P (24bit color specifically, i had some slow Cirrus Logic adapter that stored the framebuffer in triplets of R,G,B, probably to save RAM but at the cost of performance).
Open source software also needs a stable ABI because:
a) i don't want to bother building it over and over (not everything is in my distro's repository, a ton of software has a stupid building process and not every new version is always better than the old versions)
b) a stable ABI implies a stable API and even if you have the source, it is a massive PITA to have to fix whatever stuff the program's dependencies broke to get it running, especially if you're not the developer who made it in the first place
c) as an extension to "b", a stable API also means more widely spread information/knowledge about it (people wont have to waste time learning how to do the same tasks in a slightly different way using a different API), thus much easier for people to contribute to software that use that API
There is also UMU Launcher[0] which is basically all that without the Steam integration/dependencies so you can run games from GOG and other stores (it is a command-line tool but launchers like Heroic can use it behind the scenes). I used to install dxvk, etc manually but in recent months i switched to it as it tends to work much more seamlessly for games (i did disable its autoupdates though).
Wine devs do not want to work with people who have looked at ReactOS[0] (see at the end) so any collaboration is one-way (or by ignoring the guidelines) and the likelihood of the two projects merging is zero.
Surprised no one responded to the 7th comment in that linked email thread, the author brought up a good point about making progress without using any disassembled windows binaries.
> One could argue DRI bowed out too soon. Then again, it’s questionable whether it would have won against Windows anyway. Microsoft was the larger company and had OEM agreements with all of the major PC makers.
Well, it is also that Windows even at version 1.0 was much more capable than GEM. Better documentation, better tools, better API and better functionality.
GEM was really just a shell over DOS and applications were actually DOS programs that called a special interrupt handler to make API calls. While this allowed any language that could make EXE files and call interrupts to be used to make GEM apps, it also meant that GEM inherited all the limitations from DOS, like the inability to run multiple applications at the same time (DR did eventually make GEM/XM that allowed switching between applications but it was still only one application active at any given time). Windows meanwhile not only could run multiple applications, but it also had a software-based virtual memory system that allowed applications to swap in/out both data and code to fit in the available memory (this required custom compiler support so, unlike GEM, you couldn't use any old compiler but on the other hand it you could make more complex applications).
The GEM API was also very barebones, you could create windows but all you could do with them was to draw inside. Dialog boxes were a completely separate thing that could take a tree of "objects" to draw inside them but even then the functionality was limited (the object types are hardcoded and while there is a "custom" type, all it does is provide a callback for drawing). You could work around some of the functionality by implementing some of it yourself - for example there is a call to draw an object tree (object trees are actually a flat array of fixed size structures where the first three fields define 16bit indices inside the tree for each object - this probably saved some bytes of memory at the cost of flexibility loss and TBH the extra bytes added for the code to work with the tree probably ate back those saved bytes, if not made things worse) so i think (never tried it) you could draw buttons, etc in a window when you receive the WM_REDRAW message but there is no event message propagation.
Meanwhile on Windows everything is a "window" in a window tree with a consistent approach to how things are handled. On GEM everything is a special case.
I get the impression that the GEM developers basically had some idea of what their desktop would look like and implement the functionality to do just that and nothing else with little room for flexibility or later expandability.
EDIT: also the graphics functionality was very limited, e.g. with hardcoded colors. Here are some GEM API docs in case anyone is interested:
Atari ST user here. AES is as you say rather bare bones. In some ways it's more analogous to X windows "Xt" X intrinsics than it is to any "widget" toolkit -- in that it gives you the facilities for constructing trees of drawn objects, registering applications, communicating between applications, receiving events, opening windows, redrawing windows, etc. but for actual active widgets ... only provides premade alerts, dialogs, windows, menubars, and a file selector. But in fact those pieces are made from object trees like you say. So, yes, with your own event handling you absolutely could write your own widgets directly into the window by drawing an object tree, and more savy developers did that.
I suspect there was maybe an intent to eventually build something higher level above it, still. Just that never happened, or was never standardized. There are in fact some C-level libraries for the Atari ST that do, but they're more recent inventions.
It's not a bad architecture, just incomplete. It wasn't aiming for -- nor would they have had the budget to make -- the same space as MS Windows in that it wasn't a full and complete environment in that way. Even on the Atari ST where they controlled the whole stack instead of being hoisted over MS-DOS.
You can do a lot of stuff with the system as it is since it does expose a lot of its internals (and when you need to replicate functionality, there isn't that much in there to replicate so it is perfectly doable), but my point is that it wasn't as flexible or capable as Windows 1.0.
It wasn't just Microsoft's marketing skills that made Windows overshadow GEM, it was also that Windows was genuinely a better product - both from a technical and a functional perspective.
There have been a couple of GCWZero clones made in more recent years (e.g. from Anbernic) running the same (or a derivative) Linux-based OS with JZ4770 MIPS SoC and software compatibility. Too bad Ingenic never released any successor to the SoC though.
I don't think i ever have something fully maximized (aside from games, though even then sometimes i play in windowed mode). Even when i do maximize a window (which isn't often but some programs like Krita work better like that), the dock and miniwindows (i'm using Window Maker as my window manager) still take their own space and the background shows through. Also i often have a bunch of terminal windows minimized, then i forget about them and open new ones until at some point i go and garbage collect them :-P
Been auto-hiding the taskbar since Win 95, and feel the need for the feature all the more with the macOS dock. I doubt I’ve spent a collective hour without auto-hide on the dock in more than a decade of macOS :-)
One neat bit with Codeberg however is because they're using (actually developing) Forgejo (a Gitea fork which itself is a Gogs fork) you can easily clone the entire thing locally or on your own VPS to have as a backup.
Forgejo is even trivial to set up as it is a single self-contained binary you can throw somewhere and it'd work.
If this is a real issue, it seems to be an issue with the way a particular toolkit handles visual WYSIWYG editors. Lazarus serializes the object properties into a simple and readable text format that follows the class declarations themselves and you can easily diff them. E.g. here is the diff of a minor change i did (added a new button in a panel with an event handler and modified a property in an existing button):
I swear I meant to write an "often" in my previous post. But yeah, that was largely directed at the interface builder in xCode, for iOS - it gives you storyboard/xib files that are effectively-not-human-editable (and entirely non-mergeable) xml.
IMO WinForms didn't manage to reach even Delphi 2's state, so i'd say it is far from peak considering the improvements later Delphis (and now Lazarus) added. It was abandoned too soon.
reply