Installing Windows Software and Registering COM Objects
Wine will generally work with Windows program installers. A VB program with an installer
made through the VB Package and Deployment Wizard should install without a problem
and will even make a shortcut on the Desktop if it normally does so in Windows. But there
are some things to be aware of when installing VB software in Linux with Wine:
Include the VB6 runtime -
The VB6 runtime, MSVBVM60.DLL, is required
on Linux just as it is on Windows. Wine will generally create a folder named
.wine
in the folder
/home/username. Inside the
.wine folder is a folder
named
drive_c. Inside that are
Windows and
Program Files folders. Those
folders are just as they are on Windows. Any COM or Win32 libraries should go in the
/home/username/.wine/drive_c/windows/system32 folder. Wine will find them there.
Note that a period preceding a file or folder name in Linux marks
it as hidden. Unfortunately, most program file folders in Linux are set to be hidden in that way,
with no option provided to choose otherwise. Program installations generally do not provide
any choice about install location or path. If you want to find the
.wine
program folder you'll need to select
"Show Hidden Files" in the [username] folder window menu. (If you
try removing the period from the .wine folder name then Wine will just create a new .wine
folder and populate it with new files - without asking or even informing you!)
If the VB6 runtime is included in your installer it will probably get installed properly
and your VB software should run. Another option, if you have problems or if you
don't normally package the runtime, is to simply put a copy of MSVBVM60.DLL
into the System32 folder. None of the other files in the VB6 runtime installer should
be needed.
Register COM Objects -
Wine has its own Windows Registry, which functions as expected.
COM objects can be registered, Registry calls to ADVAPI32.DLL will work as expected, etc.
However, COM objects usually do not get registered without help. For example,
the Windows Script Host can be installed under Wine, but it will not work until
the COM files are registered because Wine does not recognize the .inf installer file.
If you run a VBScript after installing WSH you will see a message that says, "Can't find
script engine VBScript". Wine will have properly installed the WSH files into the System32 folder,
but to finish the job any COM libraries, such as vbscript.dll, scrrun.dll, etc., must be registered.
Probably the easiest way to register COM objects is to open a command line
terminal and do something like the following:
cd /home/username/drive_c/windows/system32
wine regsvr32 vbscript.dll
Wine has its own RegSvr32.exe, in the System32 folder. It works
in the same way that it works in Windows. The only difference is that the paths
can sometimes get a bit confusing, since the Windows paths are extensions of
the Wine program folder path. Also, Linux seems to get confused, at least in some
situations, by paths with spaces. You can specify a standard Windows path within Wine itself,
but when specifying a Wine\Windows path to Linux
a backslash is sometimes needed as an escape character. Example:
/home/username/.wine/drive_c/Program\ Files/Some\ Program/
Back to Index
Fonts in Wine
Although Linux uses True Type (ttf) fonts, they seem to be different from
Windows fonts. When Windows software is first used in Wine you will probably find
that the fonts are tiny and illegible. Installing
any Windows font in Linux
seems to cure the problem. Fonts can also be "installed" to Wine specifically
by putting them into the .wine/drive_c/windows/fonts folder.
If you have any software that enumerates fonts - such as an editor
with a font selection combo box - you'll notice that Wine is causing all the Linux fonts
to be listed even though they're useless. It turns out that list is coming from the
Wine Registry. Even more odd is that the list cannot be removed. If you delete
the fonts key (HKCU\Software\Wine...) you'll find that it comes back when Wine
is restarted. Wine will not allow you to control the list of available fonts. It seems to
be hard-coded into the Wine executable that it refreshes the Registry fonts list
with all of the useless Linux fonts on every startup! If you use standard VB
methods to list fonts - like enumerating Screen.Fonts - you'll be stuck with
this useless list.
Back to Index
The Wine Win32 API
After deciding to adapt VB software to Linux, and finding that there
are numerous small or large glitches, the next logical step is to debug.
That presents a problem. The Wine project is not designed to be an API
for Windows developers. It's designed to be a total system for running
Windows software. If your software doesn't work then you can file a bug report
at bugs.winehq.org. And then you can wait...
There is some documentation available for debugging, but it's limited.
WINEDEBUG
First, you can start a program from the command line and use WINEDEBUG. (See the WINEDEBUG man page for details.) That allows you to start
a program with a debug report that could be useful in some cases. The debug
output may be able to tell you what dependency library is missing or what API
is not supported, assuming the problem happens at startup.
Information at winehq.org
At winehq.org you can find some documentation. It's mostly
the basic introductory information. There is also a set of webpages that
list how many functions from various Windows DLLs have been implemented.
That list can provide a general overview of what you can expect from Wine,
but it doesn't specify any information about particular functions.
Windows DLLs and Header Files
If you go to the download page at winehq.org you'll
see that one of the downloads is Windows DLLs. There is virtually no
information or explanation available regarding the Windows downloads.
There are two things that could be of limited usefulness here:
The wine-dlls download is a package of Wine DLLs compiled as standard
Windows PE files. Normal Windows PE file operations can be used to
find dependencies and exported functions for these files. However, there is
not a 1-to-1 correspondence between Wine DLLs and Windows DLLs. For instance,
there is no kernel32.dll in Wine. Nor is there an ole32.dll. Presumably there
was a reason for that approach and apparently Wine works out the translation
when an API function is called. But since the Wine DLLs do not match with the
Windows DLLs it's not a simple task to check whether a specific API function
is supported.
The wine-w32api download consists of header files for the
Wine version of the Windows API. Those could be useful as reference.
Wine Documentation Package
At this URL:
http://ibiblio.org/pub/linux/system/emulators/wine/
you can download a Wine documentation package. The download is somewhat awkward.
First, it's a tar.gz file. On Windows you'll need something like 7-Zip to open it.
Inside you'll find a number of XML files. You're expected to compile your own help file from those!
As it turns out, reasonably readable HTML files can be produced from these files
if you simply replace
para tags with
P
tags, replace
title tags with
H3 tags,
replace
programlisting tags with
PRE
tags, and replace
listitem tags with something like a bullet character
(char. 149).
Having rendered these files readable, you'll find that one is named
winedev-documentation.html. According to that file, the API documentation
is supposed to be written as inline comments in the Wine source code. Then Wine
programmers are encouraged to generate man files from those comments. However,
I have yet to find even one man file for the Wine-Win32 API functions.
General Tips for VB Code
As you can see from the preceding list, there are limited options for
debugging code in VB that doesn't work in Wine. For the most part, code that doesn't
work simply won't work - it doesn't generate any error messages.
As noted above, Windows API functions are much more dependable
than ActiveX functions. Also, using a "Native" DLL in place of the Wine "Builtin" version
(that option can be set with the
winecfg applet) will sometimes yield much
improved functionality.
Another thing to watch for is "VB hacks". VB developers sometimes use
varied declarations in order to accomodate "unfriendly" data types. VB hacks may
sometimes conflict with Wine functionality.
An example:
The
ChooseColor dialogue uses a
CHOOSECOLOR structure.
The
CHOOSECOLOR structure has a member
lpCustColors.
lpCustColors is supposed to be a pointer to an array of 16 Longs that represent color
values for the custom color selections. VB programmers often declare
lpCustColors as Long,
create an array:
Dim AColors(15) as Long, then
use:
lpCustColors = VarPtr(AColors)
in order to point the
lpCustColors pointer at the actual array.
But there is also a VB hack version of that code. Microsoft actually
recommends a very funky bit of code that declares
lpCustColors as a String and jumps through hoops to make it work.
Apparently Microsoft's version was created because the
VarPtr
function was undocumented and the Microsofties didn't intend for VB to need to deal with pointers.
So rather than document the *Ptr functions, Microsoft published a non-functional hack as the "official"
way for VB to call
ChooseColor.
The point here is that both versions of the
lpCustColors
member of the
CHOOSECOLOR structure will work in VB, but the VB hack does not
work in Wine. So when VB code does not work that's one thing to check: Make sure that
your declaration matches the C++ version if possible (and confirm that the Wine header files
also have it declared that way).
In the future this page may incorporate a list of specific
workarounds for problems with VB in Wine, but as of this writing there is no
such list.
Back to Index
A Simple Display Applet for Windows Software in Wine
This is a small, simple program similar to the
Appearance tab in the Windows
Display applet. Since Wine starts with no Windows display colors in the Registry,
it uses what appear to be Windows default colors: plain black for text with a dingey medium gray
for window frames and buttons. This display applet provides a convenient way to set
color selections for windows, menus, buttons, etc. (It will also work in Windows, actually.
Wine handles the Registry calls to
HKEY_CURRENT_USER\Control Panel\Colors, writing
them to the Wine Registry.)
Download disp.zip (14 KB)
Back to Index
Saying Goodbye to Windows
Things have been changing over the past few years, such that
the landscape is not very encouraging for many Windows developers:
Microsoft is trying to move Windows programmers toward .Net, a bloated, managed code Java clone.
There are several factors at play:
• Software as a service (SaaS, also known as "cloud computing" in its current re-heat),
is being pursued as a possible way to increase software profits.
• Phone software has become a popular
fad. Apple has figured out how to cash in on that. Microsoft is following on Apple's heels.
• Web-based
software -- in the form of highly interactive webpages -- is another current fad.
• Microsoft's Windows 8 Metro, Windows RT, and Windows Phone 8 (none of which
is really a version of Windows) run trinket apps that are typically interactive webpages, written
in script or .Net, using the limited WinRT API. While Windows 8/Metro/RT has been a failure,
Microsoft are clearly determined to keep going away from Windows as a software platform and toward
Windows as an online services portal.
While .Net is poorly suited for Windows software (and WinRT isn't capable of supporting Windows software), .Net is adaptable to
phones and interactive webpages. So Microsoft is trying to herd Windows developers in that direction,
hoping to get a big stable of "apps" for Windows Phone OS, and to get a lot of "cloud nuts" hosting
"rich Internet applications" on Microsoft's Azure service. It's the emperor's new software -- often developed
using .Net, but really little more than a glorified webpage.
In conjunction with those developments, the Windows OS is becoming increasingly
restrictive for software developers and end-users alike. Windows was designed to be a flexible
platform
for software. But if people are going to be persuaded to rent their software -- rather than choosing from
plentiful, superior, and inexpensive installed software -- then Windows needs to be made less flexible,
so that it becomes more of a purchasing portal and less of a platform. Already, with Windows Vista/7, Windows
has become a spyware product that calls home in numerous ways, with Microsoft threatening to disable customers'
PCs remotely if they can't confirm that a legal copy of Windows is in use. The transition of Windows
from a software product to a services portal -- a sort of interactive cable TV -- is underway.
As Microsoft and their products become increasingly problematic and
irrelevant, Linux has been gradually improving. Also, a number of good
quality, open source, free software products have appeared to replace
the Microsoft versions: Firefox replaces the outdated Internet Explorer. Thunderbird
replaces Outlook Express. OpenOffice (AKA Libre Office) replaces Microsoft Office.
With
Microsoft having ended support for VB, pushing programmers to stay out of the API, and opening
their own "app store" that may restrict what can be installed onto Windows 8, it might be a good time to think about
moving to Linux. That transition can be eased with the help of Wine.
Wine provides the ability to run Windows software, including VB
software, in Linux. Ironically, just as Microsoft is abandoning COM and VB support, de-emphasizing the Windows API,
Wine support for VB, COM and the API is increasing.
Back to Index
Acclimating to Linux and Wine
Moving from Windows to Linux can be a radical transition.
The desktops look deceptively similar, but underneath things are very different.
There are two differences that are are immediately noticeable: 1) Much of Linux is
perennially under construction. Software is constantly tweaked
and re-released, often never quite getting finished, and often available only in
a primitive and clunky command line version. 2) While Linux might be thought of as an
operating system "of the people", it's less flexible than Windows in some surprising
ways. Some good examples are touched on in the topics above: Software installs
without letting you choose the path (even though you may have had to compile that
software yourself before installing), hidden files cannot be unhidden, etc.
Additionally, Linux is not free of the bloated and problematic design
issues that are plaguing Windows. Just as an Administrator is no longer an Administrator
on Windows, root is no longer root on many Linux systems. Instead there's a new entity
with a ridiculous name like "superuser". And just like on Windows, the method to enable
this superuser is convoluted and obscure. Both systems can be equally frustrating and
time-wasting when it
comes to the imposition of undesired and poorly documented restrictions.
On the other hand, a great deal of thought has gone into
the general user interface options in Linux. It's a smoother, more attractive system than
Windows, unencumbered by strategic commercialism in its design.
Linux on Desktop PCs - the "Culture" Problem
While Linux and Wine have come a long way toward the possibility of a widely
used Linux desktop PC, in some ways that vision is as far away as ever. One big
problem is lack of software. Wine may eventually be able to help on that score.
But perhaps the biggest roadblock is the widespread occurence of a quirky sort
of Linux sensibility. Time and again one encounters an assumption that all Linux
users are programmers. Download Linux software and you may find that you
have to also download directions for compiling and debugging that software. Visit
Linux user groups and you'll find a surprisingly rigid
culture that is, for the most part, in no hurry to make Linux more user-friendly.
It's a culture that adamantly celebrates a rugged individualism, yet enforces
an almost fascist peer pressure...A culture in which brutal scorn for Windows
and the Mac OS is
de rigueur, but at the same time, refugees from those operating
systems are met with a barrier to entry into the Linux world - a kind of adolescent
hazing ritual of unhelpfulness and criticism....It's a culture
that clings to tedious, arcane and outmoded command line operations as a kind
of heroic, austere tradition - a sort of "geek machismo". GUI is for sissies. It's
a culture with a great deal of ambivalence about polishing the rough edges
of Linux: If it's easy to use then everyone will use it, and the mystique will be
lost. If Windows users are like a group of car owners sharing tips and
cameraderie, Linux users might be likened to a group of "greasemonkeys", often more interested
in fixing their car than in driving it, and having no patience with non-mechanics who
don't want to roll up their sleeves and spend the next two days reading repair manuals. If
Linux has a "dirty little secret" it is the problem of this peculiar Linux culture, with its
petulant, unsocialized "geeks"
who regard Linux as a private club and who want to protect their imagined
status in that club.
Given that the average Windows user often cannot install software
if it involves opening a zip file (and more competent Windows users expect properly written documentation,
not just a man page crib sheet), the in-crowd anti-social behavior among many Linux
users does not seem to bode well for the future of Linux on the desktop. It's well to
remember here that the Open Source movement is not made up of social idealists who
believe that everyone should have access to affordable software tools. Rather,
it's made up mainly of programmers who want the right to edit and recompile the software
that they use; programmers who, to a great extent, have no interest in
making that software accessible to people who have not chipped in to help write it.
Back to Index
Wine is a project that involves implementing nearly the entire Win32 API
in Linux. The support is currently quite extensive, though most Windows software does not run without
at least minor glitches, and COM support is only partial. (ActiveX controls do not run as dependably as straight
VB code and Win32 API functions.) To some extent VB software can be adapted to run smoothly in Wine.
A typical example: The RichTextBox control's methods are not currently well supported. RTB.Find does
not work. But the Windows message EM_FINDTEXT will work, providing a relatively easy replacement for RTB.Find code.