February 2005 - wine-devel

Re: setupapi: enumerate serial ports
by Alexandre Julliard 25 Feb '05

25 Feb '05

Juan Lang <juan_lang(a)yahoo.com> writes: > +/* Based on code from winspool's info.c */ > +static UINT SETUP_CountSerialPorts(void) > +{ > + UINT i, ret; > + > + /* FIXME: it should be possible for more than four COM ports to exist, not > + * sure why we retain that limit, but winspool does too so go with it. > + */ > + for (i = 0, ret = 0; i < 4; i++) > + { > + if (SETUP_SerialPortExists(i)) > + ret++; > + } > + TRACE("returning %d\n", ret); > + return ret; > +} It would probably be better to use QueryDosDevice here. -- Alexandre Julliard julliard(a)winehq.org

2 2

using safe string functions in wine
by James Hawkins 25 Feb '05

25 Feb '05

Hey, While perusing msdn recently, I stumbled across string safe functions. These functions were created to replace the standard c string handling routines. The following are some design criteria of string safe functions (msdn): * Always NULL-terminate the string. * Always take a destination buffer size. * Always return consistent return codes (an HRESULT). * Support 32-bit and 64-bit environments. * Flexibility. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/h… What is your opinion on whether we should implement and use either the user-mode or kernel-mode (or both) string safe functions? Using these functions instead of the standard c string functions would promote consistency and security in the wine code base. On the other hand, using these functions adds another layer of calls to the code. What are other pro's and con's of using string safe functions? -- James Hawkins

3 2

Microsoft admits targeting Wine users
by Tom 25 Feb '05

25 Feb '05

Here is the link: http://news.zdnet.co.uk/0,39020330,39189180,00.htm Tom

3 2

While we're saying thanks, another thing that works is...
by Holly Bostick 25 Feb '05

25 Feb '05

... the Neverwinter Nights Toolset. Amazingly enough, after I had followed a whole lot of very complex instructions in order to download and compile some half-ancient version of WineX (3.3.2), patch it to nwwine (which is the common name of the patched version that is supposed to get the toolset working; it's in Portage and everything), and add Registry entries and native dlls, it turned out that the toolset ran 'perfectly well' under regular old Wine 20050211 (and in fact not very well under nwwine; couldn't use the menus, etc.). My wine is all hacked together atm, so I'll have to do a clean install to see if it needs anything special other than a couple of native dlls (that it might not need, but I had installed them to the program folder for nwwine) before attempting to add it to the appdb, but it definitely works. I've added custom content to all 7 of the Original Campaign modules using it (and the game is using the content properly, so it's correctly added). Oh, and by the way, thanks for the fix of the titlebars; it's really really nice to have the same window decorations in Wine programs as on the rest of the desktop. Just noticed it today (can't believe I didn't before) and wanted to let you know I appreciate it. Holly

1 0

WineConf agenda ideas
by Brian Vincent 25 Feb '05

25 Feb '05

Over the the past week or so I've harassed some folks about the agenda for WineConf. At this point there's a lot that remains to be filled in, but I need some feedback. Also, I need more ideas for presentations. Does anyone want to present something? It'd be great if someone would volunteer. I think what we're shooting for is a presentation followed by discussion all contained within about one hour. In total we'll have 10 - 12 different topics. Here's the items that are definitely going to be on the agenda: WRS intro Keynote - Alexandre Road to .9 and 1.0 - Dimi ReactOS update - all the ReactOS guys Wine / networking / Samba issues - Juan Lang We've also got some other items, but I need feedback as to whether any of you find this stuff interesting. (So reply and tell me if any of these items sound interesting.) Windows authentication - Andrew Bartlett (um.. haven't asked him yet though) Something else Samba related? - Samba guys Commercial port of a Winelib app and using Wine - an enterprise user CXTest and regression testing - someone from CodeWeavers Version control - Mike Hearn wearing a fire retardant suit DCOM work - Mike or Rob DirectX update - ? Also, if you need to make hotel reservations, there's just a few weeks left to do that. Check out the WineConf page for details: http://www.winehq.org/site/wineconf As people begin to figure out travel plans, the wineconf mailing list will pick up. How to join: http://www.winehq.org/mailman/listinfo/wineconf Let me know if you have any questions. -Brian

1 0

Space Empires: Starfury
by Adam Babcock 25 Feb '05

25 Feb '05

I have posted to the list before about this game. Anyway, a group of us over at the publisher's forum really want to see this game running, so we will be getting in #starfury on freenode this saturday to try and get it to run. We would really appreciate the help if anyone from the list with a more technical background on the inner workings of wine would join in and help. We've set a starting time of around 15h00 UTC, so if any of you wanted to join in, would be greatly appreciated.

2 1

Re: [winecfg] Drive autodetection
by Mike Hearn 25 Feb '05

25 Feb '05

Paul van Schayck wrote: > Changelog: > As last option for drive type detection we try the device node name. Looks good but please try and use the same code style as in the rest of the program. In particular note that winecfg doesn't use Hungarian notation anywhere, eg "szNode" would just be "node" or "nodename". thanks -mike

2 2

Re: wsock32 conformance test
by Juan Lang 25 Feb '05

25 Feb '05

Hey guys, nice work. Minor comments below: > +/* we often pass this size by reference */ > +int sizeofSOCKADDR_IN = sizeof(SOCKADDR_IN); When you pass it by reference, you don't reinitialize it after a call that might modify it, e.g. here: > + /* get port number */ > + getsockname(*sock, (SOCKADDR *) &tmpAddr, &sizeofSOCKADDR_IN); I think it'd be safer to declare a local int initialized to sizeof(SOCKADDR_IN) and pass this by ref instead. > + for (connIndex = 0; connIndex < NUM_CLIENTS; connIndex++) { > + /* accept connection */ > + tmpSock = accept(*sock, (SOCKADDR *) &tmpSockAddr, &sizeofSOCKADDR_IN); Your indenting's off here. (Do you have to use tabs? Ick.) > + connection->serverThread.Handle = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE) &BlockingServerConnection_Run, connection, 0, &connection->serverThread.ID); Please wrap long lines. > + const int numTests = 3; Might as well make that static too. Props for first post :) --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: SHELL32: implement loading and saving of MSI advertised shortcut info
by Juan Lang 25 Feb '05

25 Feb '05

Hi Mike, > + * in that string is parsed an stored. s/an/and/ > +typedef struct volume_info_t > +{ > + DWORD type; > + DWORD serial; > + WCHAR label[12]; /* assume 8.3 */ Shouldn't label's size be 13? 8+3+'.'+NULL? > + if( (buffer.magic&0xffff0000) != 0xa0000000 ) A symbolic constant would be nice here. Thanks, --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Compiling wine dlls for windows
by Michael Jung 25 Feb '05

25 Feb '05

Hello, I would like to test a wine dll I'm working on on windows. Could you please tell me how the wine dlls are build for windows ? (Or beat me to the the place where it is documented.) Thanks, -- Michael Jung mjung(a)iss.tu-darmstadt.de

4 4

Re: [RESEND2] Uninstaller localization
by Dmitry Timoshkov 25 Feb '05

25 Feb '05

"Jonathan Ernst" <Jonathan(a)ErnstFamily.ch> wrote: > Next I'll change the window to a dialog if I can. Thanks. > - wc.lpszClassName = appname; > + wc.lpszClassName = sAppname; > > if (!RegisterClass(&wc)) exit(1); > - hWnd = CreateWindow( appname, "Wine Application Uninstaller", > + hWnd = CreateWindow( sAppname, sAppname, Sorry for not pointing out to it earlier, but it's better to leave the window class name in ASCII. -- Dmitry.

1 0

Re: working installshield?
by Robert Shearman 25 Feb '05

25 Feb '05

Marcus Meissner wrote: >Hi, > >Is there any chance to have a working installshield at some time? > >I don't really want to fall back to the december or even earlier WINE >releases for our spring SUSE Linux product ;) > > I haven't been testing against InstallShield for a while, but last time I checked it was hanging because we do not process window messages during RPCs. If you want to implement this yourself, I can give you details on how to do this. I will get around to this eventually, but at the moment I have other priorities. If the worst happens and InstallShield is still not working, then you can still ship the December ole32 with the most recent Wine. Rob

2 2

WINE: Rendering in Diamond2.x works :-)
by Tobias Burnus 25 Feb '05

25 Feb '05

Hello, I'd like to thank the Winegrowers for providing such a nice flavoured Wine. With the current version, the program Diamond is even able to render the output (at least if one turns off the double buffering): w/o rendering: http://www.physik.fu-berlin.de/~tburnus/wine/diamond2.png w/ rendering: http://www.physik.fu-berlin.de/~tburnus/wine/diamond_rend.png (somehow the menu/tool/status bars are not correctly redrawn and the rendering seems to be too low by the height of a toolbar, but rendering works :-) and hitting Shift-Ctrl-N now works as well (thanks to Dimitry!). Tobias

1 0

wsock32 conformance test
by Thomas Kho 25 Feb '05

25 Feb '05

Hi, We're working on a set of tests for wsock32.dll. So far we've completed a test of blocking network I/O with multiple threads. Before we post to wine-patches, we'd appreciate any critiques/input. Fredy, Doug, and I are UCLA undergraduates in a software engineering course. Thanks for your help, Thomas Kho cc: Fredy Garcia, Douglas Rosenberg (group members) Files available at: http://www.geekymedia.com/viewcvs/cgi/viewcvs.cgi/wine4/wine/dlls/wsock32/t…

1 0

Re: [RESEND] Uninstaller localization
by Dmitry Timoshkov 25 Feb '05

25 Feb '05

"Jonathan Ernst" <Jonathan(a)ErnstFamily.ch> wrote: > This time I didn't translate the WINE_ERR messages and translated another messagebox. It would be better to not touch WINE_ERR lines at all then. > Changelog: > - localization of uninstaller > + /* We load the strings */ > + LoadString( hInst, IDS_APPNAME, sAppname, sizeof(sAppname)); ... > - wc.hIcon = LoadIcon( hInst, appname ); > + wc.hIcon = LoadIcon( hInst, sAppname ); LoadIcon will always fail in the localized case. -- Dmitry.

1 0

Re: Fix recently introduced SEGV in DOCFILE IStorage implementation
by Troy Rollo 24 Feb '05

24 Feb '05

On Thursday 24 February 2005 20:39, Paul Vriens wrote: > Could you send the patch to wine-patches :-). Damn, another typo on my part (I meant it to go there in the first place) On Friday 25 February 2005 03:26, Mike McCormack wrote: > Thanks for finding this problem. I think the root cause of the problem > is that three structures that need to be the same require 3 seperate > tweaks. > > Can you confirm that this patch also fixes the problem for you? I probably could, but given the nature of your patch there's a much more efficient test that should give much greater confidence in it - compiling the affected source files without debugging information using your patch and mine should give identical object files (except for time stamps in the object file headers).

