[buug] Best XP emulator?
rick at linuxmafia.com
Mon Mar 16 15:01:54 PDT 2009
Catching up on this thread.
Quoting Zeke Krahlin (pewterbot9 at gmail.com):
> I know about Wine, but never used it. Here is a page that lists
> additional Windoze emulators:
> I'm interested in an XP emulator for Ubuntu 8.10, that works well with
> unsupported peripherals, such as scanners and printers. Is the ol'
> standard Wine best for that, or some other? Here's a list of free
> Windoze emulators, on that page:
> Is one emulator perhaps better at handling unsupported drivers, than
> the other two? TIA.
> Or would NDIS wrapper be the better solution? I have been advised by
> hackers-in-the-know, to avoid that program like a plague...not for
There's a syndrome we see often enough to be wary of it, on *ix mailing
lists (and other technical forums), whose somewhat blunt name is
"Solving the wrong problem", and you should be careful lest you end up
doing that. The way it works is that someone new to a piece of software
or hardware enters the forum and asks "How do I do [foo]?" and the
regulars answer the question exactly as posed, while privately thinking
"But why would he/she be wanting to do [foo]? It's probably more in
his/her interest to do [bar]."
You started out with a request for information about XP emulators, which
means you're tending to get (mostly) answers to the question as posed,
but I see that several people (notably Ian) have also been thoughtful
enough to politely question your underlying assumption of that being the
most appropriate solution to your real, underlying problem.
There certainly _are_ problems for which the best solution is either:
1. Win32 subsystems integrated directly into Linux userland
2. Virtual machines of one sort or the other that run MS-Windows under
a Linux for x86 host OS.
3. Software that allow one to remotely run Win32 apps on a dedicated
and network-connected MS-Windows box and image it onto, and control
it from, a graphical Linux box that is on the same network.
Those all are ways of doing "Windows on Linux", and each way (category
of solution)has a number of implementations that we could discuss.
Please note that you have _not_ accurately cited "Windows emulators"
in your above-quoted list. For example: Bochs is a software emulator
of the entirety of x86 hardware all the way down to the hardware
register and BIOS level. It does not provide an operating system, but
rather an emulated-PC layer atop which you could run a PC-compatible
operating system. Because of the extremely deep scope of hardware
emulation, it carries a fearsome cost in system overhead. Also, of
course, _all_ relevant hardware interface calls must be emulated for
the simulated PC to function as desired. Because of those drawbacks,
its natural role is for use on non-Intel, non-AMD CPU platforms (e.g.,
PowerPC) where there is no alternative way to get x86 emulation.
VirtualBox isn't a Windows emulator, either. It's a VM package (my
category #2) providing an emulated x86 guest VM, developed originally by
Innotek of Germany and now published by Sun Microsystems.
WINE _is_ a partial Windows emulator, providing Linux-native userspace
reimplementations of selected MS-Windows DLLs' programming interfaces,
plus reimplementations of selected calls to the NT kernel.
In a followup, Zeke Krahlin (pewterbot9 at gmail.com) wrote:
> Just checked up on my scanner and printer compatibility, good news on
> both fronts:
> My Canoscan LiDE 20 is not even on the SANE Supported Scanners list of
> Canon models:
> But a search for "Canoscan LiDE 20 Linux" brought me here:
> Quote: "This scanner is compatible with Linux. It "just works" through
> SANE, no special drivers needed."
> To back up that claim, this from a linux site:
> > So I got lucky. But why doesn't SANE list that model as compatible?
> (Doesn't sound very "sane" to me!)
Well, if you understand how the SANE Project and its device support
database works, that will make more sense:
At any given time, the project publishes both a "stable release" version
of its back-end software (where the device support is) and an "unstable
development" (CVS) version. Newer code goes in the unstable/CVS
trunk first, is tested, then is rolled out to stable. Linux
distributions typically ship a snapshot of whatever the stable release
was some time prior to their freeze date for the distribution release.
Meanwhile, SANE Project makes the Web site's HTML tables of known state
of hardware support for hundreds of current and past devices available
on the Web. There are _two_ sets of that Web-published information:
There is one set of pages for the stable release, and one for the
unstable/CVS code. And here's the clincher: The developers have
nothing like the time or money to go out and acquire all of that
hardware. Instead, they are totally dependent on users all over the
world to submit reports about how various SANE releases worked with
their particular makes/models of scanner hardware (plus still cameras,
movie cameras, and other things) . It's extremely common for recent
SANE releases to support a particular device model quite well, but the
Web site's roster of supported hardware says nothing about that, because
nobody's bothered to send the SANE Project a report telling them that.
_You_ could be the person who sends in such a report, sir.
Because of that drawback in the way the data-collection process works,
the more you know about your device, the more mileage you're likely to
get out of the two tables. Let's consider the stable and unstable pages
for Canon scanners:
The Canon CanoScan LiDE 20 _is_ listed explicitly on the "unstable"
page. It says your thing has a USB interface, USB device ID
"0x04a9/0x220d". Support status is described as "Complete." The tested
SANE back-end is "plustek" version 0.52. The link for a relevant
manpage (on the Web) goes to:
That manpage (which would be in system manual section 5, such that you
could type "man 5 sane-plustek" -- or just "man sane-plustek" unless
there were a manpage in sections 1-4 with the same name) further
clarifies that the supported scanners are flatbed devices whose USB
hardware interface is provided by a National Semiconductor chip in the
"Merlin" family: model LM9831, LM9832, or LM9833. For specifically the
LiDE 20, it says that that hardware contains a LM9833 chip, has 512kB of
RAM, has USB device ID ("Prod-ID") 0x220D, and supports scanning at
600x1200dpi resolution with 42bits of detail.
Checking the "stable" page (first of the two URLs cited above), one
finds the _same_ information. Tested back-end is (again) "plustek"
version 0.52, implying that the unstable release doesn't offer anything
new for those scanners that the stable version doesn't already have.
So, actually, it looks like what you needed was fully present on the
SANE Project Supported Device pages, but you missed it.
> My Lexmark Z645 printer also is compatible, I just found out:
> But since it's been so flaky with ink usage, it's a big waste of money
> and time, so I won't be using it anymore...I don't need to print much,
> anywayz. Just for the sake of learning, however, I'll set it up in
> Linux, then remove it later.
Sure. That pages says "works perfect" with a driver (PPD file, and
sometimes accompanying code) called "z600v1.0-1", whatever the heck that
Going by a bit of searching, I have a strong feeling that the reference
is to a cruddy bit of proprietary code produced by Lexmark, Inc. that
_used_ be downloadable as archive CJLZ600LE-CUPS-1.0-1.TAR.gz from the
Lexmark support site. It can still be found at a third-party site,
as mentioned here: http://ubuntuforums.org/showthread.php?t=447092
In case it isn't obvious, drivers published _by_ Manufacturers are
usually A Very Bad Thing in the Linux world. They're usually really
badly written / buggy, proprietary, binary-only, easily break over time
(as a result of system upgrades with which they're incompatible) without
the community having any ability to fix them, and are often very
peculiarly packaged. It is usually worth going to some lengths to avoid
such drivers and use genuine open source community-maintained drivers if
In this case, Lexmark happens to be one of the manufacturers who mostly
cooperate poorly with the open source community, with the result that
usable open source drivers come out only slowly, after coders in the
community reverse-engineer the hardware's programming interfaces.
Happily, it sounds like you might be looking to get a replacement
printer. Might I suggest double-checking any candidates against
http://openprinting.org/printer_list.cgi , first?
 Despite the acronym standing for "WINE Is Not an Emulator", that
name is half-facetious. WINE is an emulator to the extent that it
aspires to emulate the portions of the Win32 programming interface that
are considered to matter. It does not aspire to fully implement all
aspects of the Win32 programming interface, which is a good thing, since
the project has had a rough time with only its modest aims, given the
incredible complexity of Win32, lack of documentation on key points, and
evolving nature of the thing.
Recently, developers have started calling it "Wine" rather than "WINE",
but I do not concur.
More information about the buug