Debian Etch package
Hi, I would like to maintain latest Debian Etch(to-be-stable in about month) packages for wine. The download page says "If you can help provide up-to-date Debian packages, please contact Scott Ritchie", but I already contacted, maybe month ago. Didn't get any answer. The debs are located http://blitzkrieg.homelinux.org/~paveq/wine/ I got enough bandwith(10Mb) to host them myself. Comments? -- Paavo Pokkinen [EMAIL PROTECTED] pgpi91qucA7KB.pgp Description: PGP signature
Re: regression from 0.9.28 -> 0.9.29 breaks U.S. tax program
On 1/19/07, Tom Lowe <[EMAIL PROTECTED]> wrote: > We had the same problem with Google Earth, and Rob Shearman > kindly provided a fix: > http://www.winehq.org/pipermail/wine-cvs/2007-January/029362.html Have not tried compiling wine myself yet, but may give it a try this weekend to see if that solves it. ... What might be a rough time frame for 0.9.30 to be out, so I can test it with that? (I have an old slow machine, so that may be simpler, but I have been meaning to look into git to see how that works. ) They come out roughly every two weeks, so another week or so...
Re: [Wine] www.winehq.com newsletter dead forever?
On Friday 19 January 2007 16:36, Edward Savage wrote: > I came to the conclusion that trying to do a back issue is just to hard. I > have most of last weeks written... Nice. Never mind about the back issues. > Unfortunately people have been nice > enough to implement directx reasonably well so I've been playing EVE Online > solidly like a good addict for over two weeks now... I will see if I can > get last weeks, which may be a mix of last week and this week, to Brian > today/tonight for help with formatting. Great. If you want to take a break after that to.. er... do some DirectX regression testing in EVE Online, just say the word, and we'll look into gettin that round-robin stuff set up. Cheers, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpXqWZ8bhcZe.pgp Description: PGP signature
re: regression from 0.9.28 -> 0.9.29 breaks U.S. tax program
On Thu, 2007-01-18 at 21:14 -0800, Dan Kegel wrote: > On 1/18/07, Tom Lowe wrote: > > Using ubuntu 6.10 and wine packages from > > http://wine.budgetdedicated.com/apt edgy main > > > > TaxACT 2006 ( free download from http://www.taxact.com ) works > > "out-of-the-box" with 0.9.28. Checking for program updates and > > electronic filing "hang" with 0.9.29. > > > > When 0.9.29 hung up on me, I removed it and re-installed 0.9.28 and was > > able to connect and file my tax return. > > We had the same problem with Google Earth, and Rob Shearman > kindly provided a fix: > http://www.winehq.org/pipermail/wine-cvs/2007-January/029362.html > Could be the same problem you hit. > If so, it's already fixed in cvs. > - Dan > Have not tried compiling wine myself yet, but may give it a try this weekend to see if that solves it. Obviously can't try e-filing again, but if checking for updates connects ok, then that might be the fix. Watching the modem lights, it seemed to be trying to connect several times and just not succeeding. In any case, will make an entry in appdb that TaxACT works with 0.9.28 but not 0.9.29 in case anyone is looking for tax software that works with wine. What might be a rough time frame for 0.9.30 to be out, so I can test it with that? (I have an old slow machine, so that may be simpler, but I have been meaning to look into git to see how that works. ) -- Tom Lowe
Re: Questions concering an application I maintain
I'm aware of the WINEDEBUG stuff, just wanted to use something that gives me uniform results, the data it outputs is the same on wine as windows, to speed up comparison I've been going through a WINEDEBUG=+all and have found some points of interest, I just need data to compare that to on a real windows machine (which I am currently setting up in a vm) This project is ultimately going to be moved to lazarus so that I can have a native solution, however wine is damned close to perfect with the corefonts package, a little config tweaking and riched20.dll from the nativemsi installer (which by the way the instructions at http://wiki.winehq.org/NativeMsi) have been failing for me as of wine 0.9.27(tested on 0.9.28 and 0.9.29 still didnt work) fails when i run instmsia.exe with "wine: Unimplemented function mscoree.dll.GetCORSystemDirectory called at address 0x60368820 (thread 0013), starting debugger... Unhandled exception: unimplemented function mscoree.dll.GetCORSystemDirectory called in 32-bit code (0x603688a2). " I have been extracting riched20.dll with cabextract for use. On 1/20/07, Andreas Mohr <[EMAIL PROTECTED]> wrote: Hi, On Fri, Jan 19, 2007 at 02:12:49PM -0800, Duane Clark wrote: > Jacob Alberty wrote: > >What method is best to watch the api interaction going on in my > >application so I can see if wine is returning any weirdness that > >it shouldnt (do normal windows api spy programs work under wine?). > > SPY++, at least older versions, work fine under Wine. He most likely isn't talking about a message spy (i.e. SPY++), but about API tracers. apispy32 (IIRC) was one of the better API tracers on Windows. On Wine you just use WINEDEBUG=+relay and be done with it (unless you need further channels for specific Windows subsystems). Andreas Mohr
Re: Questions concering an application I maintain
Hi, On Fri, Jan 19, 2007 at 02:12:49PM -0800, Duane Clark wrote: > Jacob Alberty wrote: > >What method is best to watch the api interaction going on in my > >application so I can see if wine is returning any weirdness that > >it shouldnt (do normal windows api spy programs work under wine?). > > SPY++, at least older versions, work fine under Wine. He most likely isn't talking about a message spy (i.e. SPY++), but about API tracers. apispy32 (IIRC) was one of the better API tracers on Windows. On Wine you just use WINEDEBUG=+relay and be done with it (unless you need further channels for specific Windows subsystems). Andreas Mohr
Re: Questions concering an application I maintain
Jacob Alberty wrote: What method is best to watch the api interaction going on in my application so I can see if wine is returning any weirdness that it shouldnt (do normal windows api spy programs work under wine?). SPY++, at least older versions, work fine under Wine.
Re: Greenville Revisited, A new look at FontForge
Wierd_w wrote: I am currently shooting to have a full Latin-1, Latin-A, and Latin-B + Greek + Cyrillic glyphset IMO for a first version Latin-1 would be enough, so steam would be useable out of the box. But of course the more glyphs the better. Feedback would be greatly appreciated. Presenting the work often generates more feedback. Could you send your current working version as TTF to wine-devel, so we can play around with it? If it's too big (I'm not sure what's the currently accepted max attachement size, but 200-300k should be fine), upload it to the corresponding bug [1]. If you don't wanna create a bugzilla acount mail it to me, so I can uplaod it. Markus [1] http://bugs.winehq.org/show_bug.cgi?id=4449
Re: Makefiles: Add a default BISONFLAGS variable for widl, wmc, wrc and wpp.
Robert Shearman <[EMAIL PROTECTED]> writes: > I disagree. I had a resource file that had an error because I forgot > to define "IDC_STATIC" to a number and all I got from wrc was an > unhelpful "syntax error" that seemed to point to the wrong line. I > ended up using the debugging option to find out what was causing this > error. If you can suggest a better solution, I'd go for it. Well, I don't know, but I have never had to resort to the parser debugging code for that sort of thing. In worst cases looking at the preprocessed file is normally enough to find the problem. It's true that line numbers are sometimes off in wrc errors, and that should clearly be fixed; but the parser debug stuff is not something that should be exposed to users. Do you still have the file that shows an unhelpful error? You should file a bug with it, and I'll have a look. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Questions concering an application I maintain
I'm not yet sure what the specific issue is with the richedit control yet,
Its not behaving as it should in regards to saving information to a database
in delphi (very delphi specific), So its going to take a lot of testing and
debugging to determine where the fault lies exactly (if i replace
riched20.dll with the one from the native msi installer it works fine). Just
coming up with a test case I can submit will be a feat on its own
considering how many layers I have to dig through, I have to look at my
useage of TDBRichEdit, TDBRichEdit's use of TCustomRichControl and
TCustomRichControl's use of the windows api to pin it down to any one
specific thing, hence the vague description I gave of "weirdness". All in
all considering my small program is dependant on ~50 thousand lines of
delphi code and my using wine in a production system with this program only
uncovering one small bug relating to richedit, I am quite impressed with
wine.
On 1/20/07, Matt Finnicum <[EMAIL PROTECTED]> wrote:
Jacob,
If you have any specific issues with wine's richedit control, you can
always file a bug on bugs.winehq.org (and be sure to mark it as in the
wine-richedit component). I haven't personally tried any api spy
programs, so I can't vouch for them - but I've usually had success
with just using the environmental variable WINEDEBUG
("WINEDEBUG=+richedit wine application.exe"). If you have any
questions about how the richedit component works, feel free to ask me
directly. When making changes, we encourage writing tests (see the
dlls/riched20/tetsts folder) to demonstrate that the new behavior is,
in fact, the correct behavior. Also, when you make a change make sure
to run the tests already there to make sure you haven't caused any
existing tests to fail.
Thanks,
--Matt
Re: Questions concering an application I maintain
On 1/19/07, Jacob Alberty <[EMAIL PROTECTED]> wrote:
I am a delphi developer (not limited to this language, I have done several
projects in C, C#, as well as assembly but for the purposes of this email I
am a delphi developer). I am experiencing some weirdness in regards to the
richedit control in regards to database access (Specifically TDBRichEdit),
Since I am a delphi developer using wine this means I have access to A) My
programs source code, B) Delphis VCL source code (So i can view how delphi
manages the richedit control which in this case is split up among 3 files)
and C) The Wine source code. I have two questions 1) Since Delphi does not
actually implement any of richedits features, merely wraps around them I
should be in the clear to create a patch to wine to correct this
functionality correct? and 2) What method is best to watch the api
interaction going on in my application so I can see if wine is returning any
weirdness that it shouldnt (do normal windows api spy programs work under
wine?).
Jacob,
If you have any specific issues with wine's richedit control, you can
always file a bug on bugs.winehq.org (and be sure to mark it as in the
wine-richedit component). I haven't personally tried any api spy
programs, so I can't vouch for them - but I've usually had success
with just using the environmental variable WINEDEBUG
("WINEDEBUG=+richedit wine application.exe"). If you have any
questions about how the richedit component works, feel free to ask me
directly. When making changes, we encourage writing tests (see the
dlls/riched20/tetsts folder) to demonstrate that the new behavior is,
in fact, the correct behavior. Also, when you make a change make sure
to run the tests already there to make sure you haven't caused any
existing tests to fail.
Thanks,
--Matt
Re: Dead links
I get the 403 error as well, most of time from pages under hypermail/ Google indexed. I don't know when the mailing list archives changed, but the page is still viewable here: http://winehq.org/pipermail/wine-devel/2003-June/017893.html On 1/19/07, Francois Gouget <[EMAIL PROTECTED]> wrote: On Fri, 19 Jan 2007, Tom Wickline wrote: [...] > http://www.winehq.com/hypermail/wine-devel/2003/06/0325.html Does this URL work for you? It gives me a 403 Forbidden error here. -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.
Re: COMCTL32: Fix InitCommonControlsEx prototype
On Fri, 19 Jan 2007, Mike McCormack wrote: > > Thomas Weidenmueller wrote: > > > BOOL WINAPI > > -InitCommonControlsEx (LPINITCOMMONCONTROLSEX lpInitCtrls) > > +InitCommonControlsEx (const INITCOMMONCONTROLSEX *picce) > > The version of the Windows Platform SDK that I'm looking at agrees with Wine. Microsoft has done a lot of work to make their headers more const-correct in the latest SDK (which I will identify as VistaSDK-6.0.6000.0.0-20061107 just to add to the naming confusion). There's quite a lot of work to update the Wine headers to match. I also wonder on the impact it may have on the past and current 'cast qual fixes' work... -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ I haven't lost my mind, it's backed up on tape around here somewhere...
Re: Dead links
On Fri, 19 Jan 2007, Tom Wickline wrote: [...] > http://www.winehq.com/hypermail/wine-devel/2003/06/0325.html Does this URL work for you? It gives me a 403 Forbidden error here. -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.
Re: user32: Some apps pass a color bitmap as a mask to CreateIconIndirect, convert it to b/w
Hi, these patches http://www.winehq.org/pipermail/wine-patches/2007-January/035014.html http://www.winehq.org/pipermail/wine-patches/2007-January/035052.html totally break qip IM icons. (www.qip.ru). I suspect the reason is hidden in GetDIBits(...) - resulting AND mask is not correct. XOR mask is correct. BTW, these patches heal systray taskmgr icon! -- Kirill
Re: COMCTL32: Fix InitCommonControlsEx prototype
Mike McCormack wrote: > The version of the Windows Platform SDK that I'm looking at agrees > with Wine. This is how it is defined in the latest public platform SDK (Windows SDK v6.0). > There is also no reason to make a pointless change to the name of the > argument, so this patch looks pointless and wrong to me. While the name of the parameter is irrelevant, I picked the one used in the PSDK definition to make the implementation more readable when using the latest PSDK documentation. - Thomas
Winelib over Solaris/SPARC
Thanks Eric and Mike for your in-sights. Your feedback has been helpful. Regards, Keyur
Re: [Wine] www.winehq.com newsletter dead forever?
I came to the conclusion that trying to do a back issue is just to hard. I have most of last weeks written...Unfortunately people have been nice enough to implement directx reasonably well so I've been playing EVE Online solidly like a good addict for over two weeks now... I will see if I can get last weeks, which may be a mix of last week and this week, to Brian today/tonight for help with formatting. On 1/18/07, Kai Blin <[EMAIL PROTECTED]> wrote: I'm not sure we really need to do this. It was my impression that on Wineconf 2006, most people would prefer to have WWN again just picking up where we're now, oppoesed to a possible "what happened since the last WWN" issue that took another year to happen. So, with Steven and you, we're three people. Edward, are you still intersted? Cheers, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.
Re: [3/5] wined3d: Use SetupFullscreenWindow() to make the window fullscreen
On 19/01/07, Stefan Dösinger <[EMAIL PROTECTED]> wrote: Am Donnerstag 18 Januar 2007 23:41 schrieb H. Verbeet: > Changelog: > - Use SetupFullscreenWindow() to make the window fullscreen I do not think that SetupFullscreenWindow should stay publically exported from wined3d. I think it would be better if IWineD3DDevice_SetFullscreen calls it, and it is made sure that SetFullscreen is called when needed with a true / false flag. DDraw calls it already, and I think Init3D() calls it too for d3d8 and d3d9. Not sure about IWineD3DDevice_Reset. Probably not, no. DDraw should probably call it through SetFullscreen instead. AFAIK d3d8 / d3d9 don't call SetFullscreen. Currently SetupFullscreenWindow is called from CreateAdditionalSwapChain, but perhaps that should call SetFullscreen then.
Re: [3/5] wined3d: Use SetupFullscreenWindow() to make the window fullscreen
Am Donnerstag 18 Januar 2007 23:41 schrieb H. Verbeet: > Changelog: > - Use SetupFullscreenWindow() to make the window fullscreen I do not think that SetupFullscreenWindow should stay publically exported from wined3d. I think it would be better if IWineD3DDevice_SetFullscreen calls it, and it is made sure that SetFullscreen is called when needed with a true / false flag. DDraw calls it already, and I think Init3D() calls it too for d3d8 and d3d9. Not sure about IWineD3DDevice_Reset. pgpIQj99ipunA.pgp Description: PGP signature
Re: comctl32/tests/updown failures on xp?
On 1/19/07, James Hawkins <[EMAIL PROTECTED]> wrote: It sounds like your build environment isn't set up correctly. The easiest way to work on and compile the tests is to run wine/tools/winapi/msvcmaker under cygwin in Windows. This will create several project files, one for each dll etc, and a winetest project that can be opened with Visual C++ (and converted to a solution). Nah, I prefer bare metal commandline. I like knowing what's going on under the hood. No matter which method you use to compile the tests, you should have the latest Windows SDK installed (not the Platform SDK, which the Windows SDK is replacing). OK, I'll try that... If you run 'make test', you shouldn't see the errors (because they're wrapped by todo_wine). Whoops, forgot about that! When running without 'make test', you have to set the environment variable WINETEST_PLATFORM=wine on wine for the todo_wine to work. Thanks! - Dan
Questions concering an application I maintain
I am a delphi developer (not limited to this language, I have done several projects in C, C#, as well as assembly but for the purposes of this email I am a delphi developer). I am experiencing some weirdness in regards to the richedit control in regards to database access (Specifically TDBRichEdit), Since I am a delphi developer using wine this means I have access to A) My programs source code, B) Delphis VCL source code (So i can view how delphi manages the richedit control which in this case is split up among 3 files) and C) The Wine source code. I have two questions 1) Since Delphi does not actually implement any of richedits features, merely wraps around them I should be in the clear to create a patch to wine to correct this functionality correct? and 2) What method is best to watch the api interaction going on in my application so I can see if wine is returning any weirdness that it shouldnt (do normal windows api spy programs work under wine?).
Re: COMCTL32: Fix InitCommonControlsEx prototype
MSDN agrees with the specification that the data should be constant: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/common/functions/initcommoncontrolsex.asp Mike McCormack wrote: > > Thomas Weidenmueller wrote: > >> BOOL WINAPI >> -InitCommonControlsEx (LPINITCOMMONCONTROLSEX lpInitCtrls) >> +InitCommonControlsEx (const INITCOMMONCONTROLSEX *picce) > > The version of the Windows Platform SDK that I'm looking at agrees > with Wine. > > There is also no reason to make a pointless change to the name of the > argument, so this patch looks pointless and wrong to me. > > Mike > > > >
Re: COMCTL32: Fix InitCommonControlsEx prototype
Mike McCormack wrote: > The version of the Windows Platform SDK that I'm looking at agrees > with Wine. This is how it is defined in the latest public platform SDK (Windows SDK v6.0). > There is also no reason to make a pointless change to the name of the > argument, so this patch looks pointless and wrong to me. While the name of the parameter is irrelevant, I picked the one used in the PSDK definition to make the implementation more readable when using the latest PSDK documentation. - Thomas
Re: Dead links
Le vendredi 19 janvier 2007 à 11:47 +0100, Francois Gouget a écrit : > > I found some dead links on WineHQ. hat should we do about them? Does > anyone want to hunt them down to see if they have simply moved > elsewhere? There are also a bunch of dead links related to the Wine > mailing lists. We cannot simply remove those :-( FYI web.archive.org has most of them archived.
Re: Dead links
On 1/19/07, Francois Gouget <[EMAIL PROTECTED]> wrote: I found some dead links on WineHQ. hat should we do about them? Does anyone want to hunt them down to see if they have simply moved elsewhere? There are also a bunch of dead links related to the Wine mailing lists. We cannot simply remove those :-( I have plans to run the linklint script you wrote a couple years back and fix as many errors as possible. it will be at least a month before I can start on this, Ive got a couple issues remaining here at home to take care of first then I should have the time. http://www.winehq.com/hypermail/wine-devel/2003/06/0325.html Tom
Re: COMCTL32: Fix InitCommonControlsEx prototype
Thomas Weidenmueller wrote: BOOL WINAPI -InitCommonControlsEx (LPINITCOMMONCONTROLSEX lpInitCtrls) +InitCommonControlsEx (const INITCOMMONCONTROLSEX *picce) The version of the Windows Platform SDK that I'm looking at agrees with Wine. There is also no reason to make a pointless change to the name of the argument, so this patch looks pointless and wrong to me. Mike
Dead links
I found some dead links on WineHQ. hat should we do about them? Does anyone want to hunt them down to see if they have simply moved elsewhere? There are also a bunch of dead links related to the Wine mailing lists. We cannot simply remove those :-( On the Wine Press page: http://www.winehq.org/site/press * Luhit July 1, 2006 - CrossOver Wine to join the party with BootCamp & Parallels http://luhit.wordpress.com/2006/07/01/mac-crossover-wine-to-join-the-party-with-bootcamp-parallels/ * OSViews September 13, 2004 - ReactOS - The Open Source Windows NT http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=1454 * OSViews May 30, 2004 - SpecOpS Labs response to Wine Project http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=1454 * OrangeCrate May 20, 2004 - An Interview with Jeremy White, CodeWeavers http://www.orangecrate.com/article.php?sid=710 * OSViews October 28, 2003 - Macromedia and Adobe Graphics Suites to Run on Linux http://www.osviews.com/modules.php?op=modload&name=News&file=article&sid=358&mode=thread&order=0&thold=0 * ConsultingTimes October 17, 2002 - CodeWeavers/Xandros Deal: "Let the Revolution Begin!" http://www.consultingtimes.com/articles/codeweavers/codeweaversxandros.html And another one on the Fun Projects page: http://www.winehq.org/site/fun_projects * http://www.trolltech.com/products/qt/windows.html * http://www.winehq.org/hypermail/wine-devel/2003/01/0153.html * http://www.winehq.org/hypermail/wine-devel/2003/04/0324.html * http://www.winehq.org/hypermail/wine-patches/2002/09/0250.html * http://www.winehq.org/hypermail/wine-cvs/2003/12/0051.html And on the Winelib page there are a bunch of dead hypermail mailing list URLs. Unfortunately there appears to be no easy way to map them to the pipermail archives :-( http://www.winehq.org/site/winelib * http://www.winehq.org/hypermail/wine-devel/2004/04/0192.html * http://www.winehq.org/hypermail/wine-patches/2003/04/0237.html + 6 more * Erwin Wolff http://www.winehq.org/site/[EMAIL PROTECTED] And on the Resources page: http://www.winehq.org/site/resources * WinDoc http://leb.net/wine/WinDoc/ * X2 http://sunsite.lanet.lv/ftp/mirror/x2ftp/msdos/programming/00Main.html * comp.fonts http://rcum.uni-mb.si/local/fontfaq/cf_1.htm * Internet Font Archive http://rcum.uni-mb.si/local/fontfaq/cf_18.htm#GLOSS6 * Curvesoft http://www.curvesoft.com/tools.html -- Francois Gouget <[EMAIL PROTECTED]> http://fgouget.free.fr/ "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U
Re: comctl32/tests/updown failures on xp?
On 1/19/07, Dan Kegel <[EMAIL PROTECTED]> wrote: While getting ready for cs130 (thanks to Lei and James for all the help), I tried building and running comctl32/tests/updown.c standalone on winxp using Visual C++ Express 2005 (the freely downloadable one) and the Platform SDK (also freely downloadable, needed for e.g. user32.lib and .h files). First I tried building it by starting cmd with the visual studio environment vars defined (using the handy Start/Programs/Visual C++/Visual Studio Tools/Visual Studio Command Prompt start menu entry installed by visual C++): cl -DSTANDALONE -D_X86_ -I../../../include updown.c user32.lib gdi32.lib comctl32.lib This failed to compile, complaining about redefinitions in rpc.h. I worked around that as suggested by Lei Zhang by avoiding letting cl see any of the Wine headers but wine/test.h, by doing mkdir wine copy ..\..\..\include\wine\test.h wine cl -DSTANDALONE -D_X86_ updown.c user32.lib gdi32.lib comctl32.lib This failed to compile, complaining about WM_QUERYVISTATE being undefined. I worked around that as suggested by Lei Zhang by defining _WIN32_WINNT to the right value: cl -DSTANDALONE -D_X86_ -D_WIN32_WINNT=0x502 updown.c user32.lib gdi32.lib comctl32.lib That failed to link, complaining it couldn't find user32.lib. I worked around that by doing echo setenv LIB=%LIB% > setenv.bat editing that batch file to append ;C:\Program Files\Microsoft Platform SDK\Lib and running it. That worked (whew), but running the test found two failures: updown.c:509: Test failed: create parent window: the msg 0x0281 was expected, but got msg 0x0007 instead updown.c:522: Test failed: add updown control with edit: in msg 0x0005 expecting lParam 0x4b005b got 0x440065 updown: 133 tests executed (0 marked as todo, 2 failures), 0 skipped. I guess it needs a bit of tweaking. The system I tested it on is running Win XP Professional Version 2002 Service Pack 2. - Dan It sounds like your build environment isn't set up correctly. The easiest way to work on and compile the tests is to run wine/tools/winapi/msvcmaker under cygwin in Windows. This will create several project files, one for each dll etc, and a winetest project that can be opened with Visual C++ (and converted to a solution). No matter which method you use to compile the tests, you should have the latest Windows SDK installed (not the Platform SDK, which the Windows SDK is replacing). I edit and compile the tests in Visual C++, then run the tests from cmd. The tests run flawlessly for me in Windows XP SP2 with IE7 installed. updown: 172 tests executed (0 marked as todo, 0 failures), 0 skipped. 0x0281 is WM_IME_SETCONTEXT and this is what msdn has to say about it: "Sent to an application when a window is activated. A window receives this message through its WindowProc function. " Also, I added the optional flag for the IME messages, because not all versions of Windows send this message, and we don't send it in Wine. It's not pertinent to the updown control tests, but the message sequence will fail on those systems that do send the message if it's not in the tests. Oh, and it fails on Wine from git, too: updown.c:509: Test failed: create parent window: the msg 0x0046 was expected, but got msg 0x030f instead updown.c:521: Test failed: add updown control to parent: the msg 0x0055 was expected, but got msg 0x0210 instead updown.c:522: Test failed: add updown control with edit: in msg 0x0005 expecting lParam 0x4b005b got 0x4b0050 updown: 85 tests executed (0 marked as todo, 3 failures), 0 skipped. It should fail in Wine, because our implementation isn't completely correct :) The failing sequences have the last parameter (todo) of ok_sequence as TRUE because the tests fail, so they are essentially todo_wine. If you run 'make test', you shouldn't see the errors (because they're wrapped by todo_wine). -- James Hawkins
