World Wine News

WHAT'S NEW with Wine-20040309: (see ChangeLog for details)

• Much improved winegcc tool, now used to build Wine itself.
• VxDs are now separate libraries for better modularity.
• Improvements and simplifications to the drive configuration.
• New setupapi INF script to create the initial registry.
• Many improvements to the various multimedia dlls.
• Lots of bug fixes.

It seems to me that you could simply do a longjmp() out of your WinMain, and then you wouldn't need to modify Wine at all. It would require patching up the TEB a bit (for instance to remove the exception handler chain), but nothing really complicated.

Our WinMain doesn't get called because our patch prevents it. If it were to get called, we'd be on a different (Wine-created) stack, with all kinds of things that are hard to undo, like the exception handling, etc.

The goal of my patch was to have minimal impact on Wine, and allow the *same* wine code/binaries to be used for regular use as well as shared library, so any future Wine version you create will automatically also support shared library use.

I modeled the global __wine_shared_lib variable after the __wine_main_argX globals you introduced last year, assuming that following that style would create the least resistance of getting my patch accepted.

Having Wine set up the TEB and stack environment and actually call our WinMain and us then trying to 'undo' that in WinMain creates potential for future breakage of our library, in case you change something related to the TEB & stack. Having a variable in kernel that prevents creation of these, on the other hand, is easy to maintain, and really has no impact on performance or coding.

I will be happy to implement any suggestions you may have on how to solve it another way in a single codebase that doesn't intruce the potential of breaking it in the future. I may very well have overlooked something.

It still makes the code too hard for us to maintain.

Our patch is simple, and we lack the experience to work on Wine, TEB and what not. We just do not have the time to learn everything there is to Wine.

For now, we will ship a different Wine RPM, and use a different prefix to avoid conflicting or something like that.

Something along these lines should do the trick:

#include <wine/library.h>
#include <stdio.h>
#include <windows.h>
#include <winternl.h>
#include <setjmp.h>

static jmp_buf jmpbuf;

int WINAPI
WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpszCmdLine, int nCmdShow)
{
    longjmp( jmpbuf, 1 );
}

int
SharedWineInit(void)
{
    unsigned char Error[1024]="";
    char *WineArguments[] = {"sharedapp", LIBPATH "/wine-sharedlib.exe.so", NULL};

    if (!setjmp( jmpbuf ))
    {
        wine_init(2, WineArguments, Error, sizeof(Error));
        printf( "should not get here\n" );
    }
    NtCurrentTeb()->Tib.ExceptionList = (void *)~0UL;
    VirtualFree( NtCurrentTeb()->DeallocationStack, 0, MEM_RELEASE );
    NtCurrentTeb()->DeallocationStack = NULL;
    NtCurrentTeb()->Tib.StackBase = (void*)~0UL;  /* FIXME: should find actual limits here */
    NtCurrentTeb()->Tib.StackLimit = 0;
    return(0);
}

For the record there are still a ton of unresolved questions that Mono is just choosing to ignore here (because they can). For instance, multithreading won't always work correctly, but as S.W.F is not thread safe this doesn't seem to matter too much. I think stuff like exception handling and so on won't work either. So it really is not a general solution.

Being able to initialize winelib mid-flight is possible but a whole ton of work that very few people understand enough to do (in fact maybe only AJ).

The intention is to have a module wine-sharedlib.so that you can dlopen and call a method in there to have Wine initialize itself. After this you can call the API as a library.

Now, this might not be as helpful to others as you might think, unless they dlopen/dlsym every symbol they want to import (this is what we do with Mono: every symbol we need has to be explicitly invoked).

MPlayer sounds like the perfect consumer for this though, and drivers as well.

Mono on CVS (mono and mcs modules) now have the capability of running Windows.Forms applications.

Windows.Forms is basically an API to create GUI applications with .NET and its essentially a wrapper around Win32, hence our strong desire to use Wine as a runtime library.

uuidof.diff - enable use of some ms extensions

include/wine/uuidof.h (new)

Lets GCC compiler use the uuidof MSVC++ extension used in ATL. See comments inside the file

include wine/pretty_com.h (new)

Lets any C++ compiler use the __decelspec( property () ) MSVC++ extension. See comments inside the file

tools/pretty_com.pl

A Perl script that changes __decelspec( property () ) declarations to the proper macros from pretty_com.h. see comments inside the file

include/unknwn.idl (updated)

Adds a C++ only extension to the IUnknown Interface. This is to let ATL compile (use of uuidof.h)

ForAtlMfc.diff - some fixes and additional files needed by ATL/MFC

include/Makefile.in

Added some new .idl files, see below

include/expdisp.idl

Add the DWebBrowserEvents + the IWebBrowser2 and events

include/expdispid.h (new)

needed by expdisp.idl and ATL code

include/olectl.h

The font constant will not compile. I think it should also be fixed for c but I can't be sure. It was written like in MS headers, MSVC will compile it, but GCC will not. The way I did it works for both.

include/mshtmhst.idl (new)

other Interfaces related to IE that are not present in expdisp.idl

include/msstkppg.h (new)

some GUIDs used by MFC

include/objsafe.idl (new)

common Interface also used by ATL

msvcrt.diff - minor fixes to msvcrt

include/msvcrt/limits.h

very much synced with MSVC, needed by MFC

include/msvcrt/math.h

I'm not sure who submitted a broken empty math.h header. Just to show that no one is doing serious winlib work lately, or they are not reporting about it. This header is the one I have for use with STLPort, it will Just #include the standard lib one. If it is not acceptable than at least completely remove the one in now.

include/msvcrt/mbctype.h

