Wine Implementation of Web Based Enterprise Management

At the time of writing (January 2009) Wine does not have support for WBEM, probably because it is a large and complicated sub-system that is closely related to WMI (Windows Management Instrumentation). I found an aborted attempt to add  WBEM patches in February 2008 but they were  rejected as being incorrectly configured for the way Wine does things. The author didn't respond and nothing more happened.

I've looked at those patches, read the Wine Developers New DLL instructions, and am preparing a set of patches to get the WBEM project rolling. This page is a repository of the research, design decisions, and sources of information so that others can understand, share and contribute.


File system layout

The first hurdle was figuring out how to have wine install the DLLs into the correct location. On Windows NT there is a wbem/ system sub-directory:


On wine, files in this location are dummies mainly containing version information - the real libraries are in /usr/lib/wine/, /usr/lib32/wine/ or similar. The WBEM sub-system on Windows contains 50 or so DLLs, plus optional sub-directories for static data and similar. As a result it is important that wine uses this same layout. See the MSDN article  WMI Architecture for more details.

Source Layout

After checking with people at IRC Freenode #winehackers I got confirmation that against my preference, and against logical layout, each of these DLLs should have its own source directory (dlls/wbemXXXX/) - rather them all being in, or in sub-directories of, dlls/wbem/.

17:51 UTC, Saturday 10th January, 2009
<IntuitiveNipple> Can anyone point me to documentation on how to create a new series of DLLs?
 I'm playing about with wbem, (which has a sub-dir of System32/) full of related DLLs.
 The primary dll is system32/wbem/wbemprox.dll, but it has *a lot* of supporting DLLs too.
 Can I keep them in the source tree under dlls/wbem/, or do I need something like
 dlls/wbem/wbemprox/ (one dir for each DLL) ?
<mike_m> IntuitiveNipple:  take an existing one as a template
<IntuitiveNipple> I would, but wbem looks to be organised differently to all the others since it
 is a large collection of related DLLs
<mike_m> IntuitiveNipple:  iirc, subdirectories more than one deep under dlls/ are not favoured
<Thunderbird> further wbem is a huge beast to tackle
<IntuitiveNipple> It doesn't feel right to potentially create 40+ related DLLs in dlls/<dll>
 - hence why I wonder if I should do dlls/wbem/<dllname>/ for each one, or just dlls/wbem/ with all DLLs in
<Thunderbird> but wbem is easy to extend I don't think you have to start out with all those 40
<IntuitiveNipple> Indeed not, but I *do* need to start out with the correct layout
<Thunderbird> it are all just plugins I think
<Thunderbird> as far as I remember wbem is some SQL-like '/proc' framework
<mike_m> IntuitiveNipple:  so long as they have unique names, there should be no problem
<IntuitiveNipple> mike_m: You mean each getting a separate sub-dir of dlls/ ?
<Thunderbird> yes
<IntuitiveNipple> That doesn't seem right to me, surely it would be best to keep all these closely
 coupled DLLs together?
<Thunderbird> perhaps code from e.g. msi.dll or so can be reused for the sql framework (or the sql
 code should be split, so it can be reused for different dlls)
<Thunderbird> we don't have subdirs
<Thunderbird> a long time ago all sound drivers were for instance under winmm, we stopped with that

Installation (Setup)

The only other wine fake DLL that currently installs to a sub-directory of %windir%/system32/ is mountmgr.sys, which installs to drivers/. There is an entry in tools/wine.inf


The 12 is a pre-defined constant named DIRID_DRIVERS which represents %windir%/system/IoSubsys/ (LDID_IOS) on Windows 9x/ME, and %windir%/system32/drivers/ on NT/Win32 versions. More information about System Folders and Shell Special Folders is found on the Windows DDK  Using Dirids page.

For custom installation directories the INF file needs a  DestinationDirs section to define a custom location, which can then be used in directory specifications:



%11% is DIRID_SYSTEM (%windir%/system32/). The DIRID constants are defined in [ include/setupapi.h]. The CSIDL constants are defined in [ include/shlobj.h]. The LDID constants are defined in [ dlls/setupapi/setupx16.h].

