- Wine Implementation of Web Based Enterprise Management
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.
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
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:
[DestinationDirs] wbem=%11%/wbem [FakeDllsSection] %wbem%,,wbemproxy.dll
%11% is DIRID_SYSTEM (%windir%/system32/). The DIRID constants are defined in [http://source.winehq.org/source/include/setupapi.h#L1108 include/setupapi.h]. The CSIDL constants are defined in [http://source.winehq.org/source/include/shlobj.h#L1283 include/shlobj.h]. The LDID constants are defined in [http://source.winehq.org/source/dlls/setupapi/setupx16.h#L421 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:
pwd /home/all/SourceCode/wine 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 Makefile.in wbemprox.dll wbemprox_main.c wbemprox.spec
Add to Wine Build
make_makefiles requires dlls/wbemprox/Makefile.in to be in the git index:
git add dlls/wbemprox tools/make_makefiles configure.ac updated configure updated git add configure.ac
Add the fake DLL requirements to `/tools/wine.inf.in`. First add the new DestinationDirs section near the top of the file:
[DestinationDirs] wbem=%11%/wbem [Classes] HKCR,.avi,"Content Type",2,"video/avi" HKCR,.chm,,2,"chm.file"
Then, at the end of the FakeDLLs section, the instruction for the new DLL:
11,,wsock32.dll 12,,mountmgr.sys 16422,Internet Explorer,iexplore.exe %wbem%,,wbemprox.dll [SystemIni] system.ini, mci,,"MPEGVideo=mciqtz.drv"
Add to the git index:
git add tools/wine.inf.in
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 Makefile.in 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 configure.ac, dlls/wbemprox/Makefile.in, dlls/wbemprox/wbemprox.spec or tools/wine.inf.in, 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 make
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/wine.inf.in without affecting the wbem DLL files.
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" configure.ac git commit -m "wbemprox: Add to installer" tools/wine.inf.in
Commit new source frequently, preferably on a per-function or per logical-unit basis.
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.