Some missing constants for the _setmbcp, used by MFC

include/msvcrt/wchar.h

Some code was copy pasted from <sys/stat.h> and was protected by an #ifndef. The <sys/stat.h> added some newer definitions that where not added to wchar. This patch removes the old definitions and instead #includes <sys/stat.h>. It is the same way in ms-headers. In fact I had some code that presupposed stat.h included by wchar that would hence not compile under the old version.

warning_off.diff - some of these might be controversial but would eliminate 17 tons off warnings when compiling MFC/ATL and user code. I have found (the hard way) that GCC in some cases would produce none working code but will Just warn about it. Having thousands of warnings or turning warning off will eliminate the ability to catch these cases. I have found that most of the trivial warnings can be avoided with a few small tricks. here they are below. (for complete discussion of GCC's bad code please post me)

include/msvcrt/mbstring.h

This one will eliminate 1000 warnings in MFC and any using code The actual issue is definitely a mal-practice in the code of CString. But since MSVC does not care it was never fixed by MS . In effect it does nothing. ( I think code looks better, but that is subjective). It lets me a way to avoid these warnings when compiling MFC with -D_MBCS. (I did not currently managed to compile it with out it. And I did not even get to Unicode). This single patch would be very hard to maintain outside of wine. If any one has other suggestions I would be happy to hear them. for now it is the best I could do.

include/msvcrt/stddef.h

Lots of offsetof in MFC headers and code. GCC will automatically warn on use of this macro on c++ objects. Regardless if it is right or wrong to do so. (for a complete discussion of this topic just browse to www.gcc.org and search for "offsetof"). this patch will eliminate the warning. ( Maybe it is best to keep this patch separate)

winegcc.diff - I know I promised 4 but here is a 5th.

include/wine/winegccdef.h (new)

This is an exact replica of what winegcc is doing (extracted from winegcc.c) it is for use by people like me that cannot use winegcc directly. I hope that some day winegcc will just do: "-include wine/winegccdef.h" and save space and time. One addition I have added is an NO_NO_WARNING_MODE option that will eliminate lots off warnings. The default is warning off.

winegcc.c

needed missing stuff

#!/bin/bash
# A wine wrapper script. In Vino Veritas!
# v1.0 (C) Mike Hearn

# Licensed under the GPL

for a in $@; do

    if [[ "${a:0:1}" == "+" ]] || [[ "${a:0:1}" == "-" ]]; then
    	
	if [[ "$WINEDEBUG" != "" ]]; then
	    WINEDEBUG="$WINEDEBUG,$a"
	    shift
	else
	    WINEDEBUG="$a"
	    shift
	fi
    elif [[ "${a%=n}" != "$a" ]] || [[ "${a%=b}" != "$a" ]]; then
	    WINEDLLOVERRIDES="$a $WINEDLLOVERRIDES"
	    shift
    fi
    
done

red="\033[1;31m"
normal="\033[0m"

export WINEDEBUG WINEDLLOVERRIDES
if [[ "$WINEDEBUG" != "" ]]; then
    echo -e "${red}debug channels:${normal} $WINEDEBUG"; fi
if [[ "$WINEDLLOVERRIDES" != "" ]]; then
    echo -e "${red}dll overrides:${normal} $WINEDLLOVERRIDES"; fi
wine $@

This patch adds full support for drag list common controls. There are no known bugs, so as far as I am concerned this is 100% complete compared to ComCtl32 v5.81 and probably v6.0 too.

This patch also adds a new cursor, the copy cursor which is a normal cursor (copied from user32) with a + sign next to it. This is needed as the user can request the control to display this during dragging. I have also fixed the tabs in LBItemFromPt. Don't mix tabs and spaces!

This patch makes DrawButton a lot simpler. It splits out the drawing functions into DrawImage which draws the button image, DrawFrame which draws the frame around the button and DrawSepDDArrow which draws the entire separate drop-down arrow. Not only does this make the drawing functions easier to manage, it should also make it easier to add theming code in the future (they are now split up into the same parts as in the themes). We also now properly support the state CDIS_MARKED/BTNS_MARKED. Next on the agenda is to rewrite the button size calculation code, including integrating Dmitry's code.

This patch improves the code calculating how big a button should be and where to draw the various parts. It adds support for a toolbar global iListGap parameter (future patches will allow you to set this) and makes the toolbar use padding supplied by applications. It also fixes Internet Explorer's "Go" button and the Media Player sidebar buttons. It is still not identical with the native version, but that doesn't seem to be a problem.

Add amstream dll (MultiMedia Streams), part of Direct Show.

• Implemented IFilterGraphImpl_EnumFilters and IEnumFilters interface.
• Renamed contructor of IEnumRegFilters interface.
• Small fix in IFilterMapper_EnumMatchingFilters.

Implemented IMediaEventSink and IMediaEventEx interfaces.

Never used -B before, so I don't know if this is how it's supposed to behave. Basically, if a prefix is given, I first look there for the name of the executable. If I find a file that's executable, I run that. If not, I default to the original.

Add a wine specific mode. If is activated if the -B prefix ends with /tools/winebuild. If you happen to have such a prefix, but you don't want this behaviour, simply add a trailing '/'. In this special mode, no default Win32 DLLs are linked in, we don't force the short wchar_t, and the standard dirs are not searched.

• Support processors made up of different commands.
• Rename some processor enums for consistency.

Preserve the relative order of files and libraries. We do so by maintaining a unique list of files and lib, each marked with the appropriate metadata.

• Add support for passing options to winebuild via -Wb
• Generate only the loader script when given just the .exe.so
• Add function to delete element from a strarray.