My First Exposures to WINE

[Donald Darden]

Knoppix 5.1.1 comes with WINE 0.9.12, and the current release is 0.9.49, so you would want to replace that.  You will probably have to acquire the source code from www.winehq.com for the current release, then perform a series of make operations to assemulate it into that distribution.  Ubuntu is able to update to the current release automatically.

Building WINE from the source code is a lengthy process, but seems to be a good check for the completeness of your Linux install.  Any problems there, and the effort to make WINE will likely fail.  I've found that the distribution can install despite errors encountered on the LiveCD, and that these errors are likely if the drive is not functioning well enough, or the disk is defective.

In general, you want to follow these steps for creating WINE from source code:  The statements in red are done via a terminal console
[code[
          USE                                             REASON
1.  sudo -s1                                         become super user tempirarily 
2.  whereis wine                                   to see if wine is currently installed
3.  wine --version                                 to see what version is installed
4.  apt-get remove wine                     removes the current install of wine
5.  visit www.winehq.com                   get the source code for wine to desktop
6.  extract wine using ark                   create a folder during the extract
7.  cd [extract folder]                          position to temporary folder
8.  ./configure                                      run configure tool in folder
note: any errors encountered with ./configure may reflect a faulty install of Linux
9.  make depend                                preliminary make process
10. make                                             actual make process
11. make install                                  actual install step
you can repeat the whereis and the wine --version steps to confirm that it is installed and what version you are currently at.  Note that when building from a source file, that it is necessary to remove the prior version with apt-get remove wine to prevent possible problems.

[Donald Darden]

My experiences with wine have been short and mostly unsuccessful.  Yes, it can be made to work with some DOS and Windows applications, but the process is a painful one.  First, it is not transparent.  You have to use a command like wine [path]app.exe to get it started.  And you have to use winecfg to enable various alterations, such as whether to use provided dll substitutes or attempt to use some that come with Windows.  So that means a lot of experimentation may be involved.

Second, wine is not stable.  That is, it is still preliminary and evolving.  A problem under one release may be addressed in another.  Something made to work may later be caused to break as well.

Third, wine presumes you are not actually going to run it on a live system.  It is intended to work with skeleton drives rather than the actual ones you have.
I found that it is possible to replace one or two drive letters to point to devices under /media, but the process is somewhat limited and tedious to effect.

Fourth, while the process called by wine can be made to work with some effort, you may find that other problems arise   Dependencies, any other process or program that needs to be initiated will likely fail, because wine does not completely enclose the whole by intercepting and buffering all interface points.

Fifth, wine is not a single application.  You have wine, winecfg, wineconsole, and winedebug.  And while wine supports target executables given in M$ path format with drive letters and backslashes, this does not hold for wineconsole and winedebug.  In other words, the coverage afforded by wine is spotty at best, and this shows in many ways.

It is well that they have not attempted to call wine as being at version 1 or greater, considering its state of development.  There is no doubt that this is a herculean effort, one to be lauded, but whether the results will ever be good enough to forego the need for Windows is altogether another matter.

[Kent Sarikaya]

Donald, in watching the ReactOS video lecture, he does a great job in explaining why at a certain point in WINE can't run certain applications.

Also, I had tried to run thinBasic under Wine in Ubuntu before and couldn't get it working.  When I installed Ubuntu into WVWare, I was able to get thinBasic to work under Wine.
I wonder if PowerBasic will run under Wine via vmware. VMWare must offer things to the os install that makes more things possible than running directly on the hardware.

I would test PowerBasic too, but I can't find my CD. I know I put it in a safe place, I guess just too safe for me to find

[Donald Darden]

Knoppix will inform you that you need to also install flex and bison when you try to build wine from source code.  All in all, it is a major build project, taking several hours to do the whole thing.

PowerBasic can be copied over and run under some version of Windows that is running in VMWare.  No need to reinstall it.  I recall a lengthy discussion about whether PowerBasic should involve any registry entries.  The users polled were against it, so it did not happen. Be glad for that.

I haven't played with VMWare yet, but I have read some of the claims made for it.  According to what I've read, it should be possible to substitute real drives for the virtual ones that most people would specify as an added precaution against malware.  That would give it the flexibility that I am looking for at present.  I have WMware server 1.0.4, which is free, downloaded to begin playing with, but I have it as a binary and as a RPM package.  Of course with Knoppix or Ubuntu, the package system is Debian, so I may have some conversion issues to address going forward.

A problem between distributions of Linux, particularly those using RPM and others using Debian packages, is the arrangement and naming of folders.  In looking at the packages of wine for Ubuntu, you may note that each new minor
release of Ubuntu gets a new name and also gets a new folder distination.  That might be good for retaining several generations of updates and still keep
any prior dependencies in place, but it can mean unnecessary duplications as well, particularly if you only want the latest and greatest features.

It certainly should be possible for packages to be guided by scripts to ensure that they install in the best places.  The whereis command makes it a breeze to find any file or folder, so there should be no great difficulty in determining if a folder or file already exists or not, or whether a folder needs to be emptied before you try to delete it.  The idea that you build a package for a specific distribution, such as Red Hat, then users of other distributions should somehow be responsible for somehow adapt it to work with other distributions is arcane and really a burden on novices and casual users alike.  It would benefit everyone if efforts were made to either prebuild packages for all distributions,
or to work on creating a packaging system that is compatible with all mainstream distributions.

Another problem with packages or installs is that you cannot default some
choices.  It will stop and wait for user input before continuing.  You should only have three choices at the very beginning of an update or upgrade process:  (1)  retain user specified or distributor preferences that already exist,  (2) replace these with packager recommended settings, or  (3) allow the advance user to request to be asked on an item by item basis.  In most cases, option (1) should be the default, so that various settinss that make the distribution work will not be disturbed.

I'm not saying that you can't do things just as they are, but I am talking about removing unnecesssry choices that at present only confuse most people.  K.I.S.S. (Keep It Simple, Stupid) could really pay off here.  Sure, give me five editors to choose from if you want, but rate them, or give me a way to rate them myself, so that I can more easily determine what works best for me as I gradually progress and gain experience.

[Kent Sarikaya]

Know that you are not alone in your evaluations of *nix world. I heard this term, as free BSD is an Unix based and I guess if you call it a Linux distro it makes people unhappy, so Robert Herron at Digital Life mentioned he uses nix world instead of linux world or he said either *nix or *.nix. I thought that was funny.