1 1

broken faq.sgml
by Vitaly Lipatov 24 Feb '05

24 Feb '05

Patch http://cvs.winehq.org/patch.py?id=16300 breaks faq.sgml in line <question id="Can-I-bundle-everything-in-one-huge-executable"> during compiling: jade:/home/lav/RPM/BUILD/wine-20050224/documentation/faq.sgml:1716:66:Q: length of name token must not exceed NAMELEN (44) -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

Re: Fix recently introduced SEGV in DOCFILE IStorage implementation
by Paul Vriens 24 Feb '05

24 Feb '05

On Thu, 2005-02-24 at 17:26, Mike McCormack wrote: > Troy Rollo wrote: > > After changing StorageBaseImpl, StorageInternalImpl was not updated to reflect > > the change. > > Thanks for finding this problem. I think the root cause of the problem > is that three structures that need to be the same require 3 seperate tweaks. > > Can you confirm that this patch also fixes the problem for you? > > thanks, > > Mike > Hi Mike, this fixes one of the problems I had with the Uru_Ages_Beyond_Myst_Demo. I still have problems with InstallShield but that's a known problem, and worked on ;-). Cheers, Paul.

1 0

Re: Child windows require IsWindowVisible() test in DestroyWindow()
by Dmitry Timoshkov 24 Feb '05

24 Feb '05

"Dmitry Timoshkov" <dmitry(a)baikal.ru> wrote: > in the msg.c,test_DestroyWindow() test case adding WS_VISIBLE to all > windows except a parent shows that behaviour doesn't change for child > windows but a popup window starts to receive WM_WINDOWPOSCHANGING and > friends indicating that child windows require IsWindowVisible() test. > > I don't want to add that to the real test in order to keep the test > as simple as possible. > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > A test shows that child windows require IsWindowVisible() test > in DestroyWindow() in order to suppress ShowWindow() call. Alexandre, please do not apply this patch, it's wrong. -- Dmitry.

1 0

Re: Uninstaller localization
by Dmitry Timoshkov 24 Feb '05

24 Feb '05

"Jonathan Ernst" <Jonathan(a)ErnstFamily.ch> wrote: > Changelog: > - localization of uninstaller You should not localize WINE_ERR messages, encoding of strings might be incompatible in Wine and underlying system. Also, is it possible to use normal dialog for uninstaller's main window? We could use conventional dialog templates in resources for different locales then. Right now localization will look ugly if lengths of strings in various locales are different. -- Dmitry.

1 0

Fwd: Invitation to the mediation manual
by Duane Clark 24 Feb '05

24 Feb '05

Oops, I inadvertently deleted this from the queue, sorry. Robert Schuster wrote: Dear Wine developers, I wrote some guidelines that should help FOSS projects getting more lively and lowering the barrier for new developers to join. You can find them in form of a small manual here http://projects.mi.fu-berlin.de/w/bin/view/SE/ThesisFOSSIMMediationManual. These ideas are the result of work for my bachelor thesis and have been used successfully at the GNU Classpath project. If the topic is of interest to you, I would be happy to receive criticism and comments concerning the manual or the general idea. For further discussion I have set up a mailing-list (use http://lists.spline.inf.fu-berlin.de/mailman/listinfo/mediation_manual to subscribe or mediation_manual(a)lists.spline.inf.fu-berlin.de to post unsubscribed). Please send your feedback to this list but if you have reasons to contact me directly then just reply to this mail. In case you answer to your project's mailing list please CC me. Best regards Robert Schuster

1 0

Re: Poor performance when using Texas Instruments code generation tools in Wine
by Jan Tore Korneliussen 24 Feb '05

24 Feb '05

We found a simple solution (workaround?) to make this application perform well under WINE. Typical running time of the linking process is down from 30min to 15sec (!). A short explanation: The TI linker allocates and frees a lot of small buffers, typical size 24-32 bytes - but we have not seen allocation of buffers smaller than 24 bytes. Due to fragmentation of the heap in WINE, the number of free buffers smaller than 24 bytes gradually increases. Since the free buffers are organized in 4 lists based on their size, the small (<24 bytes) buffers will go in the first list (which in the current version holds buffers of size <= 32), and each new allocation will have to search past these small buffers. After a while this consumes all processor time, due to the large number of allocations done by the linker. A sufficient fix for this particular application is to introduce a new free list for buffers smaller than 24 bytes. In this way the small buffers will simply be skipped for each allocation, keeping allocation time relatively constant. Note that this is a custom fix for this application, but maybe introducing more free list for small buffers can help other applications which allocate a lot of small buffers. I guess one has to collect data from a lot of apps to make a good tradeoff here. Anyway it was a good thing for us that the heap is "tunable". The diff is with respect to Wine-20050211.tar.gz dlls/ntdll/heap.c -- Jan Tore Korneliussen R&D Engineer TANDBERG Phone +47 6783 8514 mail jan.tore.korneliussen(a)tandberg.net 85c85 < #define HEAP_NB_FREE_LISTS 5 /* Number of free lists */ --- > #define HEAP_NB_FREE_LISTS 4 /* Number of free lists */ 90c90 < 0x10, 0x20, 0x80, 0x200, ~0UL --- > 0x20, 0x80, 0x200, ~0UL

1 0

Re: SHELL32: fix SHSimpleIDListFromPath to do the correct thing for non-existing pathes
by Alexandre Julliard 24 Feb '05

24 Feb '05

