> > I'd like to propose a different software item.... I'd like to see a
> > "compiler" written that reads in a windows application, converts its
> > code more or less permanently to linux/X format with suitable widget
> > library and device replacements, and writes it out to disk.
>
> I like this idea. There's some scheme like this coming (here?) for
> OS/2 but I don't have the URL handy. It might be nice to have
> something like an incremental compile where the first time an app runs
> the system creates a translated executable as it goes, saving it for
> later runs.
Thinking about it some more, it might be even easier to write a
windows-emulation library package that could take (say) C source for a
complete and total windows app and allow a simple recompile under
generic Unix (no use hogging all the good stuff just to linux) and X.
That is, to write a windows app, one has to do the usual -- call some
setup stuff, create a base window, install widgets, and put callbacks
under the widgets. Only rarely does a developer get totally cute and
try to write/read things a very low level -- when they do (games) it
is usually for performance reasons but usually the small performance
gain is totally obscured by the device/configuration dependence
introduced.
SO, all we need is an X library based on widgets like Motif that make
Win95-like buttons, pulldown menus, and so forth, whose calls are
IDENTICAL to Win95 windowing calls and whose generic effect is
similarly identical. We need drop-in replacements for Windows I/O
calls (most of which are written in raw C anyway, but some of which
probably involve DLL's or registered devices -- I don't know enough
about low level Windows code since I barfed at the
InitWindowButtonCall(...) syntax and just gave up before finishing my
first windows app, but it can't be >>too<< irrational or nobody could write
applications...:-)
Then we run a windows application right through gcc or g++, linked to
this library, and out should pop an X app that pretty much does the
same thing.
The advantages of working at the source code level are obvious -- no
need to disassemble a binary and interpret calls to a (possibly
unknown or difficult to ascertain) DLL. Instead, simply replace calls
with functional equivalents and leave ordinary code alone. If the
tool was made available FREE to software developers everywhere, they
would have a strong incentive to do a recompile of their Windows apps
for the various Unices. A company could also easily be founded that
provides code ports as a contract service (give us your source and
$10K, we'll give back a linux/X binary to stick on your distribution
CD-ROM!).
>
> -------------------------------------------------------------------------
> Mark Aitchison, \_ Phone: +64 3 364-2947 home 337-1225
> Dept of Physics & Astronomy, </ Fax: +64 3 364-2469 or 364-2999
> University of Canterbury, /) E-mail: phys169@csc.canterbury.ac.nz
> Christchurch, NEW ZEALAND. (/' www.phys.canterbury.ac.nz/~physmsa
> -------------------------------------------------------------------------
>
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@phy.duke.edu