Re: [nbos] : [FM] FM, ASTRO et al under WINEExile In Paradise Mon Sep 17th, 2007
On Mon, 2007-09-17 at 10:35 -0400, NadinB-at-aol.com wrote:
> ok folks, I am so unimpressed with Windows and I need
> to replace the laptop in the next six to eight months,
> or sooner if it finally fails, how well do any of these
> programs work under emulation?
They work surprisingly well out of the box, with some
exceptions, caveats, gotchas, and the like.
Long Ramble Coming Right Up:
February 1997, I was trying an early beta of what would
become Win98. I installed an ALPS touchpad driver that
claimed to be for the beta. Windows rebooted into the
Black Screen of Despair, with a message of:
"Windows Protection Error: Reinstall Windows."
My brain snapped, and I said, "No."
I spent 14 hours repairing the machine, ultimately finding
that the win.ini had a semi-colon out of place. I fixed
the semi-colon, booted the Win98 with my ALPS touchpad
driver, and declared success. Then I formatted that pieces
of junk OS into oblivion and replaced it with a FreeBSD
install. I swore several oaths to myself:
1. I would never run an OS that came with such a ridiculous
2. If I wanted to install a program that only ran on Windows,
I did not need that program, and would find or write an
It was tough at first, breaking the Microsoft habit.
But, I came to realize that I did not miss things like
having to run an anti-virus, defrag my drive, and all of
the other wastes of time that Windows users accept as
requirements to use a computer.
But, I really missed a silly little application called
Treepad. So, I kept trying to find ways to to run it
This led me to experiment with running it under WINE,
and later Cedega, and even VMware for Linux.
Over the years of terrorizing windows applications with the
threat of making them run on Unix, I have learned a lot of
1. It generally doesn't work at first.
There is no "standard" to create Windows programs to.
So, every program works differently. Some do things
that Windows itself says they shouldn't do. Some programs
bypass the Windows APIs to do things "low-level" that
they shouldn't do. This means you may have to fight with
it for a while to get it running under any emulator.
2. Emulation is complex.
What Wine and other does, and how it does it, is actually
some pretty deep voodoo. That it works at all is actually
pretty hard to imagine. That it works so well is simply
amazing. But, complexity means that there are lots of
parts required to work well together, and that there are
lots of little breakable parts. You can expect to spend
time keeping the parts all working well together once you
get it working at all.
3. Edge applications require tuning.
The emulator will ship with a "default" setup that generally
works well for "widely used" applications. Using "edge"
applications like NBOS tools requires you to tune the
emulator. This is no slight against NBOS or the emulators,
its just a fact of reality that not everyone is smart
enough to enjoy this hobby. The developers have created
ways for end users to custom tailor the emulators to
solve the problems caused in item 1. This means you might
have to do complex things to get your apps to work.
4. You might still need Windows.
This is the thing most people fight, but it ultimately
remains that no Windows emulator can 100% replace an
actual copy of Windows, and Microsoft works actively
to keep it that way by sneaking in subtle changes to
break emulators and overtly forbidding things in their
license. Most emulators have a way to "tap into" an
existing Windows install, either in a virtual hard
disk or on a separate partition (such as in dual boot
systems). To really get emulation working on a variety
of applications, you may want to plan your new system
to have a default Windows partition you never install
things into, but that the emulator can load fonts and
5. One emulator can't do it all.
Each emulator supports the things their developer has
had time and interest to build. Wine is great with the
2D and basic 3D applications, but not so good on the
hardcore gamer APIs like DirectX. Another group, Transgaming
offers a fee-based fork of Wine that handles the game APIs
well, but breaks on simple 2D apps that Wine itself works
great with. So, you may have to develop an entire ecosystem
of emulators and tools that will collectively replace a
single Windows OS and still run all of your applications
6. It may work, but only 90%.
In many cases I can get applications mostly-working under
an emulator, but not every feature works, or it will
explode violently when I push a certain button. Learning
what is "safe" and what isn't can be tedious and hard on
irreplaceable data, so expect to build in time to just
put programs through their paces to find out their quirks
under the emulator.
7. Save early, save often, save again
If you use emulation, you are choosing to add even more
instability to your apps. Be in the habit to save early,
save often, save again. Use revision control where possible.
However, the app instability is generally more than offset
with the improved stability of the OS itself. So, you spend
less time just keeping the OS alive, and more time keeping
the applications pointed in the right direction.
8. Stay up-to-date, but keep old versions around.
Emulators are like water: ever changing. Stay up to date
to get better and better emulation, but also know there
will be times when an updated doesn't run your app, and
a previous version did. So, you may have to "freeze"
or "fork" your emulation at certain stable versions
that run your app.
9. You don't have enough memory.
Get more. Emulation naturally requires more resource
that just running the native thing. VMware is notorious
for its incredible demand for RAM, unless you spend the
time to tune its memory engine. Then it can generally
be made to play well with the rest of your desktop.
10. Get ready to *really know* your application.
Getting the application to install under an emulator with
its own installer is an adventure of its own. You will
learn a lot about how the installer works, and what changes
it expects to make, and what it thinks the OS should do
to run the application. Once it installs, running it becomes
a second adventure. You can expect to learn some new registry
skills, and have some "gee, I never thought it did that" moments.
11. Never Give Up! Never Surrender!
It's hard, very hard, especially at first, to get apps to
behave and be useful again under emulation. The temptation
to throw in the towel and just go back to windows will
be great. When that happens to you, and it will, go get
your copy of GalaxyQuest, watch it and relax. Let the
crew of the NSEA Protector remind you to "Never Give Up!"
and "Never Surrender". Take a break. Sleep on the problem
if you have to. Come back to it later, when you are fresh
and can hopefully look at the problem in new ways.
As you get each install finished, and each app working,
it becomes easier as you learn the common pitfalls and
workarounds for them. Eventually, you just don't notice
and you find you are running Windows apps side by side
with Linux apps, on Linux, and you start forgetting
which is which.
Now, to Specifics:
All of that was general notes.
Specifically, I use VMware Workstation with a real Windows
2000 install to run ProFantasy and NBOS tools. It just
works better for me, because these tools require OS features
not generally available in other emulators. NBOS uses a lot
of VBscript functions and calls which emulators are just
dumbfounded by. Most A simple test: If you can't get IE6 to work
with the emulator, you are going to have problems with many
edge applications, included NBOS and Profantasy, because they
use scripting APIs, COM and Active X controls, and other things
that just aren't 100% present in emulators.
For example, AS1 worked well under Wine, as long as I didn't mind
the menus being blank at random times. AS2 worked well too,
but the scripting sections just plain would not work. FM7 custom
tools would not work because of the scripting engine used behind
I have also been able to get some emulation to work together.
For example, under Linux, I can "loopback mount" my VMware
virtual disk into the Linux file tree, and use Wine to run
some of the apps using the loopback mounted disk.
You can get really tricky if you like, but it makes it harder
to run stable/production-ready apps this way.
Personally, I would start with a Linux that has deeply integrated
Wine. Fedora 7 is one, there are many others. By deeply-integrated,
I mean that Wine and Windows apps will appear in the GNOME menus
on fedora, and "exe" files are registered as valid binaries in the
kernel, so you can just type (or double-click) the EXE file itself
in order to launch the application. The OS then knows how to start
and use Wine to run the thing. Once you get going, Wine expertise
develops quickly, there's a good community behind it to rely on.
Use winecfg to setup your basic wine environment. Then, use the
original installer to try installing the app. Be prepared to do
that many times, for each application, as you work through each
roadbump to get it to install.
Run the Linux side by side with your Windows while you start
moving things over and to act as a reference to compare against
while you get the app working on Linux.
Robert "Exile In Paradise" Murphey
Xerox does it again and again and again and ...
Nbossoftware mailing list