Mike McCormack <mike(a)codeweavers.com> writes: > ChangeLog: > * fix SHSimpleIDListFromPath to do the correct thing for non-existing pathes This is causing some test failures (and also some extra successes, I guess we are on the right track...) shelllink.c:177: Test succeeded inside todo block: path_to_pidl returned a NULL pidl shelllink.c:197: Test failed: GetPath returned 'C:\nonexistent\file' shelllink.c:234: Test succeeded inside todo block: GetIconLocation failed (0x00000000) shelllink.c:236: Test failed: GetIconLocation returned 'c:\windows\system\shell32.dll' shelllink.c:238: Test succeeded inside todo block: GetIconLocation returned 0 -- Alexandre Julliard julliard(a)winehq.org

1 0

Fix recently introduced SEGV in DOCFILE IStorage implementation
by Troy Rollo 24 Feb '05

24 Feb '05

After changing StorageBaseImpl, StorageInternalImpl was not updated to reflect the change. ChangeLog: Fix SEGV in IStorage implementation due to structure mismatch between StorageBaseImpl and StorageInternalImpl.

1 0

pcmconverter.c question
by Jeremy White 23 Feb '05

23 Feb '05

The attached patch fixes all remaining test failures in winmm when run in interactive mode on my box with Wineoss. It does so by making msacm conversions start aligned (which lets them finish aligned for my test cases). However, it's clear that Robert Reif intended them not to be aligned. My question is: why? Cheers, Jer

2 1

Re: Re: World Of Warcraft
by fenix＠club-internet.fr 23 Feb '05

23 Feb '05

----Message d'origine---- >De: Colin Wright <c.d.wright(a)tesco.net> >A: Raphael <fenix(a)club-internet.fr> >Sujet: Re: World Of Warcraft >Date: Mon, 21 Feb 2005 21:07:14 +0000 > >Raphael wrote: > >> Ouppsss >> >> better patch >> >> sorry >> >> Regards, >> Raphael >> >> On Monday 21 February 2005 09:58, Alex Woods wrote: >>> On Mon, Feb 21, 2005 at 09:33:29AM +0100, Raphael wrote: >>> > can you try this patch ? >>> >>> Yes, doesn't look any different though. I did notice that with either >>> patch I get this though: >>> >>> 0009:warn:opengl:wglGetProcAddress Did not find extension >>> wglGetExtensionsStringARB in either Wine or your OpenGL library. >>> >>> Whereas without the patches I get this: >>> >>> 0009:trace:opengl:wglGetProcAddress (wglGetExtensionsStringARB) >>> 0009:trace:opengl:wglGetProcAddress returning WGL function (0x561cbf90) >>> 0009:trace:opengl:wglGetCurrentDC () >>> 0009:trace:opengl:wglGetCurrentDC returning 0x7b8 (GL context 0x780d7fd8 >>> - Wine context 0x5593f478) 0009:trace:opengl:wglGetExtensionsStringARB () >>> returning "WGL_ARB_extensions_string WGL_EXT_extensions_string" >>> >>> So something must be broken ;) > >I have absolutely no understanding of this but in the list at the >end of your patch mailed to the list there is... > > { "wglGetSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL}, > >and 5 lines later > > { "wglSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL} > >Since it's the only entry where the string and >pointer/function/object/structure/whatever don't match I wondered it >"wglGetSwapIntervalEXT" ... wglSwapIntervalEXT might be a typo rather >than. > You are right Seems that lionel made a typo :) Thx Regards, Raphael

4 6

Cygwin X11 server, notepad and message boxes
by Krzysztof Foltman 23 Feb '05

23 Feb '05

I'm trying to run notepad on WINE, with DISPLAY environment variable pointing to Cygwin (X Server 6.7.0.0-12) running on my Windows XP machine. It works rather OK-ish, but when I try to close Notepad, it gets stuck in GetMessageW function call after displaying a "text changed, do you want to save ?" dialog box: trace:msg:GetMessageW (1117) mask=0000007f, bits=00000000, changed=00000000, waiting 0009:Call kernel32.ReleaseThunkLock(406ce6f8) ret=409b79a3 0009:Ret kernel32.ReleaseThunkLock() retval=00000000 ret=409b79a3 0009:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,403893f4,ffffffff,00000000,00000000) ret=409b79c7 0009:Call kernel32.WaitForMultipleObjectsEx(00000001,403893f4,00000000,ffffffff,00000000) ret=40ce1838 0009:Call ntdll.NtWaitForMultipleObjects(00000001,406ce32c,00000000,00000000,00000000) ret=404e8989 I guess the bug is not in notepad, but in Wine message handling, as it's not the only program, that freezes after displaying a dialog box. It doesn't happen when MessageBox is called from WM_KEYDOWN handler, but it DOES happen when MessageBox is called from WM_CLOSE handler, but only if WM_CLOSE was sent by system after clicking Close or presing Alt+F4, and not sent or posted by application itself. http://foltman.com/wintest-dlginclose.zip Any idea what it may be ? deadlock ? The version of Wine I'm using was grabbed a couple of hours ago from anonymous CVS. Krzysztof

2 1

Re: rsabase: Make rsabase a wrapper around rsaenh
by Jonathan Ernst 23 Feb '05

23 Feb '05

Le mercredi 23 février 2005 à 13:50 +0100, Michael Jung a écrit : > Ok, that makes rsabase a really trivial dll. Please remove dlls/rsabase/main.c > from cvs (Is there any way to capture this in a diff?) diff -u dlls/rsabase/main.c /dev/null >> rsabase.diff

4 4

Wrong keycodes ?
by George Ginden 23 Feb '05

23 Feb '05

Hi do you guys know anything about that already ? It looks like some keys are not mapped correctly: grep -r VK_* * | grep include/winuser.h include/winuser.h:#define VK_LEFT 0x25 include/winuser.h:#define VK_UP 0x26 include/winuser.h:#define VK_RIGHT 0x27 include/winuser.h:#define VK_DOWN 0x28 These keys are the directional arrows, not the numpad keys... Now look at what wine thinks about those keys when block num is not kicked in: tail -f /projects/tmp/winetrace.log | grep keyboard trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0000 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 83 (0x53) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff96 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0000 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 80 (0x50) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff97 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0000 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 85 (0x55) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff98 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0000 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 88 (0x58) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff99 Kickin'in the block num: trace:keyboard:X11DRV_ToUnicodeEx NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 100 (0x64) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff51 trace:keyboard:X11DRV_ToUnicodeEx NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 98 (0x62) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff52 trace:keyboard:X11DRV_ToUnicodeEx NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 102 (0x66) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff53 trace:keyboard:X11DRV_ToUnicodeEx NumLockMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx AltGrMask = 0010 trace:keyboard:X11DRV_ToUnicodeEx Found keycode 104 (0x68) trace:keyboard:KEYBOARD_MapDeadKeysym no character for dead keysym 0x0000ff54 What's wrong ? Oh, and this output is when using within a edit control. Last but not least, any test against VK_UP VK_DOWN, VK_LEFT, VK_RIGHT fails ... Regards.

2 4

Re: advapi32: Add RegCreate/DeleteKey tests and fixes
by Alexandre Julliard 23 Feb '05

23 Feb '05

