h a l f b a k e r y"More like a cross between an onion, a golf ball, and a roman multi-tiered arched aquaduct."
add, search, annotate, link, view, overview, recent, by name, 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.....
This Idea is sort-of getting Baked...
http://www.technolo...om/computing/22643/
A "hypervisor" by any other name is a type of abstraction layer. [Vernon, May 15 2009]
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
"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. |
|
| |
If we imagine that the computer is a shop of tools (drill press, lathe, band saw, benches, drawers, hoists, loading dock, etc) and that the operating system is the tooling; the bits, drills, saw blades, infeeds and outfeeds, every other unpowered piece of tooling. If so, then the user software, the "applications" could be represented by the materials: Wood, nails, paint. We need all three layers of material to produce anything. If an application is going to do anything meaningful it must interact with the "power tools" in the computer. Now, every application could be paired with a complete set of tools, a tool for every brand and make of shop tool that it requires, or it can rely on working with certain "brands" of shop (windows, mac) or it can rely on working only with certain "brands" of hardware (ATA, soundblaster). Finally it could be packaged to function with the use of a set of universal adapters, "jacob's chucks" that are designed to convert hardware into identical behavior. |
|
| |
Operating systems are 95% applications, 5% OS. Modern OS use a blend of proprietary tooling (specific hardware language) and universal tooling (any application desiring to make noise, press here). Your idea is to unify the OS into a "software abstraction" a "good enough to fool the application" OS that has all the universal and specific tools found in the windows OS. We call that a "port". A universal "port" is thus most imminently possible. Porting is also essentially a violation of copyright because to implement a port requires the insertion of code that is proprietary. Even where a port might function quite well (Windows<->OSX-Pentium) the expense of licensing the code for it would make it impossible. For all the obfuscation your idea simply ignores the primary reason why this isn't already widely done: Proprietary software for hardware. You cant pretend that your widget for "translating" software-hardware requests wouldn't violate that. |
|
| |
//Porting is also essentially a violation of copyright because to implement a port requires the insertion of code that is proprietary// |
|
| |
I think there are interoperability laws that allow companies to reverse engineer stuff. You can't steal code, but you can write an OS that runs Windows apps. Like WINE under linux. |
|
| |
or Cider? There ARE major legal hurdles to porting from one platform to another mostly in that each port is a one off version of the software with the adapting "widgets" bundled in. In reality the closest we have yet come to true implementation of hardware interoperability IMHO was DirectX. |
|
| |
consider the proposed best case scenario, a WINE type software platform where the software is implementing a windows type driver, on compatible software. That driver was licensed and promulgated under a Microsoft development program, otherwise this wouldn't be much of a port. Now a development deal is usually a two way street, you see our code; we see yours. You can't just take a windows developed driver and implement it into a non windows platform without the Microsoft proprietary coding. Now do out and get developers to implement non proprietary coding, how does the software designed to to use proprietary coding interact? Not well. |
|
| |