On Wed, Jan 11, 2012 at 5:36 AM, Michael Robinson <plu...@robinson-west.com> wrote: > The problems encountered strapping a GUI onto a DOS system are similar > to the problems that were encountered when object orientation and > classes were added to C to create C++. C++ is really a hybrid language, > neither a strictly procedural nor a strictly object oriented language. > > Any GUI strapped onto a DOS environment will seemingly make it a hybrid.
Please recall that DesqView, DesqViewX, GEM, and Windows through 9.X were precisely GUIs strapped onto a DOS environment. (Win98 used DOS as a real-mode loader, and once it was up, DOS was out of the loop and Windows *was* the OS.) DesqView and Windows even provided multitasking. They did their own time slicing, and served as dispatcher, serializing access to the underlying OS functions. > All dos environments share the following problem: > > Multiple users requires permissions on individual files and resources to > keep users from walking all over each other, if such a thing is wanted. > DOS environments only have a superuser. So, DOS environments are single > user environments. Change DOS so that there are permissions on files, > FAT filesystems present a real problem since they predate permissions on > files. Many programs that expect uninhibited access to everything and > anything won't work. The best you can do is run Linux or something even > more secure underneath DOS via DOSBox. Each user has his/her own DOS > system. If you *have* multiple users, you *don't* have a DOS system. it is explicitly single-user, and presumes the user at the machine is the administrator. Windows kept that model through XP, and only made substantial changes in Vista/Win7. Part of the problem is the file system. FAT provides no place to store the required permissions data. Windows didn't really get it till NTFS. > Nowadays with companies greedily protecting their intellectual property, > can you access hardware directly if you don't know what's there? Can If you *have* a multi user, multitasking OS, you don't *want* to address the hardware directly. The process attempting to do it *cannot* assume it's the only thing running, which was the case under DOS. And in the DOS days, addressing the hardware directly was for performance reasons. The usual direct address was the screen, and the usual reason to do it was something like a game where BIOS updates would be too slow. > you use a software library to access that hardware via a well known > interface from your favorite OS? Does it ever make sense these days to > have direct hardware access without the user abstraction? Yes, for the reasons mentioned above. It depends on how you implement a DOS system. If you have something like FreeDOS installed so you can boot directly into it, a virtual machine solution like DOSBox under Linux isn't in the picture. You *can* directly address the hardware, and your programs may try to. The challenge placed by things like DOSEmu is that the class of programs they were designed to support (games) *did* try to address the hardware, and DOSEmu needs to make the program think it *has*, even though something else is actually handling things. > If DOS itself is in ROM and you are building a kiosk... maybe then if > you can directly access the hardware DOS does make sense. Even a GUI on > a DOS kiosk might make sense. What doesn't make sense is a DOS system > that is supposed to be usable by multiple strangers where the system is > not in a ROM but on a writable hard disk. Insofar as a graphical user > interface can limit what can be done and make it easier to do what is > intended, such an interface will make sense. So a version of DOS with > no command line per se outfitted with a GUI could make a nice kiosk > system. But if direct hardware access is improbable or software library > access of hardware is impossible outside of say Windows 7, you are in > trouble even if the target system is a Linux system. Why are you assuming said DOS system will be accessed by multiple strangers? For things like FreeDOS, there will be a single user who installs it in the first place and runs it after it is. While it's theoretically possible to set up DOS in a VM so that different users have different DOS systems, t's far more bother than it's worth. If I am setting up a kiosk, DOS is *not* what I'll use. There are three issues being conflated above: multiple users, multitasking, and GUIs. They are separate issues, and for a DOS system, the first doesn't even need to be considered. It won't be used that way, and even if it is, it will be the same way DOS systems were used back before GUIs came on the scene: one user at a time. You won't have the issue of more than one person/process trying to update the same filesystem at the same time and stepping on each other's toes. What is being discussed here is the last: a GUI. There are reasons a GUI may be desireable, and I'd be delighted to see a supported solution for FreeDOS. It would be nice if it were multitasking, too, but that's likely too much to hope for. ______ Dennis ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
