GDI.dll and GDI32.dll to replace the "GUI" Abbreviation
Posted: Tue Jul 19, 2016 2:40 pm
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.
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.