GDI.dll and GDI32.dll to replace the "GUI" Abbreviation

[~]

I was just meditating about implementing a GUI and adding some WinAPI functions to cover the GUI subsystem in a standard way (given that Windows is a graphical shell for DOS).

Then I realize how many decades have passed before noticing that "GDI" is a replacement for "GUI".

So supposedly all graphical interface primitives are contained in GDI.dll or GDI32.dll

It could have been called GUI.dll



__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
By the way, it would have been so much healthier to distribute Windows as a BGI driver (and other drivers) that users could use freely instead of locking the users out of their own hardware and DOS/BIOS shell.

Even Linux is limiting from the point of view of hardware programming. It means that Linux is primarily a network OS with very strong security features for local and remote access. It should be more flexible by being able to be launched even from a DOS version and exit back to the DOS or the boot loader shell in Real mode without restarting even for tasks like simple hardware initialization to coexist with other OSes.

So it seems that the best platform is a combination of DOS/Win9x/WinNT/UNIX, with the intention to keep a platform that allows full hardware access and that at least can help initialize hardware (it gives questions like, how to leave Windows or Linux in the middle of its execution to another OS but leaving the devices active?... It can probably be achieved with a kernel-mode module, and likewise re-booting the previous OS).

Then there could have been other GUIs. Even Mozilla, Autocad and everyone else would have developed their own GUIs, and now GUIs would be based purely in HTML5, not in Windows/WinAPI.

Now we can see the importance that knowing how to implement a GUI has.

It allows for a simpler environment.

And using/loading different programs to disk as with old programs has nothing to do.

There could always be a multitasking "driver" to launch several WinAPI and non-Windows systems simultaneously and natively.

Direct hardware access with no restrictions at all is a feature that is sorely missing in modern OSes, but it should be possible to enable or disable hardware protection to access devices without worrying about drivers.


So any capable OS that allows direct manual hardware access intrinsically as an architectural behavior (DOS, Win9x) is ideal for system programming, for system-level and advanced users, and for heavy development where developing is important but not user-login-level security.

Linux is ideal, first for servers, and then for any user-level application imaginable, although its code and that of its programs isn't so clean yet. It shows that it gives more value to a multi-platform code base, but not much to the underlying hardware while it's running. It's really not oriented to system programming, even though it has all tools and source code to compile itself, but it can still be improved and is far from ideal to build other systems with ease.

Windows NT/XP/7/8/10/etc. is no longer ideal for system development but to program web applications, for gaming, as an office and home OS, and as a general use OS, but it locks users into not being able to use the previously expected unprotected level, which is MS-DOS. Now we can never leave Windows XP not even when repairing it (the install disc must repair the system without relying on DOS but in a limited NT console, so OS programming is pretty much dying since Windows XP at the Windows platform side, although the destructive polarity of the way of thinking of this problem is reverted if we use Windows 98 SE or earlier).



___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
___________________________________________________________________
So we need a platform, a system that isn't really an OS but a lot of system binaries and libraries that the applications can use, just like old programs that would have been as good as the current ones if the programmers of that time would have had more modern and capable machines. Those applications would need to be portable. It would also make a little harder to accidentally let viruses enter because we would define very well as objects that an user can understand, even the BIOS, the boot sectors and all modules (users and diagnostic programs would get used to verify that the parameters of all modules and systems elements really are what they should be, or notify the user -maybe replace with the expected default element and back up the unknown suspicious one to disable and prevent it from keeping a damaging effect-, and always build programs from fresh sources to overwrite any undesirable changes to executables).

But after all, this sort of system combination is ideal for real system-level programming where testing a bit of every sort of programming (OS, hardware, user programs and document, etc...) is the most important thing. Of course it would be functional but won't give as much importance to user-login-level security because it would be a mostly academic platform for very advanced users and also to later port very portable code to any other OS.

This is what is lacking and what should be implemented. It's a sort of set of OS libraries that don't really lock an user to mostly use it but it would simply be a bootable program to run applications which depend the least on external resources.

[iansjack]

Windows is a graphical shell for DOS

Windows is not a graphical shell for DOS. We should try to stick to documenting true facts in this Wiki, not some wild misunderstandings.

[Boris]

Windows 3.10 could be started on the top of DOS .
It feels like a shell , but it's not.
DOS back then was just a ribbon wrapping the BIOS.
Proof ? You could back them start a Linux kernel in a C:\> prompt using this tool

https://en.m.wikipedia.org/wiki/Loadlin

[~]

Windows is a graphical shell for DOS

Windows is not a graphical shell for DOS. We should try to stick to documenting true facts in this Wiki, not some wild misunderstandings.

In practice it is, since Windows 1 to 3 and specially Windows 9x (and NT should also be), but for commercial reasons it locks users more and more out and away from DOS and an unprotected hardware environment. It's an illusion that OSes aren't basically shells to increasingly simpler environment just because they don't allow returning to them natively.

It is healthier to allow systems to return to DOS for unprotected access. In this way the user is allowed to use his or her hardware at will if they happen to be low-level-capable developers in need of the freedom by lack of protection that older systems allowed, always like DOS/Win9x.

