h a l f b a k e r yLike a magnifying lens, only with rocks.
add, search, annotate, link, view, overview, recent, by name, best, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
One of the things about the Windows Operating System is that it "abstracts" the hardware from the application software.
The operating system offers a set of utility-functions for
applications to use, meanwhile builders of hardware write
appropriate drivers that must match the business-end of those
utility-functions. If there is any good thing at all about Microsoft's desktop-monopoly power, it is that it forced much of the hardware out there to become more compatible to the software. Everyone who wanted to work with the Windows Operating System had little choice.
So, the current situation is that most any application can work with most any hardware, because all those applications call Windows utility-functions the same way, and all hardware drivers also have to work with those functions. That grouping of utility functions is sometimes known as the "Hardware Abstraction Layer". The specific
features of each piece of hardware is abstractly made to
work the same way, as far as the applications are concerned.
WELL THEN:
There are a lot of people who don't like Microsoft's monopoly of the desktop. Worthy alternative operating systems, such as Linux, BeOS, "Macintosh", or you-name-it, have trouble
gaining market share because very few major applications/ software will work with those operating systems. SO, suppose we created an Operating System Abstraction Layer!
This layer of software would provide essential features for any application to call, and it in turn would call the equivalent veatures of the underlying operating system, regardless of what that OS really was.
A specific example of such an attempt is known as WINE, which tries to allow any Windows application to run on Linux. However, WINE is a SPECIFIC and not a GENERAL solution. I submit that it would be best to have a general solution.
Imagine an International Conference For Operating System Abstraction. Microsoft need not attend; besides, practically all the entry points to the Windows OS are already publicly available. What this Conference needs to do is create a set of standard "Operating System Ticklers". All application developers would write their future software to call those Ticklers. Meanwhile, an Open Source Community would create the actual Abstraction Layer which consists of those Ticklers.
When the Abstraction Layer is installed on some Operating System, even something high-end like Unix, the nature of that OS would be fully known to the AL. (The Conference would have a goal of ENSURING that all necessary information was available to the Abstraction Layer.) The AL merely checks a lookup table to translate each Tickler into an appropriate call (or set of calls) to some Operating System functionalit(ies). If the AL was powerful enough, it could even manage to work with something like good old-fashioned DOS.
The net effect of the Operating System Abstraction Layer is that any application, be it NotePad or DOOM, could run on any OS, and Windows is thereby rendered totally irrelevant.
Heh, heh heh.....
[link]
|
| |
"virtual machine" sounds like a catchy title. |
|
| |
Baked in smalltalk & VMS before windows existed. |
|
| |
Very old idea. See also e.g. Java. And POSIX, for that matter. |
|
| |
People disagree on what "essential services" are. It's hard to virtualize everything into a common layer. |
|
| |
As PS points out, POSIX is an extremely good example of this. There are a vast number of different operating systems which are "unix-like" in the sense that a program written for one, using the portable portions of the system, will run with little or no modification on the others. This is true despite the fact that many of these OSs share no code or development heritage, and in fact I think that there is no shipping OS that is, technically, UNIX. Eventually the portable bits of "unix-like" were codified as POSIX. Even MSWindows has a POSIX layer available, although I hear it doesn't work very well. |
|
| |
Apple's Carbon APIs are a weaker example, I think, because although they allow a program to run under two extremely different operating systems (MacOS9 and MacOSX) they were developed by one company in order to provide portability among its own products; Carbon isn't a standard that anyone expects, say, Sun or Microsoft to implement for their own operating systems, even though that would be possible. |
|
| |
"Windows CE" could be thought of as a set of operating systems all sharing a lot of code, in which case it's another example of a baked OSAL. |
|
| |
The VM system which ran on old IBM Big Iron was a literal virtual machine --- it emulated a large number of instances of its own hardware, down to virtual disk controllers, virtual punched-card readers (which, according to legend, could even become "jammed"), etc. It was fully virtualized, meaning you could even run VM inside one of its own virtual machines. It wasn't much of an abstraction layer, though: almost the reverse. Modern operating systems try to insulate the user processes from the details of the hardware. |
|
| |
From the way the article is written, it's hard to tell whether the aim is to have something that is source-compatible or binary-compatible. |
|
| |
Source compatibility won't help you get MS Office ported to BeOS (or whatever), and POSIX is doing a pretty good job of this for apps that don't make much use of modern hardware (where modern hardware is defined as an I/O device that isn't a teletype). For most other devices, you get differences between operating systems. Mac OS X does POSIX, IIRC, and even Windows supports a bit of POSIX. (Especially if you use CYGWIN - not sure if this is what [wiml] was talking about.) POSIX would probably make a damn good starting point for your plans, at any rate. |
|
| |
If you want binary compatibility between platforms as divergent as Windows, Sun and MacOS, what you're talking about is a virtual machine, as prometheus said. |
|
| |
What I want to know is, if FreeBSD can flawlessly emulate Linux binaries (at least, they claim they can) at the same speed as they run natively, why can't the WINE folks do a little better? (Sorry to sound a little disparaging of their efforts, but last time I tried WINE, it was horrendously buggy and very slow.) |
|
| |
The other problem no one's mentioned is that of the feature set offered. An example of a Hardware Abstraction Layer is Microsoft's DirectX. There seems to be a new version of this every year to support improvements in hardware. Likewise, operating systems are also always offering new features, hence the half-dozen different versions of Windows still in use. It might not be a bad thing to slow this multiplication, but you'd still need to update your OSAL regularly - POSIX at its core offers a very limited suite of functions compared to, say, the Windows 98 API. And Java, likewise, seems to go thru a lot of versions, particularly for the GUI and interface. Look, also, at the multiple incompatible Linux desktops; APIs seem to tend towards maximum entropy. |
|
| |
Ahh... The problem with X is that there are quite a few aspects of its design which seem to have been bungled. Fonts, at any rate, are a pain to set up on Unix systems. Even so, it's amazing how well Unix and X have fared up after all the time since they were originally developed. |
|
| |
«pheasantly surprised», Rods? |
|
| |
From what I've seen, Windows has a fairly good font system. Also, the GDI abstraction works for the printer as well as the screen, which simplifies printing immensely - all of the functions that you would call to write to the screen work equivalently for the printer. |
|
| |
In the interest of throwing some ideas around, I'm sure that in an [arbitrary time interval], we'll all be using 200-300dpi screens, and having icons that are 16x16 pixels next to 12 pixel high text won't be pheasant to read. Do you know if anyone is planning for this kind of thing happening? (Windows has an option to turn up the screen /resolution/ - in dpi, not in pixels - causing fonts to be scaled, but this seems to horribly confuse some programmes, and it gives dire warnings of impending doom and catastrophic incompatibility if you set it to more than about 120dpi.) |
|
| |
Basic obvious philosophical error in the idea: one cannot interoperate with anything abstract. Everything you can actually "touch" is by necessity specific. Therefore, any "layer" you implement here will simply be yet another operating system, of which we already have several. |
|
| |
Could be, jutta. But don't blame me -- I was just going along with Microsoft terminology, because lots of people would then know what I was talking about. |
|
| |