with today's CVS commit (for those who stay up to date with the latest developments), you'll have to modify your Wine configuration to reflect the changes.

First of all, your Wine configuration file now needs a WinMM section containing the following:

[WinMM]
"Drivers" = "wineoss.drv"
"WaveMapper" = "msacm.drv"
"MidiMapper" = "midimap.drv"


Not adding this will print the following message

> You didn't setup properly the config file for the Wine multimedia modules.
> Will use the hard-coded setup, but this will disapear soon.
> Please add a WinMM section to your Wine config file.


Note that the above configuration will be shortly required, so don't wait before setting your configuration up

Next, you have also to add a key to your registry. To do so, create a sample file (let's call it foo) containing the following text:

[HKEY_LOCAL_USER\Software\Microsoft\Windows\CurrentVersion\Multimedia\MIDIMap] 989041554
"AutoScheme"=dword:00000000
"CurrentInstrument"="#0"
"UseScheme"=dword:00000000


then goto the <wine>/programs/regapi and compile the program the run:

regapi setValue < foo

that's it

Not applying the key in the registry will result in various errors in MIDIMAP_ functions (mainly if Wine is set up to use a native Windows system)

Maintainers are welcome to update theirs packages accordingly (default values are in documentation/samples/config & winedefault.reg)

Detailed information is available in documentation/multimedia.sgml.

I understand what you mean, but nope, I think we don't really care about XP.

Sure, one day we'll have to implement whatever new APIs are in XP, but this will come when an application needs it.

The Wine development is application driven, not Windows driven: what we want is for applications to run in Wine and the release of a new version of Windows changes nothing for the 99.99999% of applications that are already out there (and solitaire XP is not the most important app although I quite sure that it will be one of the first XP apps to run).

Now, if you were to ask about Office XP (if such a thing exists)...

You will need to run the installation program or manually copy all the registry entries from an existing installation. The Microsoft Office applications put tons of stuff in the registry which is necessary for them to run.

I just checked, and they appear to have changed the name between 2.0.1 and 2.0.2. I can't help wondering how the FreeType people expect any- one to keep up with this.

DLL separation has been mentioned quite a few times on this list (usually as the ultimate solution to a problem), but I don't think I've ever seen it actually defined. Based on my own misadventures in this area, however, I would hazard a guess that is essentially the conversion of all inter-DLL function calls from OS-based dynamic linking to the Wine DLL loading mechanism.

Under this assumption, adding 'IMPORTS = ntdll' to a DLL's Makefile.in file (in order to use one of the PROFILE functions) seems like a definite step backwards. I think that the proper approach is to add the function in question to dlls/ntdll/ntdll.spec and make sure that the importing DLL lists ntdll.dll as an import in its own SPEC file.

All of which is wonderful until you consider the following in ntdll.spec:

##################
# Wine extensions
#
# All functions must be prefixed with '__wine_' (for internal functions)
# or 'wine_' (for user-visible functions) to avoid namespace conflicts.


This would seem to indicate that the PROFILE functions (in files/profile.c) need to have their names changed before they are exported. Is this an appropriate time to go crazy with grep and sed? (For example, PROFILE_EnumWineIniString would become __wine_EnumIniString.)

The profile functions are not exported and you should not use them. If you're trying to access the config file, use the registry API instead; for an example, see what Alexandre did in dlls/x11drv/x11drv_main.c. You'll see the reason Alexandre changed the .wine/config file format to the registry format.

You could use #defines in a .h file too, but you shouldn't add wine extensions without a *very* good reason. Alexandre has even advocated code duplication in some instances to keep DLL separation tight.

I'm running Lotus Notes 5.04a under WINE with one of the January releases and its been working great for months. However, any release since February does not seem to do reliable networking on my Mandrake 8.0 system. I can occassionally actually get into my inbox and even open up a message, but I've never been able to read more than one.

Some cow-orkers using this same setup on Redhat 7.1 do not have this problem, but others using SuSE 7.1 do too.

Does anyone have any ideas why only networking would be affected and only on select distributions? It stumps me because all three mentioned distros use glibc-2.2 and gcc-2.96 (SuSE may use 2.95...not sure). On a related note, another cow-orker who is using Mandrake Cooker (development distro) and his own compiled kernel does not have this problem. I am on a token ring network, which I don't think should matter.

I just submitted a patch to wine-patches that provides the implementation of spawnl and spawnlp. I had been hoping to implement execl and execlp as well but found that the underlying functionality that I would need is not exposed outside scheduler/process.c. My question is what guidelines are there, if any, are there to exposing non-win functions, such as exec_wine_binary in scheduler/process.c?

Also, from just a cursory glance at exec_wine_binary that I may need to wrap it to do some of the work that fork_and_exec and PROCESS_Create are doing, such as calling DOSFS_GetFullName. I'm not sure what, if anything, the server would need to know about this.

You cannot do this with the Win32 API, that's true. And since the native msvcrt is implemented on top of the Win32 API, this means that msvcrt exec functions cannot possibly behave exactly like the Unix ones.

What you must do is find out the expected behavior of the msvcrt exec, and implement the same behavior; you should then be able to do this using the Win32 API, since this is how the native one does it.

I have gone ahead and implemented most of the exec variants as described just terminating the previous process, the internal spawn implementation already provided a flag to accomplish this easily.

On the question of determining compatibility, what methods are we "allowed" to persue? For instance, I created a small test app for the exec variants, tested it under Windows NT then under Wine. I would hope this is a valid method, but with the way the lawyers work, it's sometimes hard to tell.

As a note, it seems NT is doing the same thing as they end up with different address spaces and pids after execl.

Big disclaimer: I am not a lawyer; if you end up in court because you pay attention to anything I say, that's just too darn bad.

It depends on which country you're in. What you've done is classic "black box" reverse engineering, which has historically been protected by the U.S. legal system. Even the DMCA protects it as long as you don't decrypt anything.

UCITA in its unaltered form, however, legitimizes all those software license agreements that U.S. courts have found unenforceable. So I guess it's starting to depends on what state you're in if you're in the U.S.