Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!torn!nott!bnrgate!bnr.co.uk!pipex!sunic!kitten.umdc.umu.se!fizban.solace.hsh.se!jocke
From: jo...@solace.hsh.se (Jocke Berglund)
Subject: dosemu and windows
Message-ID: <1993May30.172026.689@solace.hsh.se>
Keywords: dosemu, windows, wabi
Organization: Solace Computer Club, Sundsvall, Sweden
Date: Sun, 30 May 1993 17:20:26 MET
Lines: 14
Hi, after test running dosemu 0.49 and seeing that it can run windows 3.0 (real)
I got a thought about the WABI product of SUN, aka able to run windows
programs without windows in X, wouldn't that be an great feature to try to
get linux to do. WABI maps all the windows calls inte X calls, so to be able
to do so with linux, someone (not me) has to break down several programs
or get the docs from microsoft (Nah i don't think that they will let go of
that level of information) but anyway the windows emulation should be able to run in
pure 32 bit mode, I think.
Thanks to the writers of dosemu. :)
Joakim Berglund jo...@solace.hsh.se +46 60 129861
Path: gmd.de!Germany.EU.net!news.dfn.de!darwin.sura.net!gatech!howland.reston.ans.net!noc.near.net!uunet!haven.umd.edu!cville-srv.wam.umd.edu!barspi
From: bar...@wam.umd.edu (Barzilai Spinak)
Newsgroups: comp.os.linux
Subject: Re: dosemu and windows
Date: 31 May 1993 02:24:36 GMT
Organization: University of Maryland, College Park
Lines: 24
Message-ID: <1ubq94$jl7@cville-srv.wam.umd.edu>
References: <1993May30.172026.689@solace.hsh.se>
NNTP-Posting-Host: rac1.wam.umd.edu
Keywords: dosemu, windows, wabi
In article <1993May30.172026....@solace.hsh.se> jo...@solace.hsh.se (Jocke Berglund) writes:
>Hi, after test running dosemu 0.49 and seeing that it can run windows 3.0 (real)
>I got a thought about the WABI product of SUN, aka able to run windows
> programs without windows in X, wouldn't that be an great feature to try to
> get linux to do. WABI maps all the windows calls inte X calls, so to be able
> to do so with linux, someone (not me) has to break down several programs
> or get the docs from microsoft (Nah i don't think that they will let go of
> that level of information) but anyway the windows emulation should be able to run in
> pure 32 bit mode, I think.
>
>Thanks to the writers of dosemu. :)
(Listen, I don't know what I'm talking about...)
I think that what you mean is emulating the MS-Windoze API. I don't think
that is too difficult, (tiresome maybe, but not difficult), and any book on
Windoze programming gives a list of the calls and everything. But I think that
there's more to Windoze than that. And you always have the case of ill-behaved
programs who will do something unexpected.
+---------------------------------+
| Barzilai Spinak |
| ..... bar...@wam.umd.edu |
| (-O-O-) bar...@eng.umd.edu |
+nnn--U--nnn----------------------+
Path: gmd.de!Germany.EU.net!news.dfn.de!darwin.sura.net!howland.reston.ans.net!agate!sba70.berkeley.edu!garrett
From: garr...@sba70.berkeley.edu (Garrett D'Amore)
Newsgroups: comp.os.linux
Subject: Re: dosemu and windows
Date: 31 May 1993 04:46:24 GMT
Organization: University of California at Berkeley, UCB
Lines: 43
Message-ID: <1uc2j0$8ad@agate.berkeley.edu>
References: <1993May30.172026.689@solace.hsh.se> <1ubq94$jl7@cville-srv.wam.umd.edu>
NNTP-Posting-Host: sba70.berkeley.edu
X-Newsreader: TIN [version 1.2 GAMMA PL0]
Barzilai Spinak (bar...@wam.umd.edu) wrote:
: (Listen, I don't know what I'm talking about...)
: I think that what you mean is emulating the MS-Windoze API. I don't think
: that is too difficult, (tiresome maybe, but not difficult), and any book on
: Windoze programming gives a list of the calls and everything. But I think that
: there's more to Windoze than that. And you always have the case of ill-behaved
: programs who will do something unexpected.
In defense of the original post, I don't think _you_ know what you're
talking about. The Windows API calls are compiled into assembly to call
a given function at a specific address (I don't know how *.DLL's
complicate the issue) or a specific interrupt number. I think it is
technically feasible to write an "interpreter" for Windows *.EXEs that
calls its own internal functions whenever a specific call to certain API
addresses are made. Getting the "map" of API addresses from Microsoft
would probably be a major feat in itself. Reverse engineering might do
the trick, but it is a little more than a weekend hack :-)
What we're talking about here as an "executive" of sorts, that would be
able to "run" Windows .EXEs, mostly be trapping calls to API functions
and calling Linux or X-Windows equivalents. This is very similiar (I
think -- I've not looked at the source) to the way dosemu works, only
the map of functions for DOS is *well* documented, and the complexity of
those functions is much higher. On the other hand, Windows functions,
in general should be much better behaved than DOS functions, since
Windows must maintain control of system resources. (E.g. direct screen
writes by a Windows application would be unacceptable.) The worst
cases will be the use of "undocumented" Windows calls, and the
occasional program that does its own hardware access because Windows
code is either *very* slow or non-existent. In these cases the
ill-behaved code should be implemented as a device driver. Figuring out
an interface for new device drivers for a Windows emulation package
would proabably be a *very* daunting task! ;-)
Hope I've shed some light on the topic.
====================================================================
Garrett D'Amore | garr...@sba70.berkeley.edu
Software Co-Ordinator | 68 Barrows Hall, UC Berkeley
Haas Computing Services | Ph: 510-643-5923 Fax: 642-4769
====================================================================
Newsgroups: comp.os.linux
Path: gmd.de!Germany.EU.net!mcsun!uunet!elroy.jpl.nasa.gov!sdd.hp.com!col.hp.com!csn!magma!vgough
From: vgo...@mines.colorado.edu (Valiant Gough)
Subject: Re: dosemu and windows
Sender: n...@magma.mines.colorado.edu
Message-ID: <1993May31.212901.8476@magma.mines.colorado.edu>
Date: Mon, 31 May 1993 21:29:01 GMT
References: <1993May30.172026.689@solace.hsh.se> <1ubq94$jl7@cville-srv.wam.umd.edu> <1uc2j0$8ad@agate.berkeley.edu> <1ud70m$hou@cville-srv.wam.umd.edu>
Organization: Colorado School of Mines
X-Newsreader: TIN [version 1.2 PL0]
Lines: 32
Barzilai Spinak (bar...@wam.umd.edu) wrote:
: In article <1uc2j0$...@agate.berkeley.edu> garr...@sba70.berkeley.edu (Garrett D'Amore) writes:
: >Barzilai Spinak (bar...@wam.umd.edu) wrote:
: >
: >: (Listen, I don't know what I'm talking about...)
: >: I think that what you mean is emulating the MS-Windoze API. I don't think
: >: that is too difficult, (tiresome maybe, but not difficult), and any book on
: >: Windoze programming gives a list of the calls and everything. But I think that
: >: there's more to Windoze than that. And you always have the case of ill-behaved
: >: programs who will do something unexpected.
: >
: >In defense of the original post, I don't think _you_ know what you're
: >talking about. The Windows API calls are compiled into assembly to call
: >a given function at a specific address (I don't know how *.DLL's
: >complicate the issue) or a specific interrupt number. I think it is
: >technically feasible to write an "interpreter" for Windows *.EXEs that
: >calls its own internal functions whenever a specific call to certain API
<stuff deleted>
I would think that all you need to do is write a display driver for
Windows which sends the X-dosemu X11 commands. Then, when you install
Windows on your Linux box, when it asks for the display driver, just tell
it the X11 one.. Obviously this isn't something that no-one has done
before, because all graphics manufacturers have to write those drivers if
they want Windows support. Does anyone know if the ability to write
Windows graphics drivers is included in the Windows Development Kit?
regards,
Valiant Gough
vgo...@mines.colorado.edu
Newsgroups: comp.os.linux
Path: gmd.de!Germany.EU.net!news.dfn.de!darwin.sura.net!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!decwrl!csus.edu!netcom.com!samiam
From: sam...@netcom.com (Scott Moore)
Subject: Re: dosemu and windows
Message-ID: <samiamC7xKnM.1HC@netcom.com>
Organization: NETCOM On-line Communication Services (408 241-9760 guest)
References: <1993May30.172026.689@solace.hsh.se> <1ubq94$jl7@cville-srv.wam.umd.edu> <1uc2j0$8ad@agate.berkeley.edu> <1ud70m$hou@cville-srv.wam.umd.edu> <1ue21h$bjo@tigger.cc.utexas.edu>
Date: Tue, 1 Jun 1993 06:57:21 GMT
Lines: 33
There is one other way. The "real mode" windows could run under several
enviornments because it basically assumed an 8086+dos+vga interface. For
instance, the old windows prior to 3.0 would run under os/2 1.x.
The reason that running windows is such a problem is that it now uses 286/386
manipulations, essentially taking on os level operations that dos does not
provide.
Any os can get back the high ground by simply emulating at a higher level.
This is VM level technology. The emulator traps all 386/486 accesses as now,
but emulates them. For instance, the emulated CPU would have it's own page
tables, emulated disk, etc.
What this buys you is you don't care or deal with windows internals. You
simply increase the "fidelity" of the emulated CPU until the damm thing
works. And at the same time, you get compatibility with any following version
of windows, or any other OS for that matter !
The 386 is said to not be "completely self emulatable" meaning that there
are cases that you can't fully trap and emulate xyz bit fiddle. But those cases
are trivial, and if windows dosen't depend on them, it will work. I don't
know about the 486.
Responses ?
<sam>
--
Scott A. Moore [SAM] | This space for rent.
sam...@netcom.com |
Santa Cruz, CA USA |
408-423-1624 |
ExaByte Corp. | "my opinions do not represent my company, etc."
------------------------------------------------------------------------
Newsgroups: comp.os.linux
Path: gmd.de!xlink.net!howland.reston.ans.net!math.ohio-state.edu!caen!batcomputer!cornell!news
From: dul...@cs.cornell.edu (Dan Dulitz)
Subject: Re: dosemu and windows
In-Reply-To: vgough@mines.colorado.edu (Valiant Gough)
Message-ID: <1993Jun1.181301.7313@cs.cornell.edu>
Sender: n...@cs.cornell.edu (USENET news user)
Nntp-Posting-Host: deneb.cs.cornell.edu
Reply-To: dul...@cs.cornell.edu (Dan Dulitz)
Organization: Cornell University Computer Science Department
References: <1993May30.172026.689@solace.hsh.se> <1ubq94$jl7@cville-srv.wam.umd.edu> <1uc2j0$8ad@agate.berkeley.edu> <1ud70m$hou@cville-srv.wam.umd.edu> <1993May31.212901.8476@magma.mines.colorado.edu>
Date: Tue, 1 Jun 1993 18:13:01 GMT
Lines: 39
In article <1993May31.212901.8...@magma.mines.colorado.edu>,
vgo...@mines.colorado.edu (Valiant Gough) writes:
> I would think that all you need to do is write a display driver for
>Windows which sends the X-dosemu X11 commands. Then, when you install
>Windows on your Linux box, when it asks for the display driver, just tell
>it the X11 one.. Obviously this isn't something that no-one has done
>before, because all graphics manufacturers have to write those drivers if
>they want Windows support. Does anyone know if the ability to write
>Windows graphics drivers is included in the Windows Development Kit?
Sure, you can do this, and you can do it with a Device Development Kit
(DDK) from Microsloth.
But it is far from "all you need to do." Other things you need to do,
just to name a few: remap segment selectors, TSSs, call gates, task
gates, interrupt gates, etc. into Linux-friendly versions. How do you
do that? Well, you run Windows in ring 3, so all attempts to modify
selectors, TSSs, and gates fail. But that's not enough. Ring 3 still
allows selectors, etc. to be accessed (stored to memory) without
trapping. Good luck with this: it's such a tough problem that I am
starting to write a (s-l-o-w as molasses) 286 software emulator.
Emulating the Windows entry points directly isn't much easier. There
are hundreds of them, including True-Type rendering. Do you really
want to spend your time writing stuff like that? And once you're
"done," you'll have to work hard to deal with Win4.0 (if it comes out,
but it probably will).
The reason I'm writing this emulator is so that Win3.1 will run under
Linux. Don't hold your breath. It will be months, at *least*, until
anything comes of this. If you want to help and have some expertise
or can give good advice about software instruction-set emulators,
please drop me a line. Heaven knows I could use the advice.
Dan Dulitz
dul...@cs.cornell.edu
Fight Software Patents
Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usenet.ins.cwru.edu!gatech!destroyer!cs.ubc.ca!news.UVic.CA!sanjuan!pmacdona
From: pmacdona@sanjuan (Peter MacDonald)
Subject: Re: dosemu and windows
Message-ID: <1993Jun1.201657.8220@sol.UVic.CA>
Sender: n...@sol.UVic.CA
Nntp-Posting-Host: sanjuan.uvic.ca
Organization: University of Victoria, Victoria B.C. CANADA
References: <1ud70m$hou@cville-srv.wam.umd.edu> <1993May31.212901.8476@magma.mines.colorado.edu> <1993Jun1.181301.7313@cs.cornell.edu>
Date: Tue, 1 Jun 93 20:16:57 GMT
Lines: 25
In article <1993Jun1.181301.7...@cs.cornell.edu> dul...@cs.cornell.edu (Dan Dulitz) writes:
>In article <1993May31.212901.8...@magma.mines.colorado.edu>,
> vgo...@mines.colorado.edu (Valiant Gough) writes:
>
...
>Emulating the Windows entry points directly isn't much easier. There
>are hundreds of them, including True-Type rendering. Do you really
>want to spend your time writing stuff like that? And once you're
>"done," you'll have to work hard to deal with Win4.0 (if it comes out,
>but it probably will).
>
>The reason I'm writing this emulator is so that Win3.1 will run under
>Linux. Don't hold your breath. It will be months, at *least*, until
The problem with this approach is that you will then have the overhead
of running both Windows and windows apps. The WABI interface (I think)
achieves a 70% performance boost by doing the entry point thing.
Also, you would have to have a copy of MS Windows to use the apps.
And, you probably could get just implement a subset of them at first,
just enough to get most apps running, and doing more as time permits.
Win4.0, may not be an issue, if the control is wrestled from the
iron grip of MS.
Peter
Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!gatech!concert!news-feed-1.peachnet.edu!bogus.sura.net!ra!tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: dosemu and windows
Message-ID: <C7yoyF.5tH@ra.nrl.navy.mil>
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <1993May31.212901.8476@magma.mines.colorado.edu> <1993Jun1.181301.7313@cs.cornell.edu> <1993Jun1.201657.8220@sol.UVic.CA>
Date: Tue, 1 Jun 1993 21:27:50 GMT
Lines: 29
In article <1993Jun1.201657.8...@sol.UVic.CA> pmacdona@sanjuan (Peter MacDonald) writes:
>In article <1993Jun1.181301.7...@cs.cornell.edu> dul...@cs.cornell.edu (Dan Dulitz) writes:
>>In article <1993May31.212901.8...@magma.mines.colorado.edu>,
>> vgo...@mines.colorado.edu (Valiant Gough) writes:
>>
>...
>>Emulating the Windows entry points directly isn't much easier. There
>>are hundreds of them, including True-Type rendering. Do you really
>>want to spend your time writing stuff like that? And once you're
>>"done," you'll have to work hard to deal with Win4.0 (if it comes out,
>>but it probably will).
>>
>>The reason I'm writing this emulator is so that Win3.1 will run under
>>Linux. Don't hold your breath. It will be months, at *least*, until
>
>The problem with this approach is that you will then have the overhead
>of running both Windows and windows apps. The WABI interface (I think)
>achieves a 70% performance boost by doing the entry point thing.
>Also, you would have to have a copy of MS Windows to use the apps.
I agree. The way to go is the WABI way - emulating a machine will just
add a lot of overhead. I should also point out that if we do a good job with
something along the lines of WABI, there would be no pressing need to write a
new wordprocessor to wean the DOS users to linux.
-Eric
--
"When Gregor Samsa woke up one morning from unsettling dreams, he
found himself changed in his bed into a lawyer."
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!gatech!prism!gt8134b
From: gt81...@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.os.linux
Subject: Re: dosemu and windows
Message-ID: <100211@hydra.gatech.EDU>
Date: 1 Jun 93 23:10:02 GMT
References: <1993May31.212901.8476@magma.mines.colorado.edu> <1993Jun1.181301.7313@cs.cornell.edu> <1993Jun1.201657.8220@sol.UVic.CA> <C7yoyF.5tH@ra.nrl.navy.mil>
Organization: Georgia Institute of Technology
Lines: 61
In <C7yoyF....@ra.nrl.navy.mil> e...@tantalus.nrl.navy.mil (Eric Youngdale) writes:
> I agree. The way to go is the WABI way - emulating a machine will just
>add a lot of overhead. I should also point out that if we do a good job with
>something along the lines of WABI, there would be no pressing need to write a
>new wordprocessor to wean the DOS users to linux.
From a technical standpoint, this is certainly true.
However, I simply cannot understand how it will be done. Unless
someone can find /dev/manhours, the inexhaustible supply of
programming effort, it just isn't going to happen. The best
programmers among us are UNIX hackers at heart and have little
patience for the arcana of DOS and Windows. Yet I doubt that Ralf
Brown and Andrew Schulmann together--two of the most knowledgeable men
in the DOS world-- would feel up to the task of writing a completely
compatible Windows kernel.
I'm sinking as much time into dosemu as I can, but the infinite undocumented
quirks cause me no end of trouble. Can this get any better with Windows?
As for re-writing DOS, it simply isn't an option for me. I have neither
the time, the patience, nor skill with a disassembler to undertake such
a garguantanly boring punishment. Not only would I have to duplicate
the interrupt-called services, but I would have to replicate all the
internal data structures. I have news for you all: Windows is going
to be the same way. DOS people can't keep their hands out of the OS.
Dr. Dobbs is now running a monthly column on Windows internals.
Undocumented Windows internals. A dozen things every month that
a million programmers will find out *before* you do. Compatibility?
Ha.
And it's not as simple as "remap windows calls to X calls." WE're
not talking about POSIX -> POSIX translation, as Eric is doing with
SYSVR4 binary compatibility. We're talking about fundamentally different
systems. Sure, the ideas can't be too alien, but it won't be as simple
as:
WindowsDoSomethingEntryPoint()
{
FrobArguments();
XDoSomething();
}
But let's not focus on the Windows "kernel" too much. What about the
other parts? The font technology? The printer drivers? The applets?
That alone will be no small task.
I really want somebody to prove me wrong. Rather, somebodies, because it's
going to take a lot of people a long time. But until I see someone doing
the coding, I will believe it's all just an elaborate jest.
Until then, I will continue to develop dosemu as quickly as I can,
and perhaps one day find the time to work on VCPI.
--
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt81...@prism.gatech.edu
Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!noc.near.net!uunet!pipex!uknet!cf-cm!cybaswan!iiitac
From: iii...@swan.pyr (Alan Cox)
Subject: Re: dosemu and windows
Message-ID: <1993Jun2.103427.6034@swan.pyr>
Organization: Swansea University College
References: <1993May30.172026.689@solace.hsh.se> <1ubq94$jl7@cville-srv.wam.umd.edu> <1uc2j0$8ad@agate.berkeley.edu>
Date: Wed, 2 Jun 1993 10:34:27 GMT
Lines: 22
In article <1uc2j0$...@agate.berkeley.edu> garr...@sba70.berkeley.edu (Garrett D'Amore) writes:
>In defense of the original post, I don't think _you_ know what you're
>talking about. The Windows API calls are compiled into assembly to call
>a given function at a specific address (I don't know how *.DLL's
>complicate the issue) or a specific interrupt number. I think it is
>technically feasible to write an "interpreter" for Windows *.EXEs that
>calls its own internal functions whenever a specific call to certain API
>addresses are made. Getting the "map" of API addresses from Microsoft
>would probably be a major feat in itself. Reverse engineering might do
>the trick, but it is a little more than a weekend hack :-)
Please type with your hands not your backside in future. The windows API
doesn't depend on addresses or on interrupts except for the DOS compatibility
and the virtualised interrupts for things like NetBIOS. These are all
documented, and you are supposed to avoid using them unless you have to.
Real Windows calls are made to the windows kernel, which just happens to be
a dynamic link library. In essence your program is dynamically linked with
the windows kernel. This is a standard technique finding favour in modern
systems - the newer sys5 stuff is aiming that way too.
Alan
Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!darwin.sura.net!ra!tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: dosemu and windows
Message-ID: <C804o2.58y@ra.nrl.navy.mil>
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <1993Jun1.201657.8220@sol.UVic.CA> <C7yoyF.5tH@ra.nrl.navy.mil> <100211@hydra.gatech.EDU>
Date: Wed, 2 Jun 1993 16:04:49 GMT
Lines: 94
In article <100...@hydra.gatech.EDU> gt81...@prism.gatech.EDU (Howlin' Bob) writes:
>In <C7yoyF....@ra.nrl.navy.mil> e...@tantalus.nrl.navy.mil (Eric Youngdale) writes:
>
>> I agree. The way to go is the WABI way - emulating a machine will just
>>add a lot of overhead. I should also point out that if we do a good job with
>>something along the lines of WABI, there would be no pressing need to write a
>>new wordprocessor to wean the DOS users to linux.
>
>From a technical standpoint, this is certainly true.
>
>However, I simply cannot understand how it will be done. Unless
>someone can find /dev/manhours, the inexhaustible supply of
>programming effort, it just isn't going to happen. The best
>programmers among us are UNIX hackers at heart and have little
>patience for the arcana of DOS and Windows. Yet I doubt that Ralf
>Brown and Andrew Schulmann together--two of the most knowledgeable men
>in the DOS world-- would feel up to the task of writing a completely
>compatible Windows kernel.
When you look at it from that standpoint, sure it looks like a hard
problem. You have to try a different viewpoint. When I first started fooling
with the idea of running SVr4 binaries under linux, it looked like a hard
problem too (but for different reasons). Even through it is POSIX->POSIX,
there are incompatibilities that (still) need to be resolved in one way or
another in structure definitions and various constants and bitmaps. At this
point, the basic framework is done, and I am just poking away at various
components of the problem whenever I have time. In order to make the goal seem
achievable, you have to divide the project up into very small easily attainable
goals.
For example, to get WABI under linux, we need to establish a framework
for solving the problem, and I would suggest the following steps.
1) Write a C program that can pick apart a Windows binary, and locate
the various components. We need to know the load address, page protections,
file offsets and so forth. At this stage, we do not need to actually do
anything with the info, just print it out on the screen. You need to locate
and pick apart the dynamic linking tables, and print out what you find. All
you would need would be some books or articles that explain how it all works
and some beer. (This is how I started with the SVr4 binaries).
2) Write a program loader for a Windows binary. Here you make use of
the info obtained before, and actually mmap the file in question. You also
need to be able to set things up for the dynamic linking. It may be possible
to let the dynamic linker resolve some things on the fly as with SVr4, or you
can simply walk through the tables and substitute the correct values. For
this, you can make use of some of the code that I have generated for the SVR4
ELF program loader. Initialy you could just substitute the address of exit()
for all of the functions if you wanted, or you could add a printf statement,
or whatever you wanted to do.
3) Start going through and writing interface functions between the
Windows calls and X11. Pick a fairly simple Windows program (or better yet,
write one), and add whatever functions are required to get something up on the
screen. Initially, you would probably just be happy to get a blank window on
the screen - you can worry about filling it later.
4) Start adding some of the more complicated features - figure out how
to map the Windows fonts into the X11 fonts, and so forth. Figure out how to
map icons, draw lines, etc.
Now I suggest that initially that someone pick this up and focus on
step 1. Do not worry about how you are going to solve any of the later
problems, the goal is to simply pick apart the binary. As I look at it, step
4 would be the most difficult, but this is where the Linux effect will
come into play - once you have the basic framework down, then all kinds of
people can play and contribute and improve the code. Initially only very
simple binaries will run, but with time the bugs will get ironed out and
gradually more and more programs will be runnable.
Once we get into steps 3 and 4, we will need people experienced with
both Windows and X11. It might even work to pair people up - take a
Windows person who knows what a given function is supposed to do and pair them
with an X programmer who knows how to make it happen.
It might be helpful to consider the a time a 2 years ago when
Linus first started thinking in terms of protected mode programming for a 386.
If someone had said that the goal should be a POSIX compliant full featured
kernel that can run every sort of unix program, I think the idea would have
been scoffed at. Look where we are now. I have seen other projects on the net
stalled because people focus on the goal at the end and are intimidated by the
size of it.
-Eric
P.S. Some of you might ask if I could do this. The answer is quite probably
yes, but I am spending my time and energies on the SVr4/ELF end of things, and
I can only do one at a time. Many of the same types of problems need to be
addressed, so some communication might be helpful, but I would rather not take
on another project at this time.
--
"When Gregor Samsa woke up one morning from unsettling dreams, he
found himself changed in his bed into a lawyer."
Path: gmd.de!rrz.uni-koeln.de!unidui!easix!exnet2!ibmpcug!ibmpcug.co.uk!pipex!uunet!spool.mu.edu!darwin.sura.net!cc.gatech.edu!gatech!prism!gt8134b
From: gt81...@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.os.linux
Subject: Re: dosemu and windows
Message-ID: <100124@hydra.gatech.EDU>
Date: 1 Jun 93 13:46:15 GMT
References: <1993May30.172026.689@solace.hsh.se> <1ubq94$jl7@cville-srv.wam.umd.edu> <1uc2j0$8ad@agate.berkeley.edu> <1ud70m$hou@cville-srv.wam.umd.edu> <1ue21h$bjo@tigger.cc.utexas.edu> <samiamC7xKnM.1HC@netcom.com>
Distribution: git
Organization: Georgia Institute of Technology
Lines: 53
In <samiamC7xKnM....@netcom.com> sam...@netcom.com (Scott Moore) writes:
>There is one other way. The "real mode" windows could run under several
>enviornments because it basically assumed an 8086+dos+vga interface. For
>instance, the old windows prior to 3.0 would run under os/2 1.x.
Windows 3.0 will run in real mode. There is a hacked version of
dosemu that will run Windows 3.0 in real mode (it is unavailable to
the public, so DO NOT ASK FOR IT!). Soon, the public release of dosemu
will be able to do so, too.
>The reason that running windows is such a problem is that it now uses 286/386
>manipulations, essentially taking on os level operations that dos does not
>provide.
It also uses VCPI (Virtual Control Program Interface), usually implemented
in the memory manager such as EMM386.
>Any os can get back the high ground by simply emulating at a higher level.
>This is VM level technology. The emulator traps all 386/486 accesses as now,
>but emulates them. For instance, the emulated CPU would have it's own page
>tables, emulated disk, etc.
I don't know what you mean by "VM level." As for emulated page tables,
it's not as easy as it sounds. When Windows changes the page tables, it
expects them to work. Therefore, you'd have to eventually copy them to
the real page tables... but this is very dangerous.
>What this buys you is you don't care or deal with windows internals. You
>simply increase the "fidelity" of the emulated CPU until the damm thing
>works. And at the same time, you get compatibility with any following version
>of windows, or any other OS for that matter !
"Simply." Ah, well. Not quite. 1) There is more to emulate than the CPU
2) A virtual 386 is a real bitch to write. How, for instance, do you
intend to handle segment descriptors? Once again, you'd have to have
some way to move the virtual CPU's descriptor tables into the real
system descriptor tables. Linus recently changed Linux to not use the
LDT at all. But there's still the GDT. And interrupts from protected
mode? int 0x80 is a valid software interrupt, you know; it's used for
system calls. THe list of difficulties goes on forever. The 386 is
not completely self-virtualizable. In fact, it hardly is at all.
>are cases that you can't fully trap and emulate xyz bit fiddle. But those cases
>are trivial, and if windows dosen't depend on them, it will work. I don't
>know about the 486.
They are anything but trivial.
--
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt81...@prism.gatech.edu
Path: gmd.de!xlink.net!howland.reston.ans.net!ux1.cso.uiuc.edu!moe.ksu.ksu.edu!matt.ksu.ksu.edu!news
From: jeffr...@matt.ksu.ksu.edu (Jeffrey John Martin)
Newsgroups: comp.os.linux
Subject: Re: dosemu and windows
Date: 2 Jun 1993 15:43:40 -0500
Organization: Kansas State University
Lines: 19
Message-ID: <1uj3dsINNc53@matt.ksu.ksu.edu>
References: <1993Jun1.201657.8220@sol.UVic.CA> <C7yoyF.5tH@ra.nrl.navy.mil> <100211@hydra.gatech.EDU> <C804o2.58y@ra.nrl.navy.mil>
NNTP-Posting-Host: matt.ksu.ksu.edu
> In order to make the goal seem
>achievable, you have to divide the project up into very small easily attainable
>goals....
> It might be helpful to consider the a time a 2 years ago when
>Linus first started thinking in terms of protected mode programming for a 386.
>If someone had said that the goal should be a POSIX compliant full featured
>kernel that can run every sort of unix program, I think the idea would have
>been scoffed at. Look where we are now. I have seen other projects on the net
>stalled because people focus on the goal at the end and are intimidated by the
>size of it.
>-Eric
Long term goals set in concrete can stifle creativity. I read that NASA
uses a system of "programs" and "projects". The projects are small sharply
defined goal oriented steps that make up the more ambiguous program.
-Jeff jeffr...@matt.ksu.edu Jeffrey J. Martin
Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!darwin.sura.net!ra!tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: dosemu and windows
Message-ID: <C80J63.DIp@ra.nrl.navy.mil>
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <100211@hydra.gatech.EDU> <C804o2.58y@ra.nrl.navy.mil> <1uj3dsINNc53@matt.ksu.ksu.edu>
Date: Wed, 2 Jun 1993 21:18:03 GMT
Lines: 21
In article <1uj3dsINN...@matt.ksu.ksu.edu> jeffr...@matt.ksu.ksu.edu (Jeffrey John Martin) writes:
>> In order to make the goal seem
>>achievable, you have to divide the project up into very small easily attainable
>>goals....
>
>Long term goals set in concrete can stifle creativity. I read that NASA
>uses a system of "programs" and "projects". The projects are small sharply
>defined goal oriented steps that make up the more ambiguous program.
Quite true. I would also not look to NASA for examples of good project
management. Anyway, my point was that it sounded like people were intimidated
by the size of the task as a whole. If instead you divide it up into smaller
pieces, the whole thing seems much easier.
Anyway, at this point what we need is a few volunteers to work on
understanding the executable format for Windows binaries. Any takers?
-Eric
--
"When Gregor Samsa woke up one morning from unsettling dreams, he
found himself changed in his bed into a lawyer."
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!agate!sba70.berkeley.edu!garrett
From: garr...@sba70.berkeley.edu (Garrett D'Amore)
Newsgroups: comp.os.linux
Subject: Re: dosemu and windows
Date: 3 Jun 1993 00:29:06 GMT
Organization: University of California at Berkeley, UCB
Lines: 20
Message-ID: <1ujgki$82c@agate.berkeley.edu>
References: <1993Jun1.201657.8220@sol.UVic.CA> <C7yoyF.5tH@ra.nrl.navy.mil> <100211@hydra.gatech.EDU> <1993Jun2.011729.21602@sol.UVic.CA>
NNTP-Posting-Host: sba70.berkeley.edu
X-Newsreader: TIN [version 1.2 GAMMA PL0]
It occurs to me that Windows 3.x may be a bad thing to emulate.
This is because Windows 3.1 runs on only ONE architecture, the
80x86 -- which means that Windows programmers can get away with
the same nonsense that DOS programmers do -- accessing the hardware
and low-level interfaces directly! A better (???) way of adding
Windows functionality to Linux may be (better sit down for this one!)
to emulate NT! The reason is that since NT will run on many different
architectures, programs written for it will *need* to be "well-
behaved", otherwise they won't port! I would propose that if we
can arrange to get a set of the libraries (official) for NT, then
we could write an emulator that could map the calls to Linux/X11
calls. I also suspect that because NT is more POSIX compliant than
Win3.x, it will be easier to emulate in Linux.
====================================================================
Garrett D'Amore | garr...@sba70.berkeley.edu
Software Co-Ordinator | 68 Barrows Hall, UC Berkeley
Haas Computing Services | Ph: 510-643-5923 Fax: 642-4769
====================================================================
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!gatech!prism!gt8134b
From: gt81...@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.os.linux
Subject: Re: dosemu and windows
Message-ID: <100439@hydra.gatech.EDU>
Date: 3 Jun 93 01:23:52 GMT
References: <1993Jun1.201657.8220@sol.UVic.CA> <C7yoyF.5tH@ra.nrl.navy.mil> <100211@hydra.gatech.EDU> <1993Jun2.011729.21602@sol.UVic.CA> <1ujgki$82c@agate.berkeley.edu>
Organization: Georgia Institute of Technology
Lines: 45
In <1ujgki$...@agate.berkeley.edu> garr...@sba70.berkeley.edu (Garrett D'Amore) writes:
>It occurs to me that Windows 3.x may be a bad thing to emulate.
>This is because Windows 3.1 runs on only ONE architecture, the
>80x86 -- which means that Windows programmers can get away with
>the same nonsense that DOS programmers do -- accessing the hardware
>and low-level interfaces directly! A better (???) way of adding
They're not supposed to under Windows. I doubt that dirty tricks
of *this* nature will be a major problem.
>Windows functionality to Linux may be (better sit down for this one!)
>to emulate NT! The reason is that since NT will run on many different
>architectures, programs written for it will *need* to be "well-
>behaved", otherwise they won't port! I would propose that if we
>can arrange to get a set of the libraries (official) for NT, then
>we could write an emulator that could map the calls to Linux/X11
>calls. I also suspect that because NT is more POSIX compliant than
>Win3.x, it will be easier to emulate in Linux.
Well, I won't say how hard I think it would be, because everyone seems
bent on ignoring any words to that effect about Windows. However,
I will tell you what I feel are some major obstacles :
1) NT is exactly not POSIX compliant. NT is Microsoft's own mutant
creation. There is a POSIX subsystem *within* NT, but it's very
limited and unusable for all normal NT programs.
2) NT has even more external cruft than Windows 3.1 to emulate.
3) NT is much much larger then Win3.1.
4) At the moment, 99% of all Windows programs are for Win3.1. NT runs
then under its Win16 subsystem, which we would have to implement
ourselves. So, we're back to writing Windows 3.1 again, but with
the addition of a 25MB program loader (no joke, people have reported
the *bootup* sequence eating 25MB in the April Beta, not to mention the
extra memory the Win16 subsystem takes up, and also not to mention
the 4MB every DOS session takes up).
I'm afraid this isn't really an option. Now, everyone can tell me how
easy it should be, if only...
--
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt81...@prism.gatech.edu
Path: gmd.de!xlink.net!howland.reston.ans.net!usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!cis.ohio-state.edu!gec-epl.co.UK!John_Burton
From: John_Bur...@gec-epl.co.UK
Newsgroups: comp.os.linux
Subject: Windows emulation
Message-ID: <9306031150.AA11396@jupiter.sdd>
Date: 3 Jun 93 11:50:29 GMT
Organization: The Ohio State University Department of Computer and Information Science
Lines: 30
Newsgroups: comp.os.linux
Path: SDD!cuthbert!newsfeed
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: dosemu and windows
Message-ID: <1993Jun2.185352.2254@cuthbert>
Sender: newsfeed@cuthbert (News_Feed)
Organization: SDD
Date: Wed, 2 Jun 1993 16:04:49 GMT
In article <100...@hydra.gatech.EDU> gt81...@prism.gatech.EDU (Howlin' Bob) writes:
>In <C7yoyF....@ra.nrl.navy.mil> e...@tantalus.nrl.navy.mil (Eric Youngdale) writes:
> For example, to get WABI under linux, we need to establish a framework
>for solving the problem, and I would suggest the following steps.
>
> 2) Write a program loader for a Windows binary. Here you make use of
>the info obtained before, and actually mmap the file in question. You also
>need to be able to set things up for the dynamic linking. It may be possible
>to let the dynamic linker resolve some things on the fly as with SVr4, or you
>can simply walk through the tables and substitute the correct values. For
>this, you can make use of some of the code that I have generated for the SVR4
>ELF program loader. Initialy you could just substitute the address of exit()
>for all of the functions if you wanted, or you could add a printf statement,
>or whatever you wanted to do.>
This would need quite extensive changes to the kernel wouldn't it? Windows
makes extensive use of selectors in the LDT, and as far as I know there
is no way of allocating selector in the LDT by an application program.
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!gatech!prism!gt8134b
From: gt81...@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.os.linux
Subject: Re: Windows emulation
Message-ID: <100532@hydra.gatech.EDU>
Date: 3 Jun 93 14:01:00 GMT
References: <9306031150.AA11396@jupiter.sdd>
Organization: Georgia Institute of Technology
Lines: 15
In <9306031150.AA11...@jupiter.sdd> John_Bur...@gec-epl.co.UK writes:
>This would need quite extensive changes to the kernel wouldn't it? Windows
>makes extensive use of selectors in the LDT, and as far as I know there
>is no way of allocating selector in the LDT by an application program.
As of 0.99pl10, the kernel does not use the LDT. Writing system
calls to allocate and deallocate local segment descriptors is fairly
simple. If and when I implement DPMI for dosemu, I will do this anyway.
--
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt81...@prism.gatech.edu
Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!sdd.hp.com!decwrl!decwrl!concert!news-feed-1.peachnet.edu!bogus.sura.net!ra!tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Windows emulation
Message-ID: <C820q1.Dns@ra.nrl.navy.mil>
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <9306031150.AA11396@jupiter.sdd>
Date: Thu, 3 Jun 1993 16:34:48 GMT
Lines: 30
In article <9306031150.AA11...@jupiter.sdd> John_Bur...@gec-epl.co.UK writes:
>Newsgroups: comp.os.linux
>> 2) Write a program loader for a Windows binary. Here you make use of
>>the info obtained before, and actually mmap the file in question. You also
>>need to be able to set things up for the dynamic linking. It may be possible
>>to let the dynamic linker resolve some things on the fly as with SVr4, or you
>>can simply walk through the tables and substitute the correct values. For
>>this, you can make use of some of the code that I have generated for the SVR4
>>ELF program loader. Initialy you could just substitute the address of exit()
>>for all of the functions if you wanted, or you could add a printf statement,
>>or whatever you wanted to do.>
>
>This would need quite extensive changes to the kernel wouldn't it? Windows
>makes extensive use of selectors in the LDT, and as far as I know there
>is no way of allocating selector in the LDT by an application program.
It would not have to be that bad. In 0.99pl10, Linus added something
that would allow an lcall 7,0 instruction to do the right thing, and I am
now fleshing this out with iBCS/ABI stuff. I think that this could be
generalized a little bit to allow applications to set up the call gates, and
this could be done in such a way that the call gate calls some address in user
space instead of kernel space so that the kernel would not really need very
much work at all.
-Eric
--
"When Gregor Samsa woke up one morning from unsettling dreams, he
found himself changed in his bed into a lawyer."
|