James Hawkins <truiken(a)gmail.com> writes: > + /* a key cannot be created directly beneath HKEY_LOCAL_MACHINE or HKEY_USERS */ > + if ((hkey == HKEY_LOCAL_MACHINE || hkey == HKEY_USERS) && !strchr(name, '\\')) { > + *retkey = NULL; > + return ERROR_INVALID_PARAMETER; > + } > + if (!(ret = RegOpenKeyExW( hkey, name, 0, KEY_ENUMERATE_SUB_KEYS, &tmp ))) > { > + /* check for any subkeys > + * a key cannot be deleted if it has any subkeys > + */ > + RegQueryInfoKeyW(tmp, NULL, NULL, NULL, &numSubKeys, NULL, NULL, NULL, NULL, NULL, NULL, NULL); > + if (numSubKeys != 0) { > + if (*name) RegCloseKey(tmp); > + return ERROR_ACCESS_DENIED; > + } These kinds of checks should be done in the lower level functions, not in advapi32 (and in the case of the delete, are done already AFAICT). -- Alexandre Julliard julliard(a)winehq.org

2 4

unixfs.dll: shell namespace extension for the unix filesystem
by Michael Jung 23 Feb '05

23 Feb '05

Hi, this is a first rough cut version of a shell namespace extension to access the unix filesystem from wine. It's primary use-case is for winecfg's drive-mapping propery sheet. It already works for this purpose. It would be cool if 'the COM guys' could take a look at the code, since this is the first time I did something COM'ish. It would be nice if possible miss-conceptions could be found early on. Ciao, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 3

RE: [ros-dev] RE: Collection of wine tools on windows
by Rolf Kalbermatter 23 Feb '05

23 Feb '05

"Casper Hornstrup" <ch(a)csh-consult.dk> wrote: >Yes, but then you need to publish the sources for the non-free application under the LGPL. >When using headers to build your application, you create a derived work of those headers. > >http://www.fsf.org/licensing/licenses/lgpl.html > >"A "work based on the Library" means either the Library or any derivative work under copyright >law: that is to say, a work containing the Library or a portion of it, either verbatim or with >modifications and/or translated straightforwardly into another language. (Hereinafter, translation >is included without limitation in the term "modification".)" > >"4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in >object code or executable form under the terms of Sections 1 and 2 above provided that you accompany >it with the complete corresponding machine-readable source code, which must be distributed under >the terms of Sections 1 and 2 above on a medium customarily used for software interchange." This is rubish. LGPL is understood by most in such a way, that you can use a library in a closed source application as long as you do not make that library a static dependency in your app, meaning that the user could replace that LGPLed library with a newer, compatible version of his and your app still works. Shared libs (or DLLs) clearly are not a static dependency. You are obliged to provide to users of your closed source app and other interested parties the (possibly modified) sources of the LGPL library only, either directly on the media where you distribute your app with or under reasonable terms on request. A download link to Wine seems a very reasonable term to me as long as you didn't make modifications to it, or took care to at least provide a patch with those modifications to the project in question. With public headers for a library, it could be argued that they do not really provide any code (in most cases) and therefore are even less protectable in the interest of portability and interoperation compatibility. If it wouldn't be that way nobody could possibly write a closed source application to run under Linux as the kernel and it's headers are under the even more "restrictive" GPL license and every app has to link to the OS kernel (and use the appropriate headers) in some ways to be operable. Rolf Kalbermatter

2 1

Re: winmm/wineoss: use DSP_POST to flush the frag buffers
by Jeremy White 23 Feb '05

23 Feb '05

Don't apply this; more survey of alternate sound cards shows that DSP_POST does not work as well as advertised everywhere. Jer Jeremy White wrote: > When we get down to the last fragment or two in our output > to the DSP, we should use the SND_DSP_POST ioctl to let the > sound card know to flush those fragments. This allows us to > precisely know when the buffer is empty, and fixes another > set of winmm tests. > > > ------------------------------------------------------------------------ > > Index: dlls/winmm/wineoss/audio.c > =================================================================== > RCS file: /home/wine/wine/dlls/winmm/wineoss/audio.c,v > retrieving revision 1.152 > diff -u -r1.152 audio.c > --- dlls/winmm/wineoss/audio.c 28 Jan 2005 17:21:07 -0000 1.152 > +++ dlls/winmm/wineoss/audio.c 22 Feb 2005 22:17:22 -0000 > @@ -1665,12 +1665,13 @@ > > /* input queue empty and output buffer with less than one fragment to play > * actually some cards do not play the fragment before the last if this one is partially feed > - * so we need to test for full the availability of 2 fragments > + * so we need to test for full the availability of 2 fragments ; the DSP_POST ioctl > + * will let the card know to play out the rest of the fragments > */ > if (!wwo->lpPlayPtr && wwo->dwBufferSize < availInQ + 2 * wwo->dwFragmentSize && > !wwo->bNeedPost) { > - TRACE("Run out of wavehdr:s...\n"); > - return INFINITE; > + TRACE("Run out of wavehdr's, requesting a POST...\n"); > + wwo->bNeedPost = TRUE; > } > > /* no more room... no need to try to feed */

1 0

ole/storage: Problems with 'Myst Uru Demo'
by Paul Vriens 23 Feb '05

23 Feb '05

Hi, eventhough Michael withdrew his patch (http://www.winehq.org/hypermail/wine-devel/2005/02/0687.html) I've tried it, and it crashes in the ole/storage area. I've added some TRACE's and this is the output: 000b:trace:storage:StorageBaseImpl_Release (0x77ece0f8/0x77ece0f8) decremented refcount to 8 000b:trace:storage:StorageBaseImpl_OpenStorage (0x77ece0f8, L"ID_9", (nil), 1012, (nil), 0, 0x28de68) 000b:trace:storage:StorageBaseImpl_OpenStorage Calling IEnumSTATSTGImpl_Construct 000b:trace:storage:IEnumSTATSTGImpl_Construct 0xa2f7c0 / 10680096 000b:trace:storage:IEnumSTATSTGImpl_Construct Calling IStorage_AddRef(0x77ece0f8) 000b:trace:storage:StorageBaseImpl_AddRef (0x77ece0f8) incremented refcount to 9 000b:trace:storage:IEnumSTATSTGImpl_Construct Calling IEnumSTATSTGImpl_Reset 000b:trace:storage:IEnumSTATSTGImpl_Destroy Calling IStorage_Release(0x77ece0f8) 000b:trace:storage:StorageBaseImpl_Release (0x77ece0f8/0x77ece0f8) decremented refcount to 8 000b:trace:storage:StorageBaseImpl_OpenStorage Calling StorageInternalImpl_Construct 000b:trace:storage:StorageInternalImpl_Construct Calling StorageBaseImpl_AddRef(0x77ece0f8) 000b:trace:storage:StorageBaseImpl_AddRef (0x77ece0f8) incremented refcount to 9 000b:trace:storage:StorageBaseImpl_OpenStorage Calling StorageBaseImpl_AddRef(0x77e96a80) 000b:trace:storage:StorageBaseImpl_AddRef (0x77e96a80) incremented refcount to 2012012793 000b:trace:storage:StorageBaseImpl_OpenStorage <-- 00000000 000b:trace:storage:StorageBaseImpl_AddRef (0x77e96a80) incremented refcount to 2012012794 000b:trace:storage:StorageBaseImpl_OpenStream (0x77e96a80, L"FEATURELOG_STDPROPS", (nil), 12, 0, 0x28dd14) 000b:trace:storage:StorageBaseImpl_OpenStream Calling IEnumSTATSTGImpl_Construct 000b:trace:storage:StorageBaseImpl_Release (0x77e96a80/0x77e96a80) decremented refcount to 2012012793 000b:trace:ole:GetErrorInfo (0, 0x28e12c, (nil)) 000b:fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x77e95528): not verifying image 000b:trace:storage:StorageBaseImpl_OpenStream (0x77e96a80, L"FEATURELOG_STDPROPS", (nil), 12, 0, 0x28df4c) 000b:trace:storage:StorageBaseImpl_OpenStream Calling IEnumSTATSTGImpl_Construct wine: Unhandled exception (thread 000b), starting debugger... the refcount with values of 2012012793 look a bit suspicious. Any ideas where to look? Cheers, Paul.

1 1

A call to fix the BeginPaint issue
by Nick Hornback 23 Feb '05

23 Feb '05

Alright, this is probably the last time I will bring it up before I realize that there is essentially no interest in fixing this, but this has been bothering me for quite some time now. A few others have brought it up over the past couple months as well. http://www.winehq.org/hypermail/wine-cvs/2004/10/0395.html As discussed (but nothing really done about it), this patch is directly known to break painting in at least the following applcations: DeusEx Trickstyle Foobar2000 Zoo Tycoon 1 demo This is because, as far as I'm aware, these applications don't send BeginPaint/EndPaint as they technically should, but they all work fine on native Windows. Now, before, it has simply been a matter of reversing the patch, no big deal. However, since the region handling has been moved to the server, that is not possible without a lot of tinkering, something that I just don't have the mad skillz to do. --Nick __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

6 8

Re: rsabase: Make rsabase a wrapper around rsaenh
by Alexandre Julliard 23 Feb '05

23 Feb '05

Michael Jung <mjung(a)iss.tu-darmstadt.de> writes: > As suggested by Alexandre, I removed all implementation code from rsabase and > made it a pure wrapper around rsaenh. I've imitated the scheme used in wine's > unicows.dll to do so. You don't need that, you can forward directly in the spec file. Unicows has to do it differently because of the way it's loaded, but other dlls can use normal forwards. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Poor performance when using Texas Instruments code generation tools in Wine
by Dan Kegel 23 Feb '05

23 Feb '05

Anders wrote: > We have been using TI code generation tools (compiler and linker) on > Wine, and it has worked well. However, when we started evaluating newer > versions of the codegen tools, the linking time was dramatically > increased (from 20 sec to 30 minutes...). > > We have done some profiling using oprofile, and found that most of this > time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll > module. The time needed to locate a free heap block increases gradually, > from a few iterations up to about 15000 in the project we are building. Wow, that's worth looking into! Can you write a small C program that has the same behavior? That would help us reproduce the problem and then solve it. Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 1

richedit (ro): "Select all" or "Copy" crashes wine
by Tobias Burnus 23 Feb '05

23 Feb '05

Hi, in Diamond 2.x (http://www.codeweavers.com/compatibility/browse/name?app_id=865) there is a structure-data richedit (read-only). (Under Windows: http://www.physik.fu-berlin.de/~tburnus/wine/diamond_info.png; it's on the right side; Wine looks similar, but the background is grey and it is not that sleek.) I can flawlessly select some text using the mouse or the keyboard, but if I use the context menu and choose either of - "Select all" - "Copy" (after selecting something) it crashes with: wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x451e158b). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:451e158b ESP:406dfb98 EBP:406dfbb4 EFLAGS:00210246( - 00 -RIZP1) EAX:40425b70 EBX:451eecec ECX:40b77600 EDX:451f2c50 ESI:00000000 EDI:40425b70 Stack dump: 0x406dfb98: 4058a80e 4058a80e 451eecec 00000000 0x406dfba8: 451eecec 404240d8 00000111 406dfbe8 0x406dfbb8: 451e3ba8 40425b70 00000000 00000000 0x406dfbc8: 00000111 00000000 00000301 00000301 0x406dfbd8: 44b68a14 40b6a450 00000000 00020048 0x406dfbe8: 406dfc0c 40ae88f7 00020048 00000111 Backtrace: =>1 0x451e158b RTFSetEditStream in riched32 (0x406dfbb4) 2 0x451e3ba8 RICHED32_WindowProc in riched32 (0x406dfbe8) 3 0x40ae88f7 WINPROC_wrapper in user32 (0x406dfc0c) 4 0x40ae9c1b WINPROC_CallWndProc in user32 (0x406dfc50) 5 0x40aef2c5 CallWindowProcA in user32 (0x406dfc94) 6 0x00563a90fixme:dbghelp_msc:pe_load_debug_directory This guy has FPO information in diamond (+0x163a90) (0x406dfcb4) 7 0x005641c2 in diamond (+0x1641c2) (0x406dfcd4) 8 0x00562ed9 in diamond (+0x162ed9) (0x406dfd40) 9 0x005631e5 in diamond (+0x1631e5) (0x406dfd5c) 10 0x40ae88f7 WINPROC_wrapper in user32 (0x406dfd80) 11 0x40ae9c1b WINPROC_CallWndProc in user32 (0x406dfdc4) 12 0x40aef2c5 CallWindowProcA in user32 (0x406dfe08) 13 0x40ad26f2 DispatchMessageA in user32 (0x406dfe34) 14 0x00567cb7 in diamond (+0x167cb7) (0x005f3d50) 15 0x00000001 (0x005ab278) 16 0x00464520 in diamond (+0x64520) (0x00589f71) 0x451e158b RTFSetEditStream+0x2b in riched32: movl 0x0(%esi),%eax A WINEDEBUG=+relay,+seh,+tid gives the following (excerpt): (This is with Meissner's wine-20050211-1.1 and CXOffice-nightly 05-02-21 and occurs also with earlier versions of WINE. The excerpt below comes from wine-20050211-1.1 with "Select all".) [...] 0009:Call window proc 0x5631b9 (hwnd=0x20048,msg=WM_COMMAND,wp=000000b1,lp=00000000) 0009:Call kernel32._ConfirmSysLevel(40b77600) ret=40ade8c5 0009:Ret kernel32._ConfirmSysLevel() retval=00000000 ret=40ade8c5 0009:Call kernel32.TlsGetValue(00000007) ret=0058c6c9 0009:Ret kernel32.TlsGetValue() retval=403cdc08 ret=0058c6c9 0009:Call kernel32.TlsGetValue(00000007) ret=0058c6c9 0009:Ret kernel32.TlsGetValue() retval=403cdc08 ret=0058c6c9 0009:Call kernel32.TlsGetValue(00000007) ret=0058c6c9 0009:Ret kernel32.TlsGetValue() retval=403cdc08 ret=0058c6c9 0009:Call user32.CallWindowProcA(451e38b0,00020048,00000111,000000b1,00000000) ret=00563a90 0009:Call kernel32._EnterSysLevel(40b77600) ret=40ade890 0009:Call ntdll.RtlEnterCriticalSection(40b77600) ret=4050828b 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4050828b 0009:Ret kernel32._EnterSysLevel() retval=4058a640 ret=40ade890 0009:Call kernel32._LeaveSysLevel(40b77600) ret=40ade920 0009:Call ntdll.RtlLeaveCriticalSection(40b77600) ret=40507fc1 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40507fc1 0009:Ret kernel32._LeaveSysLevel() retval=4058a80e ret=40ade920 0009:Call kernel32._EnterSysLevel(40b77600) ret=40ade890 0009:Call ntdll.RtlEnterCriticalSection(40b77600) ret=4050828b 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4050828b 0009:Ret kernel32._EnterSysLevel() retval=4058a640 ret=40ade890 0009:Call kernel32._LeaveSysLevel(40b77600) ret=40ade920 0009:Call ntdll.RtlLeaveCriticalSection(40b77600) ret=40507fc1 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40507fc1 0009:Ret kernel32._LeaveSysLevel() retval=4058a80e ret=40ade920 0009:Call kernel32.GlobalGetAtomNameW(0000c043,406df99c,0000003c) ret=40aba1ba 0009:Ret kernel32.GlobalGetAtomNameW() retval=00000008 ret=40aba1ba 0009:Call kernel32._EnterSysLevel(40b77600) ret=40ade890 0009:Call ntdll.RtlEnterCriticalSection(40b77600) ret=4050828b 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4050828b 0009:Ret kernel32._EnterSysLevel() retval=4058a640 ret=40ade890 0009:Call kernel32._LeaveSysLevel(40b77600) ret=40ade920 0009:Call ntdll.RtlLeaveCriticalSection(40b77600) ret=40507fc1 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40507fc1 0009:Ret kernel32._LeaveSysLevel() retval=4058a80e ret=40ade920 0009:Call window proc 0x451e38b0 (hwnd=0x20048,msg=WM_COMMAND,wp=000000b1,lp=00000000) 0009:Call kernel32._ConfirmSysLevel(40b77600) ret=40ade8c5 0009:Ret kernel32._ConfirmSysLevel() retval=00000000 ret=40ade8c5 0009:Call user32.GetWindowLongW(00020048,00000004) ret=451e38e2 0009:Call kernel32._EnterSysLevel(40b77600) ret=40ade890 0009:Call ntdll.RtlEnterCriticalSection(40b77600) ret=4050828b 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4050828b 0009:Ret kernel32._EnterSysLevel() retval=4058a640 ret=40ade890 0009:Call kernel32._LeaveSysLevel(40b77600) ret=40ade920 0009:Call ntdll.RtlLeaveCriticalSection(40b77600) ret=40507fc1 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40507fc1 0009:Ret kernel32._LeaveSysLevel() retval=4058a80e ret=40ade920 0009:Ret user32.GetWindowLongW() retval=404240c0 ret=451e38e2 0009:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x451e158b 0009:trace:seh:EXC_RtlRaiseException info[0]=00000000 0009:trace:seh:EXC_RtlRaiseException info[1]=00000000 0009:trace:seh:EXC_RtlRaiseException eax=40425b30 ebx=451eecec ecx=00000000 edx=451f2c50 esi=00000000 edi=40425b30 0009:trace:seh:EXC_RtlRaiseException ebp=406df9ec esp=406df9d0 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00210246 0009:trace:seh:EXC_CallHandler calling handler at 0x562f3e code=c0000005 flags=0 0009:Call kernel32.GetLastError() ret=00547758 0009:Ret kernel32.GetLastError() retval=00000000 ret=00547758 0009:Call kernel32.TlsGetValue(00000006) ret=00547766 0009:Ret kernel32.TlsGetValue() retval=44b60100 ret=00547766 0009:Call kernel32.SetLastError(00000000) ret=005477ba 0009:Ret kernel32.SetLastError() retval=00000000 ret=005477ba 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x54c1e0 code=c0000005 flags=0 0009:Call kernel32.GetLastError() ret=00547758 0009:Ret kernel32.GetLastError() retval=00000000 ret=00547758 0009:Call kernel32.TlsGetValue(00000006) ret=00547766 0009:Ret kernel32.TlsGetValue() retval=44b60100 ret=00547766 0009:Call kernel32.SetLastError(00000000) ret=005477ba 0009:Ret kernel32.SetLastError() retval=00000000 ret=005477ba 0009:Call kernel32.UnhandledExceptionFilter(406df57c) ret=0054e15a 0009:Call kernel32.IsBadCodePtr(41036a10) ret=005503a1 0009:Ret kernel32.IsBadCodePtr() retval=00000000 ret=005503a1 0009:Call kernel32.IsBadCodePtr(1000a670) ret=410386a1 0009:Ret kernel32.IsBadCodePtr() retval=00000000 ret=410386a1 0009:Call ntdll.NtCreateEvent(406df240,001f0003,406df408,00000001,00000000) ret=404c574f 0009:Ret ntdll.NtCreateEvent() retval=00000000 ret=404c574f wine: Unhandled exception (thread 0009), starting debugger... 0009:Call ntdll.RtlInitUnicodeString(406df238,40568a80 L"Machine\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug") ret=404c 57e0 [...] Tobias

1 0

Checking Wine's spec files
by Francois Gouget 23 Feb '05

23 Feb '05

The recent problems with -noname in shell32.spec got be to dig up an old script I had which reads spec and dumpbin files and processes them. I then retrofitted it so it could do some hopefully useful checks for this kind of issues. So this script works by comparing the output of winedump or dumpbin on the Windows dlls for as many platforms as are available (I have 7 so far) with the contents of Wine's spec files. It then applies a number of rules to try to detect problems. However the information we can extract from the Windows dlls is incomplete so this script uses heuristics. This means the problems it reports should be treated with a grain of salt. Running the check script To download and run the check script, see the instructions are on my web site: http://fgouget.free.fr/wine/checkspec-en.shtml Then you can run it as follows: ./check_spec --verbose ~/wine/dlls/shell32.spec And here is a description of the checks it performs so far, illustrated with the output for shell32.dll. Comments and suggestions for more checks or improvements are welcome. I'll wait a bit (and then start sending some patches unless someone else wants to tackle this (could be a nice janitorial project). Notes: * It would be nice if winedump could dump the Platform SDK's .lib files. These files must have an explicit mention of which entry points have the -noname property so this would give us a more reliable source of information than the heuristics in this script. * dumpbin will something special when an API is being forwarded: 40 [NONAME] (forwarded to shlwapi.PathIsRelativeW) But winedump prints nothing special. It would be nice to add this functionality to winedump. -noname vs. ordinal internal consistency ----------------------------------------- This check verifies that all APIs which have the '-noname' property, also have an explicit ordinal. This is the only check which does not depend on dumps of the Windows dlls. No problem found here. APIs which should not have an explicit ordinal ---------------------------------------------- The script scans the Wine spec file for APIs which have both a name and an explicit ordinal. For each of these, the script looks up the API by name on the Windows platforms and collates a list of the corresponding ordinals. If it finds more than one ordinal then it considers the API should not be given an explicit ordinal. In that case it reports how many times the API was found with the right ordinal on Windows, and how many different values were found. If the former is 0 or 1 then it's clear the API should not be given an explicit ordinal. If the latter is 2 then things are maybe not so clear. These 64 APIs should not have an ordinal: SHGetDataFromIDListA (correct 0 times, found 5 values) StrChrIW (correct 0 times, found 3 values) SheGetCurDrive (correct 0 times, found 5 values) ShellAboutW (correct 0 times, found 5 values) SheFullPathA (correct 0 times, found 5 values) DllGetClassObject (correct 0 times, found 5 values) SheGetDirA (correct 0 times, found 5 values) SheGetPathOffsetW (correct 0 times, found 5 values) SheGetDirW (correct 0 times, found 5 values) DragFinish (correct 0 times, found 5 values) StrCmpNW (correct 0 times, found 3 values) StrNCmpA (correct 0 times, found 3 values) StrCmpNIA (correct 0 times, found 3 values) ShellExecuteW (correct 0 times, found 5 values) SheChangeDirW (correct 0 times, found 5 values) Shell_NotifyIconW (correct 0 times, found 5 values) StrCpyNA (correct 0 times, found 3 values) SheRemoveQuotesW (correct 0 times, found 5 values) StrCmpNA (correct 0 times, found 3 values) ShellExecuteExA (correct 0 times, found 5 values) StrRStrIA (correct 0 times, found 3 values) StrStrA (correct 0 times, found 3 values) StrStrW (correct 0 times, found 3 values) StrChrA (correct 0 times, found 3 values) SheShortenPathA (correct 0 times, found 5 values) StrNCmpIW (correct 0 times, found 3 values) StrRChrIA (correct 0 times, found 3 values) StrChrIA (correct 0 times, found 3 values) SheConvertPathW (correct 0 times, found 5 values) StrNCpyW (correct 0 times, found 3 values) DragAcceptFiles (correct 0 times, found 5 values) StrRStrIW (correct 0 times, found 3 values) StrNCmpIA (correct 0 times, found 3 values) Shell_NotifyIconA (correct 0 times, found 5 values) ShellExecuteA (correct 0 times, found 5 values) ShellExecuteEx (correct 0 times, found 5 values) SheChangeDirA (correct 0 times, found 5 values) StrStrIA (correct 0 times, found 3 values) SheChangeDirExA (correct 0 times, found 5 values) ShellAboutA (correct 0 times, found 5 values) SheChangeDirExW (correct 0 times, found 5 values) ShellExecuteExW (correct 0 times, found 5 values) StrNCmpW (correct 0 times, found 3 values) StrChrW (correct 0 times, found 3 values) DragQueryFile (correct 0 times, found 5 values) StrRStrW (correct 0 times, found 3 values) StrCpyNW (correct 0 times, found 3 values) DragQueryFileA (correct 0 times, found 5 values) StrNCpyA (correct 0 times, found 3 values) DragQueryFileW (correct 0 times, found 5 values) Shell_NotifyIcon (correct 0 times, found 5 values) StrStrIW (correct 0 times, found 3 values) SHGetDataFromIDListW (correct 0 times, found 5 values) SheGetDirExW (correct 0 times, found 5 values) SheFullPathW (correct 0 times, found 5 values) SheRemoveQuotesA (correct 0 times, found 5 values) SheShortenPathW (correct 0 times, found 5 values) StrRStrA (correct 0 times, found 3 values) StrCmpNIW (correct 0 times, found 3 values) StrRChrW (correct 0 times, found 3 values) SheSetCurDrive (correct 0 times, found 5 values) StrRChrIW (correct 0 times, found 3 values) DragQueryPoint (correct 0 times, found 5 values) StrRChrA (correct 0 times, found 3 values) APIs which have the wrong ordinal --------------------------------- This check collates a list of Windows ordinals for the API exactly as above. But it emits a warning about the API only if it found a single ordinal value on Windows and that ordinal does not match Wine's ordinal. These 1 APIs have the wrong ordinal: ReadCabinetState (is 654 on api2003es) (may be best to ignore this one) APIs which should have the -noname property -------------------------------------------- Again this check concerns APIs which have both an explicit ordinal and a name. This time it counts the number of Windows platforms where the API is not exported by name but which still have an entry point with the right ordinal and no name. If more than one such platforms were found, the script considers the API should have the '-noname' property. These 28 APIs should have the -noname property: SHRegOpenKeyW (507 has no name on api95 api98 apint4) SHGetNetResource (69 has no name on all) DAD_SetDragImageFromListView (177 has no name on all) ReceiveAddToRecentDocs (647 has no name on api95 api98 apime apint4 api2000) SHRegQueryValueExW (511 has no name on api95 api98 apint4) PifMgr_GetProperties (10 has no name on api95 api98 apime apint4 api2000 apixp) SHChangeRegistrationReceive (646 has no name on all) RestartDialogEx (730 has no name on apixp) SHRegQueryValueA (508 has no name on api95 api98 apint4) SHWaitOp_Operate (648 has no name on all) SHNetConnectionDialog (160 has no name on all) InvalidateDriveType (65 has no name on all) SHRegCloseKey (505 has no name on api95 api98 apint4) SHHandleDiskFull (185 has no name on all) SHFindComputer (91 has no name on all) SHRegQueryValueW (510 has no name on api95 api98 apint4) SHGlobalDefect (197 has no name on all) PifMgr_OpenProperties (9 has no name on api95 api98 apime apint4 api2000 apixp) SHRegQueryValueExA (509 has no name on api95 api98 apint4) PifMgr_SetProperties (11 has no name on api95 api98 apime apint4 api2000 apixp) SHCreatePropSheetExtArrayEx (194 has no name on all) RealDriveTypeFlags (525 has no name on all) SHChangeNotifyReceive (643 has no name on all) SHRegOpenKeyA (506 has no name on api95 api98 apint4) SHIsBadInterfacePtr (84 has no name on all) SHRegDeleteKeyW (512 has no name on apint4) PifMgr_CloseProperties (13 has no name on api95 api98 apime apint4 api2000 apixp) DragQueryInfo (76 has no name on all) APIs which should not have the -noname property ------------------------------------------------ This the same check as above but with a different analysis of the results. Namely, the script considers the API should not have the -noname property if one of the following two conditions is met: * the API is exported by name on all platforms * the API's ordinal corresponds to another API on one of the platforms. These 33 APIs should not have the -noname property: FileMenu_AppendItem (115 has other names on apixp api2003es) FileMenu_Create (114 has other names on apixp api2003es) DragFinish FileMenu_DeleteItemByFirstID (141 has other names on apixp api2003es) FileMenu_DrawItem (105 has other names on apixp api2003es) FileMenu_DeleteAllItems (104 has other names on apixp api2003es) FileMenu_DeleteItemByCmd (117 has other names on apixp api2003es) FileMenu_DeleteItemByIndex (140 has other names on apixp api2003es) FileMenu_DeleteSeparator (142 has other names on apixp api2003es) FileMenu_ReplaceUsingPidl (113 has other names on apixp api2003es) FileMenu_MeasureItem (112 has other names on apixp api2003es) ILAppend (154 has other names on api2003es) FileMenu_AppendFilesForPidl (124 has other names on apixp api2003es) DragAcceptFiles FileMenu_InitMenuPopup (109 has other names on apixp api2003es) FileMenu_AbortInitMenu (120 has other names on apixp api2003es) FileMenu_GetLastSelectedItemPidls (107 has other names on apixp api2003es) FileMenu_EnableItemByCmd (143 has other names on apixp api2003es) FileMenu_HandleMenuChar (108 has other names on apixp api2003es) Shell_GetImageList (71 has other names on api2003es) FileMenu_GetItemExtent (144 has other names on apixp api2003es) FileMenu_TrackPopupMenuEx (116 has other names on apixp api2003es) DragQueryFile FileMenu_FindSubMenuByPidl (106 has other names on apixp api2003es) FileMenu_Invalidate (111 has other names on apixp api2003es) DragQueryFileA DragQueryFileW FileMenu_AddFilesForPidl (125 has other names on api95 api98 apime apint4 api2000 apixp api2003es) FileMenu_Destroy (118 has other names on apixp api2003es) ShellDDEInit (188 has other names on api95 api98 apint4) DragQueryPoint FileMenu_InsertUsingPidl (110 has other names on apixp api2003es) IsUserAdmin (680 has other names on api2003es) Missing APIs ------------ The script only reports an API as missing if it is present on all platforms but missing from Wine's spec file. That's per Wine's policy to not add APIs that are only present on newer platforms unless we have a good reason to. These 2 APIs are missing: SHInvokePrinterCommandW SHInvokePrinterCommandA -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

2 5

Re: Should winecfg drive detection create device symlinks
by Michael Jung 23 Feb '05

23 Feb '05

On Wednesday 23 February 2005 08:40, Paul van Schayck wrote: > <mjung(a)iss.tu-darmstadt.de> wrote: > > I think winecfg does this already. Take a look at the function > > apply_drive_functions in drive.c. Does'nt it work for you? > > As far as I can tell it does not. We do not store the device node path > in the detect functions so I see no way we make symlinks from > dosdevices/ to device nodes. Sorry, I misunderstood you. > Yeah, the auto detect works here just fine (symlinks are created). > Just one problem I haven't come up with a sollution yet. My floppy has > as fs type in fstab 'auto'. This means my floppy comes up as a fixed > harddrive. I have the same problem for my cdrom. As a heuristic, how about the following: If fs type is auto and the referenced device node is /dev/fd*, we assume it's a floppy. If fs type is auto and the referenced device node is not /dev/fd*, we assume it's a cdrom. Are floppies always mapped to /dev/fd* or are there other valid device nodes? How about BSD/Solaris? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Re: advapi32: Don't free csp dll when a container is deleted
by Michael Jung 23 Feb '05

23 Feb '05

On Wednesday 23 February 2005 00:04, Michael Jung wrote: > Changelog: > Don't unload Cryptographic Service Provider DLL when a key container is > deleted. There might still be open handles. Don't apply this patch, please. It fixes the crash in the "Uru Demo" installer only by coincidence. We really have to implement a reference counting scheme to solve this problem properly. Ciao, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0

Re: msi: detect registry keypaths
by Alexandre Julliard 23 Feb '05

23 Feb '05

Aric Stewart <aric(a)codeweavers.com> writes: > - FIXME("Only working for installed files, not registry keys\n"); > - if ( GetFileAttributesW(path) != INVALID_FILE_ATTRIBUTES ) > - rrc = INSTALLSTATE_LOCAL; > + if (path[0]=='0') > + { > + FIXME("Registry entry.. check entry\n"); > + if (path[0]) > + rrc = INSTALLSTATE_LOCAL; > + else > + rrc = INSTALLSTATE_ABSENT; > + } Since path[0] is first checked against '0' this test doesn't seem to make much sense. What are you trying to do here? -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: status of wine dll's
by Juan Lang 22 Feb '05

22 Feb '05

Alexandre wrote: > I'm not convinced we want to remove it completely, there just might be > an app somewhere that looks for it explicitly, and it doesn't cost > anything to keep it. If so, that app won't work on windows; most versions of windows only ship with rsaenh.dll. The only ones that have rsabase are really old versions, and those that are sold in the crypto-export-restricted countries. I think removal makes more sense, keeping rsabase costs a little confusion. --Juan __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

1 0

Re: dlls/gdi: fix GetGlyphOutline(resend)
by Huw Davies 22 Feb '05

22 Feb '05

On Tue, Feb 22, 2005 at 11:31:30PM +0900, TANABE Hiroshi wrote: > @@ -2903,7 +2901,8 @@ > TM.tmStruckOut = font->strikeout; > > /* Yes TPMF_FIXED_PITCH is correct; braindead api */ > - if(!FT_IS_FIXED_WIDTH(ft_face)) > + if(!FT_IS_FIXED_WIDTH(ft_face) && > + (pOS2->version == 0xFFFFU || pOS2->panose[3]!=9)) > TM.tmPitchAndFamily = TMPF_FIXED_PITCH; > else > TM.tmPitchAndFamily = 0; Isn't this a bug in FreeType? If we have to have this in Wine, could you use the defines in wingdi.h instead of the '3' and the '9'? Huw. -- Huw Davies huw(a)codeweavers.com

1 0

regression
by Oliver Stieber 22 Feb '05

22 Feb '05

Hi, I've had a regression with Creatures 2 between and 2005-02-03 and 2005-02-19.. Creatures 2 makes heavy use of out-of-process COM for it's components, the main screen used to work ok (but the components didn't). Now it starts up and I get the error. "err:virtual:NtMapViewOfSection Sizes larger than 4Gb not supported" I'll try to find out what patch caused the regression. 1 0x405168ec RaiseException 2 0x5f45394berr:virtual:NtMapViewOfSection Sizes larger than 4Gb not supported ?? in mfc42 (0x406ffcd8) 3 0x5f40d992 ?? in mfc42 (0x0047ceb8) ...stack missing. other threads are waiting for ConnectNamedPipe,sync.c:1311 RPCRT4_Receive,rpc_message.c:312 RPCRT4_process_packet,rpc_server.c:316 ... RPCRT4_server_thread, rpc_server.c:506 User_update_thread, dsurface/user.c:515 RPCRT4_worker_thread, rpc_server.c:353 ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

2 4

Poor performance when using Texas Instruments code generation tools in Wine
by Anders Rønningen 22 Feb '05

22 Feb '05

Hi ! We have some performance problems with Wine that we could use some help on.. Here's the story: We have been using TI code generation tools (compiler and linker) on Wine, and it has worked well. However, when we started evaluating newer versions of the codegen tools, the linking time was dramatically increased (from 20 sec to 30 minutes...). We have done some profiling using oprofile, and found that most of this time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll module. The time needed to locate a free heap block increases gradually, from a few iterations up to about 15000 in the project we are building. We suspect that this may be due to fragmentation caused by the heap allocate/free algorithms. We do not have the same problem when building the code under Windows, so we tried to use the native ntdll.dll from Windows instead of ntdll.dll.so, hoping that this would solve the performance issue. We are aware that this is not recommended, but wanted to give it a try anyway. We added the dll file to the global dll-override section in the config file under ~/.wine/config, but it seems like Wine just looks for the builtin dll. We see from strace that we access the correct config file at startup. Is override of ntdll not supported, or have we missed something? If it is supported, is it likely that it is going to work? We have read some posts in the newsgroup about the heap issues. It seems that people agree that the heap should be improved, either by tweaking the existing code, or by using another heap implementation. Is any work planned on this? -- Regards / Mvh - Anders Rønningen Engineer R&D TANDBERG Phone: +47 67 125 125 Direct: +47 67 838 584 Mobile: +47 97 791 217 Fax: +47 67 125 234 mailto:anders.ronningen@tandberg.net http://www.tandberg.net

6 5

Re: SHELL32: cleanup, create unicode versions of some functions
by Dmitry Timoshkov 22 Feb '05

22 Feb '05

"Mike McCormack" <mike(a)codeweavers.com> wrote: > ChangeLog: > * cleanup, create unicode versions of _ILCreateFromPath, > _ILCreateGuidFromStr, and _ILCreateFromFindData > @@ -524,7 +516,7 @@ BOOL WINAPI ILIsEqual(LPCITEMIDLIST pidl > _ILSimpleGetText(pidltemp1, szData1, MAX_PATH); > _ILSimpleGetText(pidltemp2, szData2, MAX_PATH); > > - if (strcasecmp ( szData1, szData2 )!=0 ) > + if (strcasecmp( szData1, szData2 )) > return FALSE; > > pidltemp1 = ILGetNext(pidltemp1); > @@ -574,7 +566,7 @@ BOOL WINAPI ILIsParent(LPCITEMIDLIST pid > _ILSimpleGetText(pParent, szData1, MAX_PATH); > _ILSimpleGetText(pChild, szData2, MAX_PATH); > > - if (strcasecmp ( szData1, szData2 )!=0 ) > + if (strcasecmp( szData1, szData2 )) > return FALSE; As a common rule strcasecmp should never be used in Wine code, since it introduces problem with portability and unexpected side effects when locale of the underlying system differs from a Wine one. You could make it a part of your clean up as well :-) -- Dmitry.

3 4

Microsoft genuine downloads looking for wine
by Ivan Leo Puoti 22 Feb '05

22 Feb '05

As some of you may know, Microsoft is planning to totally restrict access to the Microsoft download center to all non-genuine windows users. So you would expect some check for pirated copies of windows to be involved. If you visit the download center with IE you get an activex control, but if you try with Firefox, you'll have to download a little program, that returns a code you have to copy into the download page, to get access to the download you selected. By quickly looking at the program, I noticed it looks for a registry key, this key is... SOFTWARE\Wine\Wine\Config the wine configuration key. the Windows Genuine Advantage program press release http://www.microsoft.com/presspass/press/2005/jan05/01-26GenuineAdvantagePR… says that in the second half of 2005, all users connecting to the Microsoft download center or to windows update will have to validate their copy of windows. Interestingly if you run the validation program on wine, and the version of windows you're emulating is prior to 2000 or is windows server 20003, you get a message saying a validation code couldn't be found, because of technical difficulties or because you're running an unsupported operating system. If you set winver to win2000, you'll get a validation code that doesn't work, this may be a bug in wine, or in the validation program. A valid and working code is returned if the version is set to xp. Still, even if this is only an initial attempt, they appear to want to discriminate wine users, while this may be acceptable for operating system components/updates, this is probably a violation of anti-trust law for all other downloads. It's also the first time Microsoft acknowledges the existence of Wine. Ivan Leo.

15 19

How do I extract the symbols from a pdb file?
by Fredrik �hrstr�m 22 Feb '05

22 Feb '05

Hi all! I am trying to to write a tool that uses the code in dbghelp to do this but I am unclear on which interface I should use to do this. Can I link to dbghlp.dll.so or do I have to write a tool inside Wine for this? I am going to use the symbol info to load a full minidump and extract information from it.... Thanks! Fredrik Öhrström _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

1 0

Collection of wine tools on windows
by Boaz Harrosh 22 Feb '05

22 Feb '05

There is a question at the end. Background: I'm putting up a Web-corner with ATL & MFC for other (gcc for now) Compilers. It will include tools, links, documentation, example makefiles, and so on to let people take an MSVC project and compile it under GCC. (+Winelib on other than windows platforms) My first release target is Windows/ReactOS MinGW-PE. What I did is take the work I've done on Linux and port it back to MinGW. At first, as I expected, it did not work at all. So what I did without hesitation is fetch the Wine headers set, + (yes) wine-msvcrt. Completely removed MinGW originally supplied headers put Wine on the Include path, and voila It was compiling Just like on Linux. (Well it didn't link, than it didn't run, because of the weak symbols thing but I fixed all that). I find 3 things bad about MinGW headers. (Please don't take this as flame. I have all the admiration for all involved and no offense is intended) 1) MinGW header-set are Evil - Because they are ugly, with this, no variables names, and all this style for machines guide. This I already carry for 10 years so here it is off my chest. 2) Win32 is not complete - I would say that MFC and ATL/WTL are a very good exercise for the completeness of the Win32 API. Well the wine stuff have every thing we need, MinGW does not 3) msvcrt - msvcrt compatibility is far from satisfactory on MinGW. Wine, since they had to re-implement msvcrt.dll had to have all these funny MS permutations of the c run time. Compiling on MinGW is almost like using wine without MBCS defined. MinGW headers are mainly derived from GCC c-runtime, with a few adjustments for the -mno-cygwin mode. But they are greatly missing all the esoteric stuff that is needed by MFC and ATL. Wine is perfect, thanks to CodeWeavers, need to run all these MFC apps out there. 4) (I know I said 3) It is time, that all projects collaborate on ONE set of headers and ReactOS is the bridge to that - It is a long time do, that Wine's Set of headers are adopted by all projects. MinGW concentrates on PE gcc compilers, and pass the Win32 project to wine. Wine will release a headers only package for every body to use. (This is what I'll do on first release of my project) [Question to the ReactOS team] The windres utility is insufficient for Most of the projects out there. For example one reason my project is not already on the air. (And hence my post) is that it refuses to compile my Toolbar resource tag. (And what is an MFC app with out a toolbar). I have seen some work done on porting wrc to PE is that work done and will you have a pre-compiled binary package for use to use on windows/ReactOS. Same applies to widl. ReactOS should adopt all these Wine tools as part of their regular tools portfolio. MinGW should adopt Wine's / ReactOS's leadership on all these technologies and supply-link to them by default. Go duplicate all these goodies the wine guys are preparing for us with widl. Again guys please let the passed be gone. And put our differences behind us. There are grate things happening, clearly Wine is the Leader here, lets do this sooner than later. Dimi I need your help here Free Life Boaz

5 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel February 2005