dosemu and windows
Jocke Berglund
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
Barzilai Spinak
(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----------------------+
Garrett D'Amore
: (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 | gar...@sba70.berkeley.edu
Software Co-Ordinator | 68 Barrows Hall, UC Berkeley
Haas Computing Services | Ph: 510-643-5923 Fax: 642-4769
====================================================================
Carlo James Calica
an easier solution would be to use existing Windows 'clone' in the way of
OS/2. OS/2 win.com is simply MS's modified to act as a DPMI client rather
than a DPMI server. If we can get dosemu to support DPMI than those of us
that ALSO have OS/2 can use that version of Windows. This may be illegel
depending on the OS/2 license.
--
/------------------------------+--------------------------------------\
| Carlo J. Calica | Linux: Choice of the GNU Generation |
| cal...@cae.wisc.edu | Dittos from the People's |
\ University of Wisconsin | Republic of Madison /
Barzilai Spinak
>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
This is just what I was trying to say. Sorry if I didn't explain it well.
But I wasn't so far away from the real thing, eh?
>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 :-)
Do you really need the addresses, or just the function numbers or something
like that? Just asking...
>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
Exactly. Is that soooo difficult? (Not that I can do it...)
[...]
Valiant Gough
: In article <1uc2j0$8...@agate.berkeley.edu> gar...@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
Jim McCoy
>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
>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
I would suggest you check out the WABI (windows application binary
interface) that Sun introduced a short while ago. It runs MS-Windows
applications faster than Windows on a 486 and completely buries NT as far
as Windows performance goes. MS is trying to sue Sun over this but they
really don't have a case (legally speaking) and Sun has a bankroll to fight
with... Sun is also trying to push the WABI as a "standard" for
interfacing systems with Windows applications [the ramifications of this
are that MS may in fact _lose control_ of definign the "Windows standard"]
and they should be fairly up front about the standard and getting
it/proting it. Sun wants this standard to become as widespread as possible
to help Solaris (if the WABI becomes the standard the MS can't use
"undocumented" calls to keep control of Windows and the MS operating
systems lose a big selling point...)
jim
--
Jim McCoy | UT Unix Sysadmin Tiger Team
mc...@ccwf.cc.utexas.edu | #include <disclaimer.h>
pgp key available via "finger -l", on pubkey servers, or upon request
Andrew McGregor
Sun Microsystems have done it, and called it WABI (Windows Application
Binary Interface): it even emulates the X86 processor on a SPARC. If
your machine is X86 based, it's 70% faster than real ms-windows!
They say that they are going to release the specs for it soon, as an
effort to standardise the windows binary interface. So: get the specs
from Sun, and port away...
---
Andrew McGregor,
Physics, University of Canterbury, Christchurch, New Zealand.
a...@phys.canterbury.ac.nz
Scott Moore
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."
------------------------------------------------------------------------
Klaus Steinberger
>there's more to Windoze than that. And you always have the case of ill-behaved
>programs who will do something unexpected.
At least MS's own programs. Do you remember the case against MS about
hidden information?
Sincerely,
Klaus
--
Klaus Steinberger Beschleunigerlabor der TU und LMU Muenchen
Phone: (+49 89)3209 4287 Hochschulgelaende, D-8046 Garching, Germany
FAX: (+49 89)3209 4280 !!! after 1. July new Postal Code 85748
Internet: Klaus.St...@Physik.Uni-Muenchen.DE
Dan Dulitz
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
Peter MacDonald
>In article <1993May31....@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
Eric Youngdale
>In article <1993Jun1.1...@cs.cornell.edu> dul...@cs.cornell.edu (Dan Dulitz) writes:
>>In article <1993May31....@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."
Todd Austin
the way to go:
- like Peter notes, user's need not own MS-Windows to run
windows application, and
- the internals is a moving target, whereas the interface
is (somewhat) static, probably moreso now that Sun is pushing
the PWI standard.
A few years back, I (and one other person) did an X server implementation
using the primitives of the Tajo windowing system running on the Xerox
D-machine architectures. BTW, the Tajo windowing system is in many ways
the parent of all other windowing systems, authored in the mid-seventies,
it was the system that spawned the system that Jobs patterned the Mac
interface after :-). Basically, its the same scenario with different
windowing systems, here's a few ideas:
- windowing systems are basically all the same, it is relatively
easy to map functionality from one to another, this is more true
when the system that you are mapping onto (in this case X-windows)
has an expressive and orthoginal set of operations -- which IMHO
is the case for X
- programs generally use a very limited set of functionality
provided by the windowing system, this is especially true for
programs that were ported to MS-Windows (most), since the
developers used basically the same process discussed here, that is,
they mapped needed functionality onto a minimal set of MS-Windows
calls
- and more importantly, most programs' output can be significantly
degraded (during development) without any significant loss in the
functionality of the program, there are umpteen variations of each
primitive available -- just map them all to one simple equivalent
operations and move on, later, after the interfaces are fully
functional (but degraded), they can be completed
Sun, is going to publish the PWI interface (the one Wabi uses) and they
are pushing its use by all. And since, the hard part is already taken
care of, that is, executing 80x86 instructions, it seems that Linux would
be an excellent PWI target. I've included a copy of the Wabi/PWI press
releases from Sun.
I'd love to take on this project, but I've got a little matter of a Ph.D.
to finish up, so I'll have to remain a sink of Linux goodies until late
1994. In any case, I'd be happy to be peripherally involved.
Cheers,
Todd
-- The Florida SunFlash
Sun Introduces Wabi - Allows MS-Windows Apps To Run Under UNIX
SunFLASH Vol 53 #x May 1993
----------------------------------------------------------------------------
This issue of SunFlash has three Sun press releases about SunSelect's
Wabi technology. (Note - Wabi is not an acronym.). -johnj
----------------------------------------------------------------------------
SunSoft To Copackage Wabi With Solaris
Sun Introduces Wabi - Allows MS-Windows Apps To Run Under UNIX
SunSelect Proposes Public Interface For MS-Windows Apps
--------------------------------------------------------------------------------
Subject: SunSoft To Copackage Wabi With Solaris
Contact: Laura Ramsey, +1 415/336-0739
Contact: Emily Cohen, Hi-Tech Communications at +1 (415) 904-7000
SunSoft: +1 510-460-3267
Windows Applications To Run On Solaris
MOUNTAIN VIEW, Calif., May 5, 1993 -- SunSoft, Inc. today announced
that it will copackage SunSelect's Wabi technology with the Solaris
software environment, enabling users to run Windows applications with
no performance compromise. The Wabi technology was recently
demonstrated running Microsoft Excel, Microsoft Word and Microsoft
PowerPoint for Windows on Solaris at SunSoft's Annual Solaris Developer
Conference.
"Wabi coupled with Solaris gives users the best of both worlds -- the
power of UNIX with the range of Microsoft applications," said Edward
J. Zander, president of SunSoft. "Now users can run their spreadsheet
on Wabi and their business on Solaris."
Solaris users will initially be able to run key Windows applications
that account for about two-thirds of the applications sold in the PC
market. These include Lotus 1-2-3 for Windows, Lotus AmiPro, Microsoft
Word for Windows, Microsoft Excel, Microsoft PowerPoint, Microsoft
Project for Windows, WordPerfect for Windows, Harvard Grahics for
Windows from Software Publishing Corp., Aldus Pagemaker, PROCOMM PLUS
for Windows from Datastorm Technologies, Inc., CorelDraw, and Paradox
for Windows from Borland International, and the complete set of
Microsoft Windows 3.1 accessories. Wabi will be certified to run
additional applications later in the year.
SunSoft will begin a promotional offer for Wabi this month. Customers
of Solaris for x86 and Solaris 2.2 for SPARC will receive a coupon with
their product redeemable for the Wabi technology at no extra cost. The
offer will extend through December. In addition, the Wabi technology
will also be copackaged with SunSoft's INTERACTIVE UNIX product line by
the end of the year. INTERACTIVE UNIX is SunSoft's product targeted at
the low end multiuser x86 marketplace.
SunSoft's Solaris environment is designed to combine the features of
high performance computing -- such as multiprocessing, multithreading,
installation, administration and network security -- with the
ease-of-use of personal computers, making it the rightsizing solution
of choice for global enterprises. It is available on the highest volume
RISC and CISC architectures, SPARC and x86, and will soon be delivered
on the new PowerPC platform. More than 7,500 32-bit applications -- the
largest base in the world -- run on Solaris today.
Product inquiries should be directed to SunSoft at 510-460-3267 in the
United States and to local SunSoft offices in Europe and Asia.
--------------------------------------------------------------------------------
Subject: Sun Introduces Wabi - Allows MS-Windows Apps To Run Under UNIX
Contact: Beth Byer, SunSelect +1 (508) 442-0271
Contact: Kathryn Lang Hi-Tech at +1 (415) 904-7000
Contact: Larry Lytle, USL at +1 (908) 552-5186
SUNSELECT INTRODUCES WABI SOFTWARE, BRINGING MICROSOFT(R) WINDOWS
APPLICATIONS INTO THE UNIX(R) SYSTEM ENVIRONMENT
USL, SCO and SunSoft to implement technology;
USL forms co-development partnership with SunSelect
CHELMSFORD, May 5, SunSelect, the PC integration business of Sun
Microsystems, Inc., today introduced the first technology that allows
Microsoft. Windows applications to run directly on UNIX.-based PCs and
workstations at full performance without the need for MS-DOS. or
Microsoft Windows itself. Named Wabi, the software gives UNIX system
users the ability to run the most popular Microsoft Windows
applications on the most powerful open network computing environment.
"The Wabi technology represents a giant step in making UNIX broadly
acceptable to the commercial marketplace," said Dave Power, general
manager of SunSelect. "For the first time, users can run their favorite
Microsoft Windows applications at full speed while still accessing the
rich resources of the UNIX environment."
SunSelect will license Wabi to leading UNIX operating system vendors.
Companies planning to implement Wabi as a part of their respective UNIX
system offerings include UNIX System Laboratories (USL), The Santa Cruz
Operation (SCO) and SunSoft.
SunSelect has formed a co-development agreement with USL to build key
components of the Wabi technology. "We are making a major engineering
commitment to this project, and view Wabi as a key element of our UNIX
strategy," said Don McGovern, vice president of USL. "The technology
dramatically advances open systems by enabling customers to take
advantage of both their Microsoft Windows and UNIX system applications,
without depending on a single vendor."
In addition, several other vendors, including Toshiba, Fujitsu Limited,
NCD, Tadpole Technology, and Quarterdeck Office Systems, have endorsed
Wabi as a way to broaden the choice of software available to their
customers.
Wabi is based on technology acquired by SunSelect from Praxsys
Technologies, Inc. (Norwood, Mass.) in September 1992. SunSelect has
also entered into an agreement with Bitstream Inc. (Cambridge, Mass.),
under which SunSelect will license Bitstream's font handling technology
to make a large selection of TrueType fonts available to Wabi vendors.
As a result, Wabi users will have the same access as Microsoft Windows
users to Bitstream's library of more than 600 scalable TrueType fonts.
From Microsoft Windows to X Windows
The Wabi software will enable UNIX system users to run Microsoft
Windows applications right out of the box. Additionally, those
applications become part of the UNIX as easily accessible as any UNIX
allowing users to cut and paste text between Microsoft Windows and UNIX
applications. For example, information queried from a UNIX-based
database management system or received via an email message can be
incorporated within a presentation document created with Microsoft
PowerPoint. or CorelDRAW!.. The user simply utilizes the cut-and-paste
facility built into X Windows, the open systems standard for displaying
graphical elements on networked computers and terminals.
While other products permit Microsoft Windows applications to run under
the UNIX system, they do so by running MS-DOS and Microsoft Windows in
an emulation environment, a feat that requires considerable system
resources, reducing application performance. By contrast, Wabi
translates the function calls made by a Microsoft Windows application
into those recognizable by X Windows. This approach consumes much less
processing power, permitting Microsoft Windows applications to run with
no compromise in performance.
Support for leading Microsoft Windows applications
Major application vendors, including Lotus Development Corporation,
Borland International, WordPerfect Corporation, and Corel Corporation,
have recognized the Wabi product as an innovative way to make their
Microsoft Windows applications available to new users.
"Wabi is a strong bridge between UNIX and Microsoft Windows, and
broadens customer's options, allowing end-users to run desktop
applications like 1-2-3. for Windows and Lotus Freelance Graphics on a
wider range of platforms," said Jim Manzi, president and chief
executive officer of Lotus Development Corporation.
The most popular Microsoft Windows applications on the market are being
certified to run on Wabi. These programs, which together represent
about two-thirds of all Microsoft Windows applications sold, include
Lotus 1-2-3 for Windows, Lotus AmiPro, Microsoft Word for Windows,
Microsoft Excel., Microsoft PowerPoint, Microsoft Project for Windows,
WordPerfect. for Windows, Harvard Graphics for Windows from Software
Publishing Corporation, Aldus PageMaker., PROCOMM PLUS for Windows from
Datastorm Technologies, Inc., CorelDRAW!., Paradox. for Windows and
Quattro Pro for Windows from Borland. International, Inc., as well as
the complete set of Microsoft Windows 3.1 accessories.
Ongoing certification program
SunSelect, USL and other partners will continue to test and certify
other Microsoft Windows packages for the Wabi environment. To increase
the library of applications compatible with the Wabi software,
SunSelect is establishing a self- certification program for
developers. Through the program, available in June, developers can
receive a free preview copy of Wabi, enabling them to conduct
compatibility testing during the course of application development.
SunSelect and its partners will also work with developers to make Wabi
as broadly compatible as possible.
Availability and pricing
SunSelect will make release 1.0 of Wabi available to its licensing
partners this summer. Each vendor will announce its own plans for
packaging, pricing, and availability.
--------------------------------------------------------------------------------
Subject: SunSelect Proposes Public Interface For MS-Windows Apps
Contact: Beth Byer, SunSelect +1 (508) 442-0271
Contact: Kathryn Lang, Hi-Tech +1 (415) 904-7000
SUNSELECT PROPOSES PUBLIC INTERFACE FOR MICROSOFT(R) WINDOWS APPLICATIONS
Users, Manufacturers, Software Vendors Join in
Supporting Public Windows Interface
CHELMSFORD -- May 5, 1993 -- In keeping with the philosophy of open
systems technology, SunSelect, a Sun Microsystems, Inc. business, today
proposed creating a specification called the Public Windows Interface
(PWI) to bring the Microsoft Windows application programming interface
(API) into the public domain. The idea of a PWI specification as the
foundation for industry innovation is broadly supported by computer
system vendors, independent software vendors (ISVs) and end users,
including American Airlines, Borland International, Corel Corporation,
Hewlett-Packard Company, ICL, Network Computing Devices Inc., Norwegian
Telecom, Quarterdeck Office Systems, Sun Microsystems Computer
Corporation, SunSoft, Tadpole Technology, The Foxboro Company, The
Santa Cruz Operation, Inc., UNIX System Laboratories, Inc., and
WordPerfect Corporation.
The goal of creating PWI is to define a standard API for Microsoft
Windows. With a defined standard, applications and tools can be
developed that will enable the users of systems based on multiple
operating systems to directly run the almost 5,000 existing Microsoft
Windows applications today. The PWI concept will be submitted to open
systems organizations with the goal of creating PWI as an industry
standard. Further, SunSelect has examined the recent industry movement
to the common open software environment processes, and believes that
PWI is well aligned with these processes. SunSelect welcomes
participation of others in accelerating the initial PWI specification
into an industry standard.
"Microsoft Windows is the most popular application programming
interface on desktops today. Changes to the API, which affect thousands
of ISVs and millions of users, should be made through an open process,"
said Scott McNealy, chief executive officer of Sun Microsystems, Inc.
"By establishing PWI as a standard, developers will have an open forum
to debate the programming interfaces they would like to see included in
the future."
SunSelect proposed that the initial specification for PWI be based on
the Microsoft Windows application interfaces published by Microsoft and
additional components of the Microsoft Windows API used in popular
software products. The specification could be enhanced over time as
ISVs, systems vendors and end users evolve the PWI specification in a
public forum.
Benefits for ISVs and End Users
"The shackles are broken," said Roel Pieper, president and CEO of UNIX
System Laboratories. "And that's great news for customers. Bringing
Microsoft Windows into the open systems arena will foster innovation,
and result in many new products. Most important, PWI will be a public
standard enabling customers to achieve their enterprise client-server
objectives by combining Microsoft Windows with UNIX for a compatible
and stable application environment."
For ISVs and end users writing high-powered business applications, the
native UNIX environment will continue to provide the richest set of
tools and features. PWI would enrich UNIX and other operating systems
by providing an API for personal productivity applications. Together
PWI and a robust operating system provide the complete solution for
today's competitive business environment.
"Borland believes that all computer languages should be available for
implementation by any party, as evident by our participation in
creating a dBASE( language standard," said Philippe Kahn, chairman and
CEO, Borland International. "The PWI initiative headed by SunSelect is
a necessary step in broadening the standards effort from languages to
user interfaces, and Borland both applauds and supports this effort."
For developers and end users alike, the widespread availability of
PWI-compliant applications will leverage their existing investments in
software and training. End users also benefit from a PWI because it
protects their investment by giving them an active voice in the
products they want to buy. Similarly, OEMs are endorsing the PWI
proposal because it provides a stable platform for customers, allowing
new markets to be opened.
"The adoption of PWI as a public standard will bring the benefits of
open technologyQinnovation, competition, choice to the world of desktop
productivity applications," said Helge Vinje, Section Chief of
Norwegian Telecom.
SunSelect, in a separate, but related announcement, today announced its
Wabi product, which is intended to be an implementation of a PWI
standard.
(c)1993 Sun Microsystems, Inc.
SPARC is a registered trademark of SPARC International, Inc.
Solaris, Sun Microsystems, Sun, SunSelect, SunSoft, the Sun logo, the
SunSelect logo, Wabi are trademarks or registered trademarks of Sun
Microsystems, Inc.
Aldus is a trademark and PageMaker is a registered trademark of Aldus
Corp. All other products or service names mentioned herein are
trademarks of their respective owners. Borland and Paradox are
registered trademarks, and Quatro Pro is a trademark of Borland
International, Inc. CorelDRAW! is a trademark of Corel Corporation.
Harvard Graphics and Software Publishing Corporation are registered
trademarks of Software Publishing Corporation. Lotus and 1-2-3 are
registered trademarks and AmiPro is a trademark of Lotus Development
Corporation. Microsoft, MS-DOS, Excel and PowerPoint are registered
trademarks of Microsoft Corporation. PROCOMM PLUS is a trademark of
DATASTORM TECHNOLOGIES, INC. TrueType is a trademark of Apple
Computer, Inc. WordPerfect is a registered trademark of WordPerfect
Corporation.
UNIX is a registered trademark of UNIX System Laboratories, Inc.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
For information send mail to info-s...@Sun.COM.
Subscription requests should be sent to sunflash...@Sun.COM.
Archives are on solar.nova.edu, ftp.uu.net, sunsite.unc.edu,
src.doc.ic.ac.uk and ftp.adelaide.edu.au
All prices, availability, and other statements relating to Sun or third
party products are valid in the U.S. only. Please contact your local
Sales Representative for details of pricing and product availability in
your region. Descriptions of, or references to products or publications
within SunFlash does not imply an endorsement of that product or
publication by Sun Microsystems.
Send brief articles (e.g. third party announcements) and include contact
information (non-800#, fax #, email, etc) to:
John McLaughlin, SunFlash editor, fl...@Sun.COM. +1 305 351 4909
--
%% Todd Austin, aus...@cs.wisc.edu
%% Department of Computer Sciences, University of Wisconsin -- Madison
%% 1210 West Dayton, Madison, WI 53706
Howlin' Bob
> 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: gt8...@prism.gatech.edu
Peter MacDonald
>In <C7yoy...@ra.nrl.navy.mil> er...@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
How about the same way Linux was done. Divide and conquer.
That's the only way to get that silly WABI.
If someone were to just cobble together the stubs for the interface,
and prioritize them, many could work on them. It sounds like
an intrigueing project, especially when you say "can't".
Peter
Peter MacDonald
>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.
Actually, complete compatibility is not an absolute requirement.
If it supported only pure 3.1 mode (pure?) it might be useful.
Can many windows applications count on things like the bios
and dos? Anyways, we could play with just getting some
PD windows progs working.
Peter
Steve Johnson
>In <C7yoy...@ra.nrl.navy.mil> er...@tantalus.nrl.navy.mil (Eric Youngdale) writes:
>> I agree. The way to go is the WABI way - emulating a machine will just
>>[many good points deleted]
>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
>[many good points deleted]
At the risk of inviting flames (user now donning flame resistant suit)
perhaps one of those (boo, hiss, gasp) commercial folks would look into
licensing the WABI technology from Sun and port it to Linux. I'd be
willing to part with a few ECU's (if I had any) for it.
(user directing all flames to /dev/null and removing flame resistant suit)
--
Steven C. Johnson, WB3IRU / VK2GDS \ I don't presume to speak for my employer.
TRW \
FP1/3133, 1 Federal Systems Park Drive \ joh...@trwacs.fp.trw.com
Fairfax, Virginia 22033-4412 U.S.A. \Vox +1.703.968.1000 Fax +1.703.803.5189
Howlin' Bob
>How about the same way Linux was done. Divide and conquer.
>That's the only way to get that silly WABI.
>If someone were to just cobble together the stubs for the interface,
>and prioritize them, many could work on them. It sounds like
>an intrigueing project, especially when you say "can't".
I have never said "can't." I have just said "a vicious bitch."
I am defending myself, not trying to discourage others. I can't count
the "why don't you do ... it would be easy ... but I won't" letters
I get every week. As I said, it's possible, but a huge pain in the
ass. And wouldn't that time be better spend on native UNIX/Linux
apps? I'm rather intrigued by the idea of a WYSIWYG word processor
based on EMACS 19. It has the power for it, and the flexibility.
The Linux effort could benefit the EMACS developers by finishing
up the presentation/font parts of EMACS that have some...rough
edges.
That's my thinking. Sure, Windows would be nice. But native apps
are *always* better.
Howlin' Bob
>In article <100...@hydra.gatech.EDU> gt8...@prism.gatech.EDU (Howlin' Bob) writes:
>>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.
>Either you meant DPMI or that was *extreme* gallows humor....
Well, I meant "DPMI and some sort of 286 virtualization." I realize the
problems of VCPI (without knowing all the VCPI details). Remember our
previous conversation about this? However, I was thinking about
386 enhanced mode. I believe some programs require enhanced mode...
Windows in standard mode wouldn't use VCPI or DPMI. However, I'm
not sure exactly what's involved in 286 virtualization. Time
to hit the data books...
The sad fact is that DPMI won't help one single bit with running Windows
3.1. Maybe the improbable Windows 4.0 will be a DPMI client. Maybe
WINOS2 won't require OS/2 features. Maybe Sun will give away Wabi.
Peter MacDonald
>>How about the same way Linux was done. Divide and conquer.
>>That's the only way to get that silly WABI.
>
>>If someone were to just cobble together the stubs for the interface,
>>and prioritize them, many could work on them. It sounds like
>>an intrigueing project, especially when you say "can't".
>
>I have never said "can't." I have just said "a vicious bitch."
>I am defending myself, not trying to discourage others. I can't count
>the "why don't you do ... it would be easy ... but I won't" letters
>I get every week. As I said, it's possible, but a huge pain in the
Amazin, I get those same letters myself. Anyways, I suggest maybe
we should pool together and work on a WinAPI translation library
that would allow Windows C code to be compiled under Linux. Then,
when/if that works, it should simplify implementing a runtime emulator
significantly.
BTW, I also think native apps are a good idea. But, we have enough people,
why not have both :-).
Peter
Alan Cox
>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
Mark Evans
: it/proting it. Sun wants this standard to become as widespread as possible
: to help Solaris (if the WABI becomes the standard the MS can't use
The thing is that solaris is a pig as it is when it comes to memory and
disk space.
Theoretically a sun Classic 16M ram 200M high speed (10M/S) disk running
Solaris, should beat a 486/33 8M ram 100M PC running Linux.
The Linux machine comes a rather close second.
And out performs the sun in some ways, like not needing a large fileserver
for the rest of the operating system (the sun 200M is just root partition
and swap, the Linux machine has all its binarys on local disk) and
getting X up in less time than it takes to boil a kettle and drink the
tea.
--
-------------------------------------------------------------------------
Mark Evans |eva...@uhura.aston.ac.uk
+(44) 21 429 9199 (Home) |eva...@cs.aston.ac.uk
+(44) 21 359 6531 x4039 (Office) |
Mark Evans
: 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.
Compared to windows 3 this older version is very basic.
: 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.
That is the problem with quite a few DOS applications, they start doing things
which are really OS tasks. Due to DOS being too basic an operating system.
Peter Eriksson
>Jim McCoy (mc...@ccwf.cc.utexas.edu) wrote:
>: it/proting it. Sun wants this standard to become as widespread as possible
>: to help Solaris (if the WABI becomes the standard the MS can't use
>The thing is that solaris is a pig as it is when it comes to memory and
>disk space.
>Theoretically a sun Classic 16M ram 200M high speed (10M/S) disk running
>Solaris, should beat a 486/33 8M ram 100M PC running Linux.
>The Linux machine comes a rather close second.
>And out performs the sun in some ways, like not needing a large fileserver
>for the rest of the operating system (the sun 200M is just root partition
>and swap, the Linux machine has all its binarys on local disk) and
>getting X up in less time than it takes to boil a kettle and drink the
>tea.
Sorry. Not correct. Even though Solaris 2.1 is big - it's not that big that
it can't be fitted onto a local disk. We have a Sparcstation 1+ running
Solaris 2.1 and it uses 200MB of disk space for root and usr. Solaris 2.1
can run swapless too (if I'm not mistaken - we use swap so I haven't
bothered to check - some news postings I've read claim that it's so)
just like Linux.
Now 200MB is about twice the size of Linux SLS but then, it contains
quite some programs too and they are compiled for a RISC processor ->
bigger binaries.
Just had to mention this. Personally I like Linux a lot.
/Peter
--
Peter Eriksson p...@lysator.liu.se
Lysator Academic Computer Society ...!uunet!lysator.liu.se!pen
University of Linkoping, Sweden <Something boring>
Eric Youngdale
>
>> 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.
Howlin' Bob
>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.
Kevin Cummings
> gt8...@prism.gatech.EDU (Howlin' Bob) writes:
>
> >In <C7yoy...@ra.nrl.navy.mil> er...@tantalus.nrl.navy.mil (Eric Youngdale) writes:
>
> >> I agree. The way to go is the WABI way - emulating a machine will just
> >>[many good points deleted]
>
> >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
> >[many good points deleted]
I've seen the technology being demoed. It's not far from being completed.
At least on platforms other than Linux.
> At the risk of inviting flames (user now donning flame resistant suit)
> perhaps one of those (boo, hiss, gasp) commercial folks would look into
> licensing the WABI technology from Sun and port it to Linux. I'd be
> willing to part with a few ECU's (if I had any) for it.
> (user directing all flames to /dev/null and removing flame resistant suit)
What an interesting turn of events. It becomes another (unexpected) option
for those of us who still are tied to a few DOS programs. Here I was
just about to swear off Windows versions of programs because they won't run
under DOSEMU, and now, maybe I want them because they'll run under WABI and
XFree86 (eventually)! I know WHICH type of DOS program I'd rather run
under XFree86.... Now here's hoping it won't be very MANY ECUs required!
--
Kevin J. Cummings ComputerVision Services
cumm...@kjc386.framingham.ma.us cumm...@primerd.cv.com
Jeffrey John Martin
>achievable, you have to divide the project up into very small easily attainable
> 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 jeff...@matt.ksu.edu Jeffrey J. Martin
Eric Youngdale
>> In order to make the goal seem
>>achievable, you have to divide the project up into very small easily attainable
>>goals....
>
>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
Andrew McGregor
>Jim McCoy (mc...@ccwf.cc.utexas.edu) wrote:
>
>: it/proting it. Sun wants this standard to become as widespread as possible
>: to help Solaris (if the WABI becomes the standard the MS can't use
>
>The thing is that solaris is a pig as it is when it comes to memory and
>disk space.
>
>Theoretically a sun Classic 16M ram 200M high speed (10M/S) disk running
>Solaris, should beat a 486/33 8M ram 100M PC running Linux.
>
>The Linux machine comes a rather close second.
>And out performs the sun in some ways, like not needing a large fileserver
>for the rest of the operating system (the sun 200M is just root partition
>and swap, the Linux machine has all its binarys on local disk)
and hence the sun is slower, it's waiting for NFS all the time.
SPARC binaries are about 4-6x the size of X86 binaries for the same
thing. Also, Solaris 2.x machines don't start to perform right until
about 24Mb memory (and myself, I don't want to run a SPARC with less
than 32Mb), so you are comparing your 486 to a machine with about 6Mb
ram and 70Mb HD in 486 equivalents. The Classic is just underconfigured
and not using it's CPU to full advantage.
It is still remarkable that this kind of performance can be extracted
from cheap hardware by a free OS.
> and
>getting X up in less time than it takes to boil a kettle and drink the
>tea.
>
OpenWindows server, right? try JPL X11R5 for speed, or even just the
-nosunview flag.
>
>--
>-------------------------------------------------------------------------
>Mark Evans |eva...@uhura.aston.ac.uk
>+(44) 21 429 9199 (Home) |eva...@cs.aston.ac.uk
>+(44) 21 359 6531 x4039 (Office) |
---
Andrew McGregor,
Physics, University of Canterbury, Christchurch, New Zealand.
a...@phys.canterbury.ac.nz
Garrett D'Amore
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 | gar...@sba70.berkeley.edu
Software Co-Ordinator | 68 Barrows Hall, UC Berkeley
Haas Computing Services | Ph: 510-643-5923 Fax: 642-4769
====================================================================
Howlin' Bob
>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...
Rick Slater
>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
rs> They're not supposed to under Windows. I doubt that dirty tricks
rs> of *this* nature will be a major problem.
rs> ...
rs> I'm afraid this isn't really an option. Now, everyone can tell me how
rs> easy it should be, if only...
Windows 3.1 apps already run under X windows with the Sun WABI interface,
which translates windows calls into X calls. Sun, USL, IBM, SCO, Toshiba,
and NCI are all planning to bundle WABI with their systems. Looks like
those folks have already done what is being talked about here. To quote
from SunWorld, June 1993: "... WABI is written in C using conventional
X libraries, making it easy for SunSelect to hop WABI from SPARC to
other computers". Of course, Microsoft is threatening to sue Sun over
all of this, but then what's new about that? :)
iv...@cc.usu.edu
> 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!
Except that most NT applications will be Windows 3.1 applications that are
being run via emulation...
> I also suspect that because NT is more POSIX compliant than
> Win3.x, it will be easier to emulate in Linux.
Well, NT achieves POSIX compliance by having a POSIX library, not be being
actually really POSIX from the ground up.
So let's emulate an operating system that emulates the system that we're using
on the system that we're using... (Ever run MBASIC programs under a CP/M
emulator on a non-Z80 machine?)
Roger Ivie
iv...@cc.usu.edu
Alan Morgan
>So let's emulate an operating system that emulates the system that we're using
>on the system that we're using... (Ever run MBASIC programs under a CP/M
>emulator on a non-Z80 machine?)
No. But I have seen someone run an Amiga with Mac simulation hardware
with Soft PC running on the pseudo-mac and a CP/M emulator running under
Soft PC.
It worked too.
>Roger Ivie
Alan
----
EFI agrees with me 100% on matters of fact. The above isn't and they don't.
-----> Mail abuse to: al...@efi.com <-----
Alias 'C Frog'. Keeper of the alt.tasteless song and part-time evil genius.
Scott Moore
written in two stages:
1. Write a pure "C" kit that translates windows functions to X calls. When
complete, you would be able to link this lib to a windows program, recompiling
the windows program, and get a pure 32 bit runnable, perhaps with some
nessesity to remove 286/windows anacronisims. This lib would be usefull on its
own for porting project where the source is available.
2. Use the above W2X lib to create an enhanced DOSEMU. The basic translation
would be nearly identical. The problem at hand would be trapping windows calls
out of the DOS VDM, performing the 16 - 32 bit thunk, then calling the
translator functions. The famed "side effect" calls to DOS would just be
allowed to happen, using the support already in DOSEMU.
The advantage to this approach is that you can get a "native" port ability as
part of the project, and also break the task into manageable steps.
<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."
------------------------------------------------------------------------
Bernd Meyer
>Amazin, I get those same letters myself. Anyways, I suggest maybe
>we should pool together and work on a WinAPI translation library
>that would allow Windows C code to be compiled under Linux. Then,
>when/if that works, it should simplify implementing a runtime emulator
>significantly.
I think THIS is a tremendours idea! It would offer great opportunities for
native applications. Some WP-companies could just take their code and
recompile, and voila, we have a native linux app!
And, before you think this is vapout-talk, I may gladly offer my help
whereever it may be of use - Somehow experienced C-Programmer, NO MS-Windows
experience (but access to at least some data books :-), a little
understanding about X. SO if you are interested, count me in!
Bernie
--
We both know that the earth is curved | ro...@umibox.hanse.de
so we can't see the way before us to its end. | or
We walk down this way hand in hand, | b-m...@tu-harburg.dbp.de
and I hope you are still with me behind the horizon | Hamburg, Germany
Bernd Meyer
>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.
Evenn the public version is able to do so, only you'll have to sacrifice
your keyboard access for it :-)
But it's nice to play solitaire again..... BTW, when I switch from windows
to another VC and back, my generic ET-4000 card goes crazy. Is this normal?
Matthias Urlichs
sla...@gandalf.nrlssc.navy.mil (Rick Slater) writes:
>
> Windows 3.1 apps already run under X windows with the Sun WABI interface,
> which translates windows calls into X calls. Sun, USL, IBM, SCO, Toshiba,
> and NCI are all planning to bundle WABI with their systems. Looks like
> those folks have already done what is being talked about here. To quote
Somebody please call up Sun and ask them what it would take to license WABI.
Alternately, we could just go ahead with the Sys5 emulator and then run the
WABI emulator under that. Should still be a lot faster than native
Windows. ;-)
NB: Does anybody actually believe that WABI is not an acronym, as one of the
press release texts stated?
--
--------- if you cut here, you'll probably destroy your monitor ----------
--
Matthias Urlichs -- url...@smurf.sub.org -- url...@smurf.ira.uka.de /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany -- +49-721-9612521 \o)/