patchworks Posted April 25, 2008 Author Posted April 25, 2008 (edited) I just discovered an old discussion @ Computing.Net about "Windows files replaced with EOSLX", and the relative OpenWINDOWS project page that claims:Goal is to build a Windows OS and/or GUI that is fully compatible with Microsoft Windows.The way to achieve this is very different than similar projects I found so far.Unlike other projects I make fully use of available software (why recreate when its already freely available?).To illustrate this: I have used no programming skills whatsoever (until now) to get this far. I have just used my knowledge of existing software...The first version that is available here for download I have named OpenWINDOWS version 3.2a.After installing you will have a GUI that is identical to Windows 3.1 from Microsoft, only this one has newer files!Of course it's just a try around Windows 3.1, but hey, here's the prove: it's possible !I must keep in touch with him ! EDIT: I would keep an eye on E/OS LX too... Edited April 25, 2008 by patchworks
SlugFiller Posted April 29, 2008 Posted April 29, 2008 More like the separation of user-mode and kernel-mode code. A crash of a program can easily bring down the system, which very seldom happens on NT systems. Usually the problem in that case is a bad driver trying to do something.What makes you think 98 doesn't have that basic concept of protected mode?I can tell you, empirically, that trying anything you shouldn't be doing with a program quickly results in an exception being thrown. If not caught, the program, and the program alone, closes.Blue screens and other crashes in Win98 are the result of faulty kernel functions, or use of kernel-mode drivers. For example, you can get a blue-screen from ejecting a CD while files are open, due to faulty error-handling in the CD drivers.If there is a "blurring flaw" between modes in 98, its in the fact the memory address spaces of separate processes are not completely separate. Trying to write into another process's memory still causes a protection fault instead of being allowed.If you ask me, though, I think two mode are too few, as third-party drivers may also have flaws, and those should not be allowed to take down the kernel too easily.NT has one, albeit it is not an initial interface, nor can you kill the and return to the command line."cmd.exe" does not qualify as a "command line". It's a terminal, a program emulating a command line in an existing graphic environment. It depends on the presence of Windows to back it up. It is not fully compatible, either, as some programs which may run in DOS cannot run in it. The only way I can run a full-compatibility command-line in NT is with a boot-disk.A goal more likely attainable with ReactOS. It had a command line for the kernel before it had a GUI....Well, you could have just tried it. ReactOS is focused on building a GUI (what is Windows without it?), but it does have a command interface.I'll have to test that. Too bad VMware in 98 is still an issue. Guess I'll look for work-arounds.90% of the problems people have with security on their computers is that they think just like you. If people had to log out and log in as an Administrator, or at least enter a password every time they had to install something, they would think twice before installing something. The security of Linux, Mac OS X, etc... is built around this very simple fact.There are plenty of "sandboxing" paradigms possible. The one used by Linux is by far the worst possible.A kernel, by default, protects all hardware from user-mode access. It may also be expected to protect its driver files and startup information from unauthorized editing. A tighter sandboxing paradigm may entirely limit the creation of executables, or have each process limited to its own sandbox(e.g. within its installed folder).Incidentally, a kernel-sponsored "would you like to access this directory", or "would you give elevated permissions to this program" need not require a password. The Java VM is a perfect example of that. Java Applets can run sandboxed, or they can request permissions as appropriate. More widely controllable permission setting interfaces on a per-program basis could also be an advantage.The Linux sandboxing and permission system, on the other hand, is draconian. It has per-file per-user permissions ingrained into the very file system. To install something you must either log out and log in as the root(which, mind you, opens up the system to more than just that one installation, so that's really a hole rather than an advantage), or use sudo, which is essentially an elevated-rights program to begin with(a concept which also reeks of holes). Additionally, despite the granularity and partition of permission settings it forces on the file system, it still applies an "all or nothing" paradigm in allowing privileged access.In general, its various design flaws would encourage a general user to just run in root all the time. However, even if you automate as much as the log-on process as possible, the multi-user system still leaves too large a foot-print on your system to ignore.A proper, even full-featured, sandboxing system could usually leave almost no foot-print on the system. All it has to do is not be based on users, but on programs and usage instead.Still, last I've checked, ReactOS was far from being ready to use, and still doesn't have sufficient compatibility to even run programs that run just fine on 9x.Of course it isn't. But it is a lot farther along than this "project" will be in any reasonable amount of time. As far as compatibility goes, even Microsoft can't guarantee that, and neither could this "project" of patchwork's.My current 9x runs programs for 9x just fine. Installing KernelEx doesn't change that. Replacing a single dll and developing it to the point where it does everything the original did would take far less time than creating an entire OS, and once it is done it can be used immediately with full compatibility with what the system had before. So, contrary to your claim, by using the existing OS as a base, and focusing on plugging-out one file at a time, usable results with full compatibility can be arrived at much faster than ReactOS possibly could.Okay, maybe compatibility with a few quirky programs would be hard to get at first, but major programs, like Explorer, Office, or common games, would be sure to fully work quite early in the development process.But the makers of ReactOS set out long ago to clone Windows 95, and came to the same conclusion: it just isn't worth it.The key word is "clone". ReactOS, from the get-go, tried to be "from the ground-up". Open-sourcing Win9x could start from the existing system and work one file at a time. This gives much better short-term results, and the solid basis gives a clear-cut "it can't get any worse" compared to the system currently present. Afterwards, the plug-outs can have things like bugs, security, and possible improvements, investigated by a larger open-source community.Instead of patches that add to existing dlls, code-patches the dll sources can be used. What more, the same would be possible for vxds and even win.com, so even files which thus far received no upgrades, official or otherwise, despite the fact that they are not necessarily "in perfect working order", would finally be candidates for improvement as well.
BenoitRen Posted April 29, 2008 Posted April 29, 2008 What makes you think 98 doesn't have that basic concept of protected mode?I can tell you, empirically, that trying anything you shouldn't be doing with a program quickly results in an exception being thrown. If not caught, the program, and the program alone, closes.I don't doubt Win9x has protected mode, but I have to admit it's not as good as other operatings systems'. Just the other day I was testing some new code in my notepad replacement, and I got caught in a blue screen of death loop, forcing me to reboot. This kind of situation doesn't happen often, mainly because the programs I use behave, but rogue programs can take out the system or suck up all the resources (like GAIM 0.73 did for me, ugh).All it has to do is not be based on users, but on programs and usage instead.Hear, hear.
idisjunction Posted April 29, 2008 Posted April 29, 2008 I just discovered an old discussion @ Computing.Net about "Windows files replaced with EOSLX", and the relative OpenWINDOWS project page that claims:If claims were code and mouths were compilers, this thread would have already created what you are looking for out of sheer verbosity.Of course it's just a try around Windows 3.1, but hey, here's the prove: it's possible !No it's not. Look more closely. It requires several files from Windows 3.1. That's no different than jaclaz's minimal Windows. Go snoop around the OS Dev Wiki and find something that resembles an actual free kernel, instead of someone's 15-year-old rescue disk. And I mean that in the nicest way possible. Blue screens and other crashes in Win98 are the result of faulty kernel functions, or use of kernel-mode drivers. For example, you can get a blue-screen from ejecting a CD while files are open, due to faulty error-handling in the CD drivers.Blue screens are far more often the fault of buffer overflows and segmentation faults that the operating system is simply not equipped to deal with. It isn't just drivers that can cause a crash, it's almost any DLL that a program can call."cmd.exe" does not qualify as a "command line". It's a terminal, a program emulating a command line in an existing graphic environment. It depends on the presence of Windows to back it up. It is not fully compatible, either, as some programs which may run in DOS cannot run in it. The only way I can run a full-compatibility command-line in NT is with a boot-disk.Of course it depends on Windows. All other command lines depend on a kernel behind it. CMD.EXE isn't a DOS emulator. It is a true command line, as pure 32-bit applications can be run from it, just like on Linux, Solaris, OS X, etc... How would you quantify the recovery console on a Windows CD, if it doesn't require the GUI to start up? I think your complaint is that it doesn't have enough DOS compatibility for you, not it's actually usefulness for scripts or commands.I'll have to test that. Too bad VMware in 98 is still an issue. Guess I'll look for work-arounds.It also runs in QEMU.There are plenty of "sandboxing" paradigms possible.Except that none of them work. All of them create some sort of "user-unfriendliness."Incidentally, a kernel-sponsored "would you like to access this directory", or "would you give elevated permissions to this program" need not require a password. The Java VM is a perfect example of that. Java Applets can run sandboxed, or they can request permissions as appropriate. More widely controllable permission setting interfaces on a per-program basis could also be an advantage.One of the biggest problems people have with Vista is it's "User Account Control" that demands people approve almost every single action a program takes. The Linux sandboxing and permission system, on the other hand, is draconian. It has per-file per-user permissions ingrained into the very file system. To install something you must either log out and log in as the root(which, mind you, opens up the system to more than just that one installation so that's really a hole rather than an advantage),Like what? iptables aren't switched off when you log in as root. Programs that you haven't previously installed can't install themselves. or use sudo, which is essentially an elevated-rights program to begin with(a concept which also reeks of holes).The only "hole" is the one in the idiotic user's head. How hard is it to create an executable that silently installs itself and modifies system files in 9x? At least if the user was prompted for a password, he'll have enough time to think and say "Hey, wait! Text documents don't need to install anything! And if you think that can be fixed by just having a box pop up that says "Ok" and "cancel", then let me tell you that most users just click "Ok" for everything automatically. If they associate passwords with installing programs, though, there will be far less risk (except from trojan horses, but there are other ways of dealing with those).Additionally, despite the granularity and partition of permission settings it forces on the file system, it still applies an "all or nothing" paradigm in allowing privileged access.Different programs and users can be given different rights.In general, its various design flaws would encourage a general user to just run in root all the time. However, even if you automate as much as the log-on process as possible, the multi-user system still leaves too large a foot-print on your system to ignore.And how is Windows any different? Most Linux distributions will warn right off the bat never to log in as root. Windows actively encourages it by making the default user an Administrator, instead of giving him a normal account and have him specify a separate system password. And no, a multi-user system does NOT create enough of a performance overhead that can't be fixed by efficient coding. There were multi-user systems long before the average individual could afford their own computers.My current 9x runs programs for 9x just fine. Installing KernelEx doesn't change that. Replacing a single dll and developing it to the point where it does everything the original did would take far less time than creating an entire OS, and once it is done it can be used immediately with full compatibility with what the system had before. So, contrary to your claim, by using the existing OS as a base, and focusing on plugging-out one file at a time, usable results with full compatibility can be arrived at much faster than ReactOS possibly could.Name ONE operating system that was developed in the way you describe. All free operating systems in existence have been developed primarily by starting with a kernel and developing the APIs around it. Okay, maybe compatibility with a few quirky programs would be hard to get at first, but major programs, like Explorer, Office, or common games, would be sure to fully work quite early in the development process.You really think Wine wrote one DLL to its entirety, then moved on to another? No. They started with several of them, and worked on all of them to get even one application working.The key word is "clone". ReactOS, from the get-go, tried to be "from the ground-up". Open-sourcing Win9x could start from the existing system and work one file at a time.No you can't. The different DLLs are entertwined. They rely on each other. Different versions of DLLs even from Microsoft cause problems when used together.This gives much better short-term results, and the solid basis gives a clear-cut "it can't get any worse" compared to the system currently present.No it doesn't. The code necessary to make a free and open source DLL work well with a proprietary one is a lot more than is necessary to have a working program. Wine's DLLs are good enough to run a vast majority of programs, yet they can't be used as drop-in replacements.
patchworks Posted April 30, 2008 Author Posted April 30, 2008 (edited) Of course it's just a try around Windows 3.1, but hey, here's the prove: it's possible !No it's not. Look more closely. It requires several files from Windows 3.1. That's no different than jaclaz's minimal Windows.Well you have to read better my Open Sourcing 9x (GNUWin) idea, then.As alredy said many times before, we're not discussing about a rewrite from scratch (as ReactOS), but how build a tool that strip down 9x components with open softwares (where possible).Freedos+Seal Gui or FreeGEM gui or Sword Gui = Some kind of an Windows Clone Again, guys: this project idea has a different point of view/start !1. You *need* an installed version of MicroSoft Windows 9x;2. You *need* a fully functional internet connection;3. You must donwload/install a project package manager;4. Package manager downloads alternatives and substitutes official components.This approach means that we don't have to start "from scratch", but we just need the package manager, the "upgrades server" and the open source alternatives (and not all actually, the hunt could be dynamic...) Edited April 30, 2008 by patchworks
jaclaz Posted April 30, 2008 Posted April 30, 2008 If claims were code and mouths were compilers, this thread would have already created what you are looking for out of sheer verbosity.Agreed. No it's not. Look more closely. It requires several files from Windows 3.1. That's no different than jaclaz's minimal Windows.Actually it is MUCH different, as the scope is completely different.The idea here:http://www.jankie.net/soedesh/20.htmis very similar to PatchWorks one, i.e. re-creating an OS, though what this thread essentially represents is simply an attempt to updating/bettering of Win9x, not unlike much of the other projects here on MSFN with a similar scope and with a less deceiving title.The idea behind minibox is just that of creating a MINIMAL system to boot to and copy/move/rescue some files in a friendlier environment than pure DOS command line, using files included in any win9x install CD and freeware/public domain/open source alternatives for the original files from Win3.x, you could see it more as a very basic "Win 3.x/9.x BartPE" rescue bootdisc.There is NO ambition whatsoever to recreate a "real" operating system :http://www.boot-land.net/forums/?showtopic=623&st=6Minibox needs NO additional files if a DOS box is not needed, and only 1 (one) file is missing: WIN386.EXE, if a DOS box is needed, a file, mind you, that it is composed by several "bricks" of which we already have a few.In other words currently to run a dos app you need to exit the GUI, run the command line utility from pure DOS, then re-start the GUI, a method that, though easily scriptable is FAR from being handy. :whistling:The fact that in two years:http://www.911cd.net/forums//index.php?showtopic=16754http://www.boot-land.net/forums/?showtopic=623noone with the "right" knowledge came out with a solution should mean that the project, while being fun and useful to learn quite a lot of "old" tricks, has no future and a very limited "geekish" audience. jaclaz
patchworks Posted April 30, 2008 Author Posted April 30, 2008 (edited) is very similar to PatchWorks one, i.e. re-creating an OSJac, you're italian too, so please don't misunderstood the goal: Open Sourcing 9x(GNUWin) idea IS NOT about recreate an OS, but to open an existing one (again, it's not the same !)Let me see, how can i explain better: a sort of online service pack but with open components. Is it more clear ? Edited April 30, 2008 by patchworks
jaclaz Posted April 30, 2008 Posted April 30, 2008 It is perfectly clear, thanks, when you quote, you should quote integrally:is very similar to PatchWorks one, i.e. re-creating an OS, though what this thread essentially represents is simply an attempt to updating/bettering of Win9x, not unlike much of the other projects here on MSFN with a similar scope and with a less deceiving titleIt's all a matter of definitions, I will call this (or whatever other project) Open Source only when and if it will be INTEGRALLY composed of Open Source components (and NO, Public Domain, Freeware, Freeware for personal use, freely available is NOT Open Source).This project, by your own definition, is aimed to "assemble" a number of alternative software to sustitute, replace or integrate original components, and needs to be run on a fullly licensed OS.Until even one single file will be under the MS license, this will not be Open Source, even if only 0,01% is from MS you need to have a valid (commercial) license to use it.All the point about Open Source is having the right to see what is inside the program you are going to compile and execute, and, if needed, modify it to suit your particular needs.The fact that most Open Source software is available for free is incidental, as well as the fact that generally, but not always, Open Source software is "better" than Commercial or more generally Closed Source one.So, I appreciate your effort, and as said partly agree with it's reasons and aims, but I like to call things with their names.jaclaz
SlugFiller Posted May 1, 2008 Posted May 1, 2008 Blue screens are far more often the fault of buffer overflows and segmentation faults that the operating system is simply not equipped to deal with. It isn't just drivers that can cause a crash, it's almost any DLL that a program can call.Buffer overflows in user-mode programs cannot cause blue screens. Verified. If you try to write into "no mans land", an exception is risen. If uncaught, a general protection fault closes your program.As for DLLs, if loaded from a program they would not cause that. If loaded from the kernel (e.g. User32.dll), they are drivers, and may be considered a part of the Kernel.What a program can load to bring the system down is a vxd, which is essentially a kernel-mode driver. Mind you that this is possible in NT as well, although using different methods. The result is the same.CMD.EXE isn't a DOS emulator. It is a true command line, as pure 32-bit applications can be run from itI didn't say it is a DOS emulator, I said it is a command-line emulator. A true command line runs in text-mode. In 9x, a virtualization layer translates the text into a graphical display, as it does for dos programs. "cmd.exe", on the other hand, is quite aware of the graphical console and the fact that it is in graphic mode. It is a terminal. The fact that it runs 32-bit application would only demonstrate that farther, although "command.com" also does that thanks to virtualization of int21h.Rather than consider it's performance with 32-bit applications, I would consider the sort of trouble it can have with 16-bit ones.It's a terminal, not a command line - a graphical program that knows it's a graphical program and simply allows text input like a command line but without actually being in text.How would you quantify the recovery console on a Windows CD, if it doesn't require the GUI to start up?"A second OS"? The recovery console is not a part of NT. It's a part of the installation CD. If it was installed along with Windows (non-optional), it would qualify. Well, somewhat, at least.It also runs in QEMU.And what does QEMU run on, smart-a**?I'll try the "Windows port", though I'd have higher expectations from Bochs.There are plenty of "sandboxing" paradigms possible.Except that none of them work. All of them create some sort of "user-unfriendliness."Again, hello: Java VM. Works 100% last time I used it.Only problem is, Java is not an OS, it is an environment that settles on top of other OSs. Perhaps that's why it's design is so good: They knew it can't be as all-controlling as an OS, since it has to share its space with an existing OS, so instead they came up with a more minimal but effective design. OS developers should learn from that design.One of the biggest problems people have with Vista is it's "User Account Control" that demands people approve almost every single action a program takes.I have a similar grief with popular firewalls. Still, how is having to log out and log in as root, and enter a password, better than this?Like what? iptables aren't switched off when you log in as root.But it can suddenly be overwritten. In fact, when you switch to root, all of the defenses you had when being not root suddenly disappear. Rather than getting access to one folder to install your one program, the installer suddenly has access to everything everywhere. An "all or nothing" strategy differs from "nothing" only in being more annoying. In that case, I might as well just have "nothing".or use sudo, which is essentially an elevated-rights program to begin with(a concept which also reeks of holes).The only "hole" is the one in the idiotic user's head.I was referring to the possibility of having an elevated-rights program.How hard would it be to bundle an installation with some other elevated-rights program that doesn't require any confirmation, let alone a password? After that random programs can elevate themselves at will, giving you the same condition as an unsecured system. Well, not exactly the same condition, since legit programs will still be a bother to install and use.As for idiotic users, if you're smart enough to get Linux running, you're smart enough not to run worms.At least if the user was prompted for a passwordRight there you assume Linux consistently does that right. It doesn't, that's not how its sandboxing system works. Only specific scripts know how to sudo for things they need. If you so much as want to copy a program into /usr/bin, assuming you'd rather use a graphic file explorer rather than cp, you'd still need to sudo the file explorer.Besides, even if you desire a password, you don't need an account system integrated into every file to do that, you just need an administration password (just like for your BIOS). You know, one that isn't associate with a username, just with the general concept of "having access".Additionally, despite the granularity and partition of permission settings it forces on the file system, it still applies an "all or nothing" paradigm in allowing privileged access.Different programs and users can be given different rights.No. Different users can be given different rights. Different programs can be given different users. Making overlapping but not equal rights is down-right impossible. You do get the "grace" of 3 levels - root(=all rights, if you can call that a level), group, and user. If all of your overlaps and use-cases are so clearly defined that these would do, then you're in the clear. Generally, though, it won't exactly work like that.There are too many resources that need to be given or denied access to from different programs, and they are not cascaded: One program may require files and internet, another internet and sound, and yet another files and sound, and you don't want one using a resource it shouldn't.And how is Windows any different? Most Linux distributions will warn right off the bat never to log in as root. Windows actively encourages it by making the default user an Administrator, instead of giving him a normal account and have him specify a separate system password.Not saying that Windows is more secure, or encourages not having full right. Only that if you're going to always be the root anyway, there's no reason to pay the overhead involved, and Windows allows that. Linux does not.And no, a multi-user system does NOT create enough of a performance overhead that can't be fixed by efficient coding. There were multi-user systems long before the average individual could afford their own computers.Okay, stop right there.Breath. Count to ten, then re-read what you wrote here.Let's try this again: Re-read the last 9 words.You just said it outright: Linux is for servers, not individuals. Multi-user systems in personal computers are left-over debree from when all computers were servers. It's intended for server-use only.Incidentally, servers are usually super-computers anyway, and waste a lot more overhead on logs and, you know, client-server access, to care about the cost of having a multi-user system.For a personal computer, having "root -rwxr--r--" appended to each file is not acceptable overhead. It should not be there to begin with.Name ONE operating system that was developed in the way you describe. All free operating systems in existence have been developed primarily by starting with a kernel and developing the APIs around it.We're not developing an OS here. If we were, there are much better paradigms than cloning Windows. In fact, I've designed my own paradigm that puts all existing OSs to shame. It has the unfortunate flaw of requiring years of development to be accomplished.The title of the thread, if you'll note, is "Open Sourcing Windows 9x". In other words, it's about taking an existing OS, and re-making it as open source. It's sort of an "upgrade", if you will. A "hotfix" to that nasty bug of it being closed-source (well... and crash-prone).Given that, starting from the existing version and altering it to open source step-by-step is a perfectly legitimate way to go about it. Well, as much as "legitimate" applies here, considering copyright laws.You really think Wine wrote one DLL to its entirety, then moved on to another? No. They started with several of them, and worked on all of them to get even one application working.Exactly. They needed many DLLs just to get a working start, which took a lot more work just to get an alpha version. And even after that they don't have reasonable compatibility.The ability to have the unofficial DLLs integrate with the official ones would make the process both faster and more compatible. You only have to worry about the compatibility of one DLL at a time, and all programs already work due to the support of the existing official DLLs.No you can't. The different DLLs are entertwined. They rely on each other. Different versions of DLLs even from Microsoft cause problems when used together.Your entire argument here relies on the last sentence which is false. My current installation is a mix of DLLs with a very wide variety of versions. It's a localized Windows using US drivers and security updates. Most of the VXDs have been replaced with versions that, according to you, should not work.The only "intertwining" I've noticed is of "user.exe" and "user32.dll", which cannot be replaced with non-localized versions. I've even made a thread about not being able to update these two for that reason. Quite frankly, these are the two I would start with, since an open-source variety would finally give me the chance to replace them with "universal" ones.Alternately, by just sticking to all other DLLs(Kernel32, GDI*, AdvAPI32) you can avoid any incompatibilities.Of course, the replacement DLL would need to implement all functions on the alpha release, but that can be alleviated with stubbing (keeping the official DLL for relay calls on yet unimplemented parts of the API). Still, getting the API of a single DLL done right is much easier than trying to get the entire Win32API right at once.The code necessary to make a free and open source DLL work well with a proprietary one is a lot more than is necessary to have a working program.Depending on how much of the program you want to run. If you have a DLL to is fully compatible with the DLL cross-requirement, you know it will also work with any program. The fact is, many programs still don't run in Wine, or only run partially, or run for a while and then crash.Maybe the full export table of a single DLL is larger than the full import table of a single program, but take 5 or 6 programs together and suddenly you have an overturn.This may not seem like a fair comparison, but consider this: If you have a partial API the fully runs a program, but still fails to run several of your program, or even one of your favorite programs, it's just not ready for regular use. On the other hand, if an entire only manages to plug-out a single DLL, it still has its own worth. And since the plug-out of that single DLL does not prevent even one program from working, you can use it right away with all of your programs, and never have to go back to the original DLL. In other words, one plugged-out DLL has more use than a system supporting 5 programs.
Sfor Posted May 2, 2008 Posted May 2, 2008 Well, acces rights, user controll. This is a "military base" language designed for a war with the world. On the other hand Windows 9x is a "home like" system. We do not like to enter passwords in order for being able to change something in our homes, or do we? That's why the minimal internal security system is so pleasant to live with. If the communication software used in Windows 9x will be safe enough, the system will have good enough safety for most. So, changing the security system means to leave the "heart" of the design and to move from a household to a military base.As for the whole opensourcing idea. Replacement of the most bugged components is the most logical point of action.The OpenOffice project has a quite interesting bug tracking system. It's quite unpleasant to use, but it has a possibility to vote on bugs. It is possible to determine what users whant to change, that way. Such a system could be quite a nice start for a project aimed in improvement of an existing OS.My pockets are empty at the moment, but these few cents can be of some use, I hope.
Recommended Posts