stacy@mcl.UUCP (Stacy L. Millions) (01/18/89)
In article <2862@kuhub.cc.ukans.edu>, sloane@kuhub.cc.ukans.edu (Bob Sloane) writes: > I have been looking for a portable operating system for some time... > ... I mean one operating system that can run on several > different machines, UNCHANGED. While, MS-DOS must be portable, it will run on several different Brands of computers UNCHANGED (5 * :-). Give me a break already, if you make make any substantial changes in hardware (ie use a different processor or bus) you are going to have to change the OS. > While unix has been *modified* to run on quite > a few different pieces of hardware, I am not convinced that it is "portable" > and that VMS is "non-portable." What do you consider portable versus non- > portable? Being able to modify the OS to run on a new peice of hardware is what I consider portable. I challenge you to port VMS to run on an 80286, pull that off and I will beleive the VMS is portable. -stacy -- "He to whom the early bird runs best learns wisdom and patience! ... I can never remember proverbs" - Charlie Brown S. L. Millions ..!tmsoft!mcl!stacy
gpwrdcs@gp.govt.nz (Don Stokes, Govt Print, Wellington) (01/25/89)
In article <579@mcl.UUCP>, stacy@mcl.UUCP (Stacy L. Millions) writes: > Being able to modify the OS to run on a new peice of hardware is > what I consider portable. I challenge you to port VMS to run on > an 80286, pull that off and I will beleive the VMS is portable. Can I point out that MS-DOS only works on an 80386 because the 80386 is capable of pretending to be an 8088, which is the *ONLY* processor that MS-DOS will run under. I challenge you to run MS-DOS on a 68000. MS-DOS will *NOT* run on an 80386 which is actually behaving as an 80386. The whole purpose of an operating system is to provide a buffer between the applications program and the physical hardware and architecture of the machine. People who have been brought up in a MESS-DOS world will not understand this, as the MS-DOS does not acheive this basic aim ... to do anything useful under MS-DOS you have to go straight into the hardware and control the machine directly, and occasionally modify the OS accordingly. On a *REAL* OS, there is never any need to do this. VMS is "portable" among VAX computers. It provides bridges in functionality which blend in so well that few VMS users/programmers are even aware that there are differences in the architectures between different VAXes (eg many of the MicroVAX instructions are emulated by the OS). While I am not convinced that Unix is really "portable", it is as close as you can reasonably expect to get given the vast range of harware it will run on. Since it is native mode, it has to be source language portable, as 80386 code will *NOT* run on a 68000 or VAX, no matter how hard you push it. Are you asking that *EVERY* machine ever built should be identical so that they can run the same OS code? I repeat a comment made here already: Get real! Regards, Don Stokes, Systems Programmer, Government Printing Office, Wellington, New Zealand.
sl@van-bc.UUCP (pri=-10 Stuart Lynne) (01/27/89)
In article <226@gp.govt.nz> gpwrdcs@gp.govt.nz (Don Stokes, Govt Print, Wellington) writes: }In article <579@mcl.UUCP>, stacy@mcl.UUCP (Stacy L. Millions) writes: }as the MS-DOS does not acheive this basic aim ... to do anything useful under }MS-DOS you have to go straight into the hardware and control the machine }directly, and occasionally modify the OS accordingly. On a *REAL* OS, there }is never any need to do this. On *REAL* OS it is not possible to do this! (Access hardware directly that is.) :-) -- Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532
domo@riddle.UUCP (Dominic Dunlop) (02/01/89)
In article <226@gp.govt.nz> gpwrdcs@gp.govt.nz (Don Stokes, Govt Print, Wellington) writes: >In article <579@mcl.UUCP>, stacy@mcl.UUCP (Stacy L. Millions) writes: >> Being able to modify the OS to run on a new peice of hardware is >> what I consider portable. I challenge you to port VMS to run on >> an 80286, pull that off and I will believe the VMS is portable. [Fulminations against ``MESS-DOS'', comments on limits to VMS portability deleted] >The whole purpose of an operating system is to provide a buffer between the >applications program and the physical hardware and architecture of the machine. >... >While I am not convinced that Unix is really "portable", it is as close as >you can reasonably expect to get given the vast range of harware it will run >on. Since it is native mode, it has to be source language portable, as 80386 >code will *NOT* run on a 68000 or VAX, no matter how hard you push it. > >Are you asking that *EVERY* machine ever built should be identical so that >they can run the same OS code? I repeat a comment made here already: Get real! It's a good idea to remember that there is a solution to this problem: make every machine look the same by implementing an emulator for some hypothetical standard machine architecture on top of each one. Then write your operating system and applications in the machine code of the standard machine. Presto! It runs for any architecture on which you've implemented the emulator. (All you have to do is work out how to get your programs onto each target.) Writing such an emulator is certainly easier than writing a whole operating system or bootstrapping a native machine code compiler onto a new architecture before compiling a source-code-portable OS. It's particularly easy if your hypothetical machine is simple, regular -- and dumb. This approach actually works well enough to be used in the real world: UCSD Pascal is implemented this way, so is Pick. (There's even a British product called BOS which, in effect, implements a COBOL engine, and has an operating system written in... you guessed... COBOL.) The disadvantage of the approach is that, as the operating system and all applications are, in effect, interpreted by the emulator, performance is unlikely to be as good as could be obtained from programs compiled all the way down to the native machine code of the target processor. -- Dominic Dunlop domo@sphinx.co.uk domo@riddle.uucp
brent@uwovax.uwo.ca (Brent Sterner) (02/03/89)
In article <978@riddle.UUCP>, domo@riddle.UUCP (Dominic Dunlop) writes: > > It's a good idea to remember that there is a solution to this problem: make > every machine look the same by implementing an emulator for some > hypothetical standard machine architecture on top of each one. I've often thought it would be nice if there was an ansi standard for user interfaces. (I guess there is/may be one with windows.) But this does bring up another point. This "war" has also be fought on a local newsgroup. The complaint specifically dealt with HELP. VMS HELP has nothing available for non-VMS commands (GREP, EDIF, ... {pick any other os and fill in the dots yourself} ). So it crossed my mind that non-VMS commands which *are* commands for some other os, ought to have help as well, and that help should point to the correct VMS command. This is simple in concept, but a @#$%^&*( of a lot of brute force work. Distaining work (as I do), I'm wondering if anyone out there has done this yet, for any os. Care to share it? I think it could make a very nice addition for any VMS system, and especially so for any mixed vendor shop (as we are here). Comments? b.
dave@micropen (David F. Carlson) (02/03/89)
In article <978@riddle.UUCP>, domo@riddle.UUCP (Dominic Dunlop) writes:
!
! [Fulminations against ``MESS-DOS'', comments on limits to VMS portability
! deleted]
!
! It's a good idea to remember that there is a solution to this problem: make
! every machine look the same by implementing an emulator for some
! hypothetical standard machine architecture on top of each one. Then write
! your operating system and applications in the machine code of the standard
! machine. Presto! It runs for any architecture on which you've implemented
! the emulator.
! It's particularly easy if your hypothetical machine is simple, regular
! -- and dumb.
!
! Dominic Dunlop
To wit, there are several products on the market now that take an MS-DOS binary
and "compile" it into another operating system binary on a non-Intel machine.
Most of the commercial products produce output for Motorola CPU's running
UNIX(tm). This, coupled with the Intel VM-8086 mode that allows almost-native
execution of DOS binaries under UNIX/386 (several products exist) and under
OS/2 (when Microsoft supports the 386) is making the MS-DOS/PC architecture
real machine into a commonly available, through whatever means, virtual machine.
Although I personally wouldn't mind seeing less of MS-DOS, it does have more
software written for it than any other machine (virtual or not) in history.
"May you live in interesting times" -- Chinese curse.
--
David F. Carlson, Micropen, Inc.
micropen!dave@ee.rochester.edu
"The faster I go, the behinder I get." --Lewis Carrollgpwrdcs@gp.govt.nz (Don Stokes, Govt Print, Wellington) (02/08/89)
In article <978@riddle.UUCP>, domo@riddle.UUCP (Dominic Dunlop) writes: > This approach actually works well enough to be used in the real world: UCSD > Pascal is implemented this way, so is Pick. (There's even a British > product called BOS which, in effect, implements a COBOL engine, and has an > operating system written in... you guessed... COBOL.) The disadvantage of > the approach is that, as the operating system and all applications are, in > effect, interpreted by the emulator, performance is unlikely to be as good > as could be obtained from programs compiled all the way down to the native > machine code of the target processor. Yeah, fine, if you want a fraction of the performance ... (fond memories of UCSD Pascal on Apple ][s ... <yawn>... gimme 6502 assembler anytime...). You mention Pick ... on many implementations, Pick is actually run as native code. The first phase of compilation produces something akin to Pcode, that code is either used directly by an interpreter, or is further "compiled" to produce native files. I don't know a lot about pick, so I'm not sure of the details. And Pick is almost as much of a mess as Unix, with every man & his dog producing different and subtly incompatible versions ... Don Stokes Systems Programmmer, Government Printing Office, Wellington, New Zealand ------------------------------------------------------------------------ Experience is directly proportional to the number of compilations plus dumps squared.