From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: dosemu and windows Date: Wed, 2 Jun 1993 16:04:49 GMT
In article <100211@hydra.gatech.EDU> gt8134b@prism.gatech.EDU (Howlin' Bob) writes:
>In <C7yoyF.5tH@ra.nrl.navy.mil> eric@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."