Add to Wine

The first step is to create the minimum of files necessary to add the DLL to wine.


This assumes that a  git repository has already been created and the index and working directory is clean. Create a new topic branch to isolate WBEM work and switch to it:


git status
# On branch master
nothing to commit (working directory clean)

git checkout -b wbem

Create Initial Files

See  Implementing a new DLL. Create the directory, then run the winedump tool to create the files (this assumes the wine tree has been built previously so the tools are available, and that you have access to the Windows DLL file):

mkdir dlls/wbemprox
cd  dlls/wbemprox
tools/winedump/winedump spec /media/Vista/Windows/System32/wbem/wbemprox.dll

Contents of /media/Vista/Windows/System32/wbem/wbemprox.dll: 30208 bytes

4 named symbols in DLL, 4 total, 4 unique (ordinal base = 1)
Done dumping ./wbemprox.dll
Export   1 - 'DllCanUnloadNow' ... [Ignoring]
Export   2 - 'DllGetClassObject' ... [Ignoring]
Export   3 - 'DllRegisterServer' ... [Ignoring]
Export   4 - 'DllUnregisterServer' ... [Ignoring]

ls  wbemprox.dll  wbemprox_main.c  wbemprox.spec

Add to Wine Build

make_makefiles requires dlls/wbemprox/ to be in the git index:

git add dlls/wbemprox
tools/make_makefiles updated
configure updated

git add

Configure Installer

Add the fake DLL requirements to `/tools/`. First add the new DestinationDirs section near the top of the file:


HKCR,.avi,"Content Type",2,"video/avi"

Then, at the end of the FakeDLLs section, the instruction for the new DLL:

16422,Internet Explorer,iexplore.exe
system.ini, mci,,"MPEGVideo=mciqtz.drv"

Add to the git index:

git add tools/


This example is for building Wine on an amd64 (64-bit) system. It helps to use the debian build script (debian/rules) from the latest Ubuntu package:

cd ..
apt-get source wine
cd wine
cp -a ../wine-*/debian .

To install the required debian tools and wine build dependencies:

sudo apt-get install build-essential dpkg-dev fakeroot autoconf automake autotools-dev
sudo apt-get build-dep wine

Now the package's debian/rules script can be used to easily configure for a standard Ubuntu system. In particular, for 64-bit Linux, it will create missing symbolic links to many 32-bit libraries in debian/libtmp/ and pass that directory in LDFLAGS before running the configure script with suitable options to create the config.status file. In the process configure will create every DLL's Makefile, including the one for the new wbemprox:

DEB_BUILD_ARCH="$(dpkg-architecture -qDEB_BUILD_ARCH)" fakeroot debian/rules config.status


ls dlls/wbemprox
Makefile  wbemprox_main.c  wbemprox.spec

Edit, Build, Test Cycle

Now the initial organisation has been done the real work can being - coding. Unless there are changes to, dlls/wbemprox/, dlls/wbemprox/wbemprox.spec or tools/, it shouldn't require running configure very often - unless adding support for additional external Linux libraries.

Do an initial build to ensure the template is okay:

make depend

Check any errors and fix them. Once fixed you can commit the changes.

Commit Changes to Repository

This is done as a series of discrete commits to maintain separation between unrelated sub-systems. This makes it easier to back out of changes to individual files such as tools/ without affecting the wbem DLL files.

Initial Commits

If this is the first successful build you can make the initial commits now.

git commit -m "wbemprox: Add initial stub for Web Based Enterprise Management" dlls/wbemprox
git commit -m "wbemprox: Add to build system"
git commit -m "wbemprox: Add to installer" tools/

Progress Commits

Commit new source frequently, preferably on a per-function or per logical-unit basis.

Submitting Patches

Especially in the early stages, don't do too much work until the basic framework patches have been accepted, because there might need to be changes to make the work acceptable for inclusion in the project.

Use git format-patch to  prepare patches for email submission to the wine-patches mailing list. Ensure you are subscribed to both  wine-patches and  wine-devel before posting the patches since feedback will be on  wine-devel.