_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
I see how GUI examples around like that from Ben Lunt's book about GUI is in fact a graphical shell for DOS.

If we add a little WinAPI, enable LFN for DOS and create a virtual graphical text console for running DOS programs, we would have an old Windows version in our hands.

It would be a GUI shell for DOS, despite having WinAPI, although each program could implement its very own and internal GUI subsystem while using the system drivers shared by all programs, or implement them and embed them in the application too if they happen to handle standard hardware.

DLL libraries should be easy to load into an application from DOS without having to load the whole Windows but just what makes each application run.

It should be something documented being able to use Linux or Windows like scattered libraries from a DOS loader (just a few DLLs or system libraries per program); or launch them directly/from DOS as full-fledged OSes. It would make everything much lighter and organized.
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________



Those programs could also start the GUI as happened with Windows 3 when you tried to launch a Win3.x program from the DOS console, so Windows is originally a GUI shell for DOS for CLI and GUI programs that could well be distributed as a BGI driver (WINDOWS.BGI).

Even ReactOS could feel excellent for hardware and system programming if it released its permanent hold on the machine and if it could be launched from FreeDOS (WIN.COM) and if we could exit to DOS mode from the ReactOS GUI.

That would turn it into something similar to an open source Win9x with the NT APIs and drivers...

Add native SATA drivers to FreeDOS (integrated into the kernel for it to boot and also loadable to make them upgradable) and we are all set with a modern DOS with a graphical WinAPI shell. Also make global direct hardware access possible to enable or disable for ReactOS and we have a really nice developer tool.

[Rusky]

Windows is a graphical shell for DOS

Windows is not a graphical shell for DOS. We should try to stick to documenting true facts in this Wiki, not some wild misunderstandings.

In practice it is, since Windows 1 to 3 and specially Windows 9x (and NT should also be), but for commercial reasons it locks users more and more out and away from DOS and an unprotected hardware environment.

No, this is completely wrong. Since NT, Windows has had nothing to do with DOS- it's not a layer on top, it stands completely on its own. And with UEFI, it is no longer even dependent on the old BIOS for booting (not that using the BIOS in the bootloader makes it a shell in any way). It's also got nothing to do with "commercial reasons"- Linux works exactly the same way.

You seem completely unaware of how protected and long mode kernels work. Once the machine and OS are in that mode, the only reasonable way to go "back" to DOS is to reboot and then go a completely different direction in the boot loader - for technical reasons, not commercial. And nothing's stopping you from doing that right now.

[~]

They have several things to do like running DOS programs, DOS commands, using drive letters, backslashes and short file names, but it really feels more comfortable to load other OS from DOS instead of only from boot loaders to then get trapped forever in the same environment that cannot allow direct hardware access because it cannot be enabled anywhere.

Things would be much easier if Linux and Windows allowed fully disabling the restriction to access hardware directly. If you are developing OSes and programming hardware you will need to disable it.

It will always be also necessary to have a BIOS shell which DOS is, for launching easily any other OSes and make it all portable, standard, simple, and to make hardware programming tests with no prior initialization by ourselves.

And with UEFI, it seems that it has actually become easier to go back to Real Mode and implement and patch UEFI with a generic GNU BIOS and then start DOS (and add SATA and UEFI support to DOS... it's possible and the least work pending about it). Now there are no longer reserved BIOS areas so it should be easy to just patch and disable UEFI (maybe still treat it like an expansion ROM for the video BIOS and other similar functions), then install a standard open-source BIOS on the first empty Megabyte (knowing that now we come from UEFI with a patched BIOS system).


If DOS and the BIOS can be used as launchers, why not do the same and do something like write a kernel-mode module and from it interrupt Windows (or Linux) and exit to any other OS, like DOS or our own OS without rebooting? Maybe it will leave hardware initialized in some cases and using initialized devices from there could be easier. So starting Linux or Windows would only be done to initialize hardware for our OS as a hack (now we just need to reconfigure the CPU mode and other stuff carefully, but forgetting about the OS that was running).

That would be an advantage to fully enable direct hardware access... we could even switch OSes in the middle without rebooting.

[Rusky]

If what you really want is direct hardware access, just write drivers. You can do that on both Windows and Linux, without resorting to the giant mess that is the old BIOS, let alone DOS (which, again, NT is not related to, code-wise).

[iansjack]

Windows is a graphical shell for DOS

Windows is not a graphical shell for DOS. We should try to stick to documenting true facts in this Wiki, not some wild misunderstandings.

In practice it is

However many times you repeat an obviously false statement, it still remains false. You do yourself a great injustice by constantly making these incorrect statements.

Better to keep your mouth shut and be thought a fool than to open it and remove all doubt.

[iansjack]

It will always be also necessary to have a BIOS shell which DOS is, for launching easily any other OSes and make it all portable, standard, simple, and to make hardware programming tests with no prior initialization by ourselves.

You venture ever further into the reams of the ridiculous. Are you sure that this web site is the right one for you?

[Kazinsal]

Better to keep your mouth shut and be thought a fool than to open it and remove all doubt.

As appreciated as the aphorism is, I don't think he's going to listen to anything short of a suspension of posting privileges.