- wine-devel - winehq.org

RE: Why is our OutputDebugString a server request?
by Raghavan Gurumurthy 13 Sep '04

13 Sep '04

I agree - I got stumped on this very issue when I got into Wine last year. I was used to relying on these trace messages and it took me a while to understand where the messages were actually being sent! //raghavan -----Original Message----- From: Shachar Shemesh [mailto:wine-devel@shemesh.biz] Sent: Monday, September 13, 2004 9:11 AM To: pouech-eric(a)wanadoo.fr Cc: Wine Development Subject: Re: Why is our OutputDebugString a server request? Pouech Eric DMI AEI CAEN wrote: > so that debuggers can intercept it (especially ones with GUI) and do > what they want with it. > A+ > > > > > Message du 13/09/04 17:50 > > De : "Shachar Shemesh" > > A : "Wine Development" > > Copie à : > > Objet : Why is our OutputDebugString a server request? > > > But as far as I can see, this means that Windows debuggers won't get it. Wouldn't it be better to implement it the Win32 way? At the very least, implement it ALSO as the Win32 way? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

1 0

A window update problem in Dutch tax program.
by Rein Klazes 13 Sep '04

13 Sep '04

Hi, I am looking in a display problem in the electronic declaration programs of the Dutch tax office. Here is a schematic of the windows involved: +--10022-------------------------------+ | | | +--100c6-------------------------+ | | | | | ..20110... | | | . . | | | . . | | | +-20114--+ | | | | | | | | | | | | | +--------+ | | | | | | | | +--------------------------------+ +--------------------------------------+ [10022] is a top level window. One of its child [20114] has itself a child window [20110] that initially lies outside the parent client area. A series of calls to ScrollWindowEx() brings it inside, simulating a drop down listbox. Now [20114] should normally not be visible because it lies behind another child of the main window: [10022] | +--[20114] | | | +--[20110] | | +-[100c6] | + ... No window styles that could affect this behavior (WS_CLIPCHILDREN, WS_CLIPSIBLINGS, WS_EX_TRANSPARENT) are used. Here the partial output of info wnd command: 00010022 WindowIB2003 14cb0000 00000000 Aangifte 2003 00020114 WindowIB2003 50000000 00000000 -- Empty -- 00020110 @LISTBOX 50800141 00000000 -- Empty -- 000100c6 WindowIB2003 50000000 00000000 TheContent The program first validates the update region of the main window with the rect of [20114]. |0009:Call user32.ValidateRect(00010022,4070f988) ret=00426f64 ... |trace:win:RedrawWindow Update region of hwnd 0x10022 is nil |0009:Ret user32.ValidateRect() retval=00000001 ret=00426f64 As the extra trace message reports, this window has a null update region at this point. Then the first scroll is requested: |0009:Call user32.ScrollWindowEx(00020114,00000000,0000000a,4070f6e4,4070f6b4,00000000,00000000,00000001) ret=00426fd1 |trace:scroll:ScrollWindowEx 0x20114, 0,10 hrgnUpdate=(nil) rcUpdate = (nil) (0,-47)-(71,0) 0001 |trace:scroll:ScrollWindowEx clipRect = (0,0)-(71,10) ... |0009:Ret user32.ScrollWindowEx() retval=00000001 ret=00426fd1 directly after this the same scroll rectangle (4070f6e4) is invalidated: |0009:Call user32.InvalidateRect(00020114,4070f6e4,00000001) ret=00426fe6 |trace:win:RedrawWindow 0x20114 (0x137e) rect 0,0-71,10 (nil) flags=0005 |trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE ... |0009:Ret user32.InvalidateRect() retval=00000001 ret=00426fe6 and directly UpdateWindow is called: |0009:Call user32.UpdateWindow(00020114) ret=00426fef |0009:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,4070f460,00000000,000000ff,00000000) ret=40764927 |trace:event:EVENT_ProcessEvent called. UpdateWindow calls RedrawWindows that first looks for outstanding events, that is where the trouble starts: |trace:event:EVENT_ProcessEvent Got event Expose for hwnd/window 0x20114/3a001aa, GetFocus()=0x20112 |trace:x11drv:X11DRV_Expose win 0x20114 (3a001aa) 0,0 71x47 ... |0009:Call user32.RedrawWindow(00010022,4070f010,00000000,00000085) ret=40d519a2 |trace:win:RedrawWindow 0x10022 ((nil)) rect 291,142-362,189 (nil) flags=0085 |trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE RDW_ALLCHILDREN and the main window and child [100c6] find them selves invalidated: |trace:win:RDW_Paint hwnd 0x10022 [0x1382] -> hrgn [0x139e], flags [0085] ... |trace:win:RDW_Paint hwnd 0x100c6 [0x138a] -> hrgn [0x139e], flags [0085] after the final scroll, a WM_PAINT message is dispatched to [100c6] and the scrolled window [20114] is invisible. I am not sure what the real problem is: either the expose event should not be there or the handling of the event is wrong. For the latter case: the handling in expose_window() sure does not expect to make visible a normally obscured window. Any suggestions? The program is available on-line, but I would need to give some instruction for non-Dutch users. Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

Re: Directx9
by Ivan Leo Puoti 13 Sep '04

13 Sep '04

> If we as a project are committed to doing 0.9, 1.0+ releases it means we > can't simply break code people are using to play their games for months > at a time and shrug it off After 1.0 there will be a stable and a development branch, the stable one for users, and the development one for new stuff, where it doesn't matter if things are broken for a while. A bit like the kernel with 2.4 stable and 2.5 full of broken/buggy stuff until 2.6 is ready, and so on. At least that's how most projects work. Ivan.

3 2

Re: Http Fixes
by Marcus Meissner 13 Sep '04

13 Sep '04

On Mon, Sep 13, 2004 at 11:38:32AM +0100, Robert Shearman wrote: > Hi, > > I have seen one server that likes to return "ICY" instead of "HTTP/1.x". > This patch allows the connection to the server continue, as native does. This would be "icecast" I suspect ;) Ciao, Marcus

1 0

Re: Wininet: InternetSetStatusCallback Fix
by Robert Shearman 13 Sep '04

13 Sep '04

Robert Shearman wrote: > Hi, > > You can call InternetSetStatusCallback on a HTTP handle, not just a > InternetOpen handle, so we should search up through the parents to > find it. Oops, I just checked on MSDN and this patch is wrong. We should copy and store the status callback in every handle, not just in the top level one. I'll submit a new patch soon. Rob

1 0

PEB documentation
by Mike Hearn 13 Sep '04

13 Sep '04

This is interesting information, but where did it come from? Is this structure described in some MS documentation? If so, does it have the full layout of the TEB as well? > Log message: > Robert Reif <reif(a)earthlink.net> > Document all the structure members up to SessionId in the PEB.

1 0

Re: winecfg (was Re: W->A calls)
by Mike Hearn 13 Sep '04

13 Sep '04

> It appears that Mike has been doing a lot of work on this. > http://www.winehq.org/hypermail/wine-devel/2004/09/0221.html > So you probably first want to coordinate with him. Yes. I'm aware that I'm holding people up right now due to my non-connectedness. I'm actually living in a bed&breakfast with no net connection, so I only have web/email access at work. It's kind of odd - I've been doing some work on it lately, and suddenly people pop up who want to work on it after a long period of inactivity. Oh well :) > I would start by running "winecfg", and seeing what doesn't work, which > is a lot. For example, on the very first tab, you can select a "Windows > Version", but changing the setting doesn't actually change anything (it > should make/alter a registry entry). The winecfg code is in > wine/programs/winecfg. Fixed by me already. Actually, I've done quite a bit of work on it, I'd recommend waiting for 2 weeks at which point I'll have net access to my laptop again and can hopefully send off my work. At that point I'll be disappearing back into university life and doing CW work again so the coast will be clear for others to work on it. > A long discussion of things that are needed is in the thread starting: > http://www.winehq.org/hypermail/wine-devel/2004/08/0007.html I've sorted some of these already, especially in the apps tab. So ... if you guys can wait for 2 weeks I should (hopefully) have something to show soon. thanks -mike

1 0

RFC: ntdll critical section debug
by Robert Reif 13 Sep '04

13 Sep '04

I have been running into deadlock problems in the direct sound dll and have been playing with the debug part of critical sections. I added a lock name to Spare[1] to give the critical sections names that will show up in the error messages just like wine's ntdll does. After looking at the ntdll code, it looks like this causes a leak because ntdll statically initializes it's locks and doesn't delete the debug part when it finds Spare[1] used. I also tried adding a linked list of critical section debug structs just like real windows does. Because ntdll statically initializes it's locks, they don't get added to the list. I manually stuff the critical section list lock into the list so it shows up and user locks show up but not the other internal ntdll locks. Is there a good reason to statically initialize ntdll locks or can they be initialized like normal locks? Here is a patch that adds the linked list of debug info: Index: dlls/ntdll/critsection.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/critsection.c,v retrieving revision 1.27 diff -u -r1.27 critsection.c --- dlls/ntdll/critsection.c 6 Sep 2004 20:26:23 -0000 1.27 +++ dlls/ntdll/critsection.c 10 Sep 2004 16:29:14 -0000 @@ -36,6 +36,51 @@ WINE_DEFAULT_DEBUG_CHANNEL(ntdll); WINE_DECLARE_DEBUG_CHANNEL(relay); +static LIST_ENTRY RtlCriticalSectionList; +static CRITICAL_SECTION RtlCriticalSectionLock; +static CRITICAL_SECTION_DEBUG RtlCriticalSectionDebug = +{ + 0, 0, &RtlCriticalSectionLock, + { &RtlCriticalSectionDebug.ProcessLocksList, + &RtlCriticalSectionDebug.ProcessLocksList }, + 0, 0, { 0, (DWORD)(__FILE__ ": RtlCriticalSectionLock") } +}; +static CRITICAL_SECTION RtlCriticalSectionLock = { &RtlCriticalSectionDebug, -1, 0, 0, 0, 0 }; + +void critsection_init() +{ + InitializeListHead( &RtlCriticalSectionList ); + InsertHeadList( &RtlCriticalSectionList, &RtlCriticalSectionDebug.ProcessLocksList ); +} + +static void CRIT_Dump() +{ + int i = 0; + PLIST_ENTRY mark, entry; + PCRITICAL_SECTION_DEBUG debug; + + RtlEnterCriticalSection( &RtlCriticalSectionLock ); + + mark = &RtlCriticalSectionList; + for (entry = mark->Flink; entry != mark; entry = entry->Flink) + { + debug = CONTAINING_RECORD(entry, CRITICAL_SECTION_DEBUG, ProcessLocksList); + + TRACE("RtlCriticalSectionDebug[%d]:\n", i++); + TRACE(" Type = %04x\n", debug->Type); + TRACE(" CreatorBackTraceIndex = %04x\n", debug->CreatorBackTraceIndex); + TRACE(" CriticalSection = %p\n", debug->CriticalSection); + TRACE(" ProcessLocksList.Flink = %p\n", debug->ProcessLocksList.Flink); + TRACE(" ProcessLocksList.Blink = %p\n", debug->ProcessLocksList.Blink); + TRACE(" EntryCount = %ld\n", debug->EntryCount); + TRACE(" ContentionCount = %ld\n", debug->ContentionCount); + TRACE(" Spare[0] = %08lx\n", debug->Spare[0]); + TRACE(" Spare[1] = %08lx (%s)\n", debug->Spare[1], debugstr_a((char *)debug->Spare[1])); + } + + RtlLeaveCriticalSection( &RtlCriticalSectionLock ); +} + inline static LONG interlocked_inc( PLONG dest ) { return interlocked_xchg_add( dest, 1 ) + 1; @@ -126,12 +171,16 @@ crit->DebugInfo->Type = 0; crit->DebugInfo->CreatorBackTraceIndex = 0; crit->DebugInfo->CriticalSection = crit; - crit->DebugInfo->ProcessLocksList.Blink = &(crit->DebugInfo->ProcessLocksList); - crit->DebugInfo->ProcessLocksList.Flink = &(crit->DebugInfo->ProcessLocksList); crit->DebugInfo->EntryCount = 0; crit->DebugInfo->ContentionCount = 0; crit->DebugInfo->Spare[0] = 0; crit->DebugInfo->Spare[1] = 0; + RtlEnterCriticalSection( &RtlCriticalSectionLock ); + InsertTailList( &RtlCriticalSectionList, &(crit->DebugInfo->ProcessLocksList) ); + RtlLeaveCriticalSection( &RtlCriticalSectionLock ); + + if (TRACE_ON(ntdll)) + CRIT_Dump(); } } crit->LockCount = -1; @@ -195,12 +244,19 @@ crit->LockSemaphore = 0; if (crit->DebugInfo) { + RtlEnterCriticalSection( &RtlCriticalSectionLock ); + RemoveEntryList( &(crit->DebugInfo->ProcessLocksList) ); + RtlLeaveCriticalSection( &RtlCriticalSectionLock ); + /* only free the ones we made in here */ if (!crit->DebugInfo->Spare[1]) { RtlFreeHeap( GetProcessHeap(), 0, crit->DebugInfo ); crit->DebugInfo = NULL; } + + if (TRACE_ON(ntdll)) + CRIT_Dump(); } return STATUS_SUCCESS; } Index: dlls/ntdll/ntdll_misc.h =================================================================== RCS file: /home/wine/wine/dlls/ntdll/ntdll_misc.h,v retrieving revision 1.48 diff -u -r1.48 ntdll_misc.h --- dlls/ntdll/ntdll_misc.h 15 Jul 2004 22:07:21 -0000 1.48 +++ dlls/ntdll/ntdll_misc.h 10 Sep 2004 16:29:14 -0000 @@ -50,6 +50,7 @@ extern void debug_init(void); extern void thread_init(void); extern void virtual_init(void); +extern void critsection_init(void); /* server support */ extern void server_init_process(void); Index: dlls/ntdll/thread.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/thread.c,v retrieving revision 1.21 diff -u -r1.21 thread.c --- dlls/ntdll/thread.c 23 Aug 2004 18:52:54 -0000 1.21 +++ dlls/ntdll/thread.c 10 Sep 2004 16:29:14 -0000 @@ -134,6 +134,7 @@ debug_info.str_pos = debug_info.strings; debug_info.out_pos = debug_info.output; + critsection_init(); debug_init(); virtual_init();

3 2

spying COM
by Saulius Krasuckas 13 Sep '04

13 Sep '04

Am not sure would it be of any use for list members, but just some minutes ago I've discovered "The COM spy". Quite old stuff, but whatever: http://staff.develop.com/jasonw/comspy/default.htm

2 1

epoll patch - status?
by Shachar Shemesh 12 Sep '04

12 Sep '04

Hi Alexandre, I'm sorry for being a pest about this. I was wondering whether there is anything that needs to be done on that one in order to facilitate committing this patch? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

5 14

Re: IShellFolder::CompareIDs partially undocumented take 2
by Vitaliy Margolen 12 Sep '04

12 Sep '04

Is there are any problems with this patch? Tests do confirm it. Vitaliy Margolen Saturday, September 4, 2004, 9:48:41 PM, Vitaliy Margolen wrote: > Since my previous patch wasn't excepted here it is again. This time with more fixes > and tests. > Also it _is_ documented that CompareIDs returns result in lower 16 bits. And this function > returns only -1/0/1 as a result. > Vitaliy Margolen > changelog: > dlls/shell32/shlfolder.c > IShellFolder::CompareIDs - return only -1/0/1 in lower 16 bit.

1 0

W->A calls
by Joris Huizer 11 Sep '04

11 Sep '04

Hello, By accident, I removed the emails of the thread I started, but I'll look it up if necessary; I found this old wine issue of some time ago.. I think the patch it has there could be helpfull http://winehq.org/?issue=229#About%20Converting%20W-%3EA%20Calls However, I don't know how to make simple tests.. as I'd really need to test wether the code I write works, and works properly :p How do I write tests for that? I'm running linux (in practice, I never boot into windows) so how should I do this (testing without windows environment)? How are tests supposed to run? I hope you can give some clues on that; I found there are many W->A calls in dlls/winmm/winmm.c (according to the janitorial page) so I might start there (hoping not all of them are so tricky ;) ) Thanks for suggestions on this, Joris

7 9

Re: Correct ConvertSidToStringSidW with test
by Dimitrie O. Paun 11 Sep '04

11 Sep '04

On Sat, Sep 11, 2004 at 08:37:09AM -0700, Juan Lang wrote: > ConvertSidToStringSidW was incorrect for low-value > authorities; it put spaces in the resulting string. > This corrects that, and includes a test case for it. Content-Description: advapi32.diff Uniffied diff, please :) -- Dimi.

1 0

Re: PROPSHEET: Wizard resizing
by Filip Navara 11 Sep '04

11 Sep '04

Filip Navara wrote: > I know this patch isn't really correct, but the old code isn't correct > either. Without it about 80% of the wizards were resized incorrectly > (or not at all) and the header line wasn't hidden sometimes. Even > though I would like to code the resizing correctly it will require > major code shuffling that I can't do now due to time constraints. So I > believe for now this patch is less evil than letting the code as is. > > (I can provide more details about how it should be implemented > correctly on request) > > - Filip > > Changelog: > First attempt at correcting wizard resizing. Scratch this patch please. I'll try to implement it correctly... Regards, Filip

1 0

Wine and non ANSI charset fonts
by Andreas Rosenberg 11 Sep '04

11 Sep '04

Hello guys, after a long pause I'm back testing our application (http://appdb.winehq.org/appview.php?appId=1536) with WINE. In the meantime I've been working to prepare our application for the east european/asian market (UTF16, wide char API). This seems to work so far, but as soon as you enter text requiring non ANSI glyphs, I'm only getting "square boxes" instead of the desired characters. So I was searching for another application that uses non ANSI glyhps with WINE. I choosed Opera, because it's quite easy to install. But unfortunately Opera 7.x crashed after entering the first URL. The function "WSAStringToAddress" and some other WSA funtions were missing/stubs. Yesterday evening I fixed these problems and just sent a patch making Opera work with Wine. With Opera I'm now getting the same or similar effects. just try the Opera in Wine and go to: http://www.viatech.com.tw/big5/index/index.jsp So my question: is this a configuration problem? Konquerer displays the page correctly, so the fonts on the Linux side have the correct glyphs available. But it seems they are not available in WINE - I looked into the WINE config file and found something like this: ;;default TrueType fonts with russian koi8-r encoding "Default" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r" "DefaultFixed" = "-monotype-courier new-*-*-*--*-*-*-*-*-*-koi8-r" "DefaultSerif" = "-monotype-times new roman-*-*-*--*-*-*-*-*-*-koi8-r" "DefaultSansSerif" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r" This seems to define something regarding the cyrilic charset. With these lines enabled, Opera can display russian pages correctly. But what do I need to enter to get the glyphs of other character sets? (chinese, hangul, etc...) I read the Wine users guide regarding fonts, but it still does not address the character set topic.Can anybody shed some light on this? Regards Andy

2 1

Re: Implementation of WSAStringToAddress(A/W), WSAHtonl, WSAHtons
by Alexandre Julliard 10 Sep '04

10 Sep '04

Andreas Rosenberg <andreas_rosenberg(a)web.de> writes: > +INT WINAPI WSAStringToAddressW(LPCWSTR AddressString, > + INT AddressFamily, > + LPWSAPROTOCOL_INFOA lpProtocolInfo, You should have an LPWSAPROTOCOL_INFOW here instead, and convert it before calling WSAStringToAddressA. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Almost complete UpdateResource implementation
by Alexandre Julliard 10 Sep '04

10 Sep '04

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > + if(!updates_list) > + { > + updates_list = current_updates; > + list_init(&updates_list->entry); > + } > + else > + list_add_after(&updates_list->entry, &current_updates->entry); That's not the right way to use the list functions. updates_list should be a separate struct list, that will make things a lot easier. > + LIST_FOR_EACH(ptr, &current_updates->resources_list->entry) > + { > + current_resource = LIST_ENTRY(ptr, QUEUEDRESOURCE, entry); > + free_queuedresource(current_resource); > + } You cannot free objects that are still on list, you have to remove them first. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: CreateDirectoryA conformance test improvement
by Alexandre Julliard 10 Sep '04

10 Sep '04

Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> writes: > This patch provides a conformance test for my patch > sent on 06. Sept 2004. > > I have successfully tested it on Windows98 and WindowsNT4. Actually the results of that test depend on what the current directory is on the drive you are testing. If your current directory is \ you will see that it fails on Windows too. I believe the Wine code is correct, it returns ACCESS_DENIED on the root and ALREADY_EXISTS anywhere else, just like Windows. -- Alexandre Julliard julliard(a)winehq.org

1 0

COmpilation problems with older Freetype 2
by Vincent Béron 10 Sep '04

10 Sep '04

A patch by Huw broke compilation of Wine on RH8 (and probably other platforms as well) which use Freetype 2.1.3 or earlier. More specifically, FT_ENCODING_NONE is undefined. Other ft_encoding_* (or FT_ENCODING_*) problems have arised in the past, but the solution used identifiers already present in older Freetype versions. The attached patch works (and results in the same compiled code IMHO), but looks like a hack rather than a proper fix (use MS_MAKE_TAG? that has already been removed in the past to use ft_encoding_*). Vincent

1 0

Re: Fix twain device handle corruption
by Alexandre Julliard 10 Sep '04

10 Sep '04

Francois Gouget <fgouget(a)codeweavers.com> writes: > * or we could check that config.h has been included first using > something like: > > #ifndef __WINE_CONFIG_H > # error You must include config.h first > #endif I think that's preferable, we really want to be using the same structure everywhere. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [SHLWAPI] Implemented PathSearchAndQualify (another fix)
by Vincent Béron 10 Sep '04

10 Sep '04

Le ven 10/09/2004 à 13:22, Diego 'Flameeyes' Pettenò a écrit : > I have fixed the patch for the problems Rolf Kalbermatter pointed out. Hope > this time is the good one :) Not likely if the patch is not attached... ;) Vincent

2 1

Re: winedos:MCB implementation
by Andreas Mohr 10 Sep '04

10 Sep '04

Hi, On Fri, Sep 10, 2004 at 06:09:26PM +0200, Markus Amsler wrote: > That's some of the result of my effort getting FreeCOM running in winedos. > It's quite important to winedos having proper MCB support, a lot of apps > depend on it. Indeed! Great, thanks a lot for this very important work!! > It also enables running/terminating apps within dos shells, and opens > the door to TSR. > With some more patches (IO-redirection, TSR comming soon) i'm able to > run FreeCOM, compile FreeCOM within FreeCOM, run XRAY and getting my TSR > app starting. Cool. > Please let me know, if there's something wrong with the patch (design > problems, naming conventions, formating, ...). Looks nice and clean to me on cursory glance. Andreas Mohr

1 0

Re: dinput axis mapping and format mapping patch
by Alexandre Julliard 10 Sep '04

10 Sep '04

Robert Reif <reif(a)earthlink.net> writes: > Add a [dinput] section to your config file and provide a line with the > following information: > > "your device name" = "X,Y,Z,Rx,Ry,Rz,Slider1,Slider2,POV1,POV2,POV3,POV4" > > where "your device name" is what you get from /bin/jstest and > the axes list are the axes supported by your joystick. > > For example, here is part of my config file: > > [dinput] > "Logitech Logitech Extreme 3D Pro" = "X,Y,Rz,Slider1,POV1" You should add this in the registry instead of the config file, this way we won't have to move it later on. HKLM/Software/Wine/Dinput should be a good place for it. -- Alexandre Julliard julliard(a)winehq.org

3 6

Fwd: Cron <paulm@quisquiliae> $HOME/Production/cronCrossBuild 10:00
by Paul Millar 10 Sep '04

10 Sep '04

Hi everyone, A couple of quick things: First, I'm off on holiday for a week (starting tomorrow :^) so won't be able to answer emails for a bit. The cross-building should carry on regardless, though. Second, very occasionally get messages like: ---------- Forwarded Message ---------- Subject: Cron <paulm@quisquiliae> $HOME/Production/cronCrossBuild 10:00 Date: Friday 10 September 2004 11:18 From: root of quisquiliae <p.millar(a)physics.gla.ac.uk> To: p.millar(a)physics.gla.ac.uk cvs checkout: warning: unrecognized response `cvs: buffer.c:1384: stdio_buffer_shutdown: Assertion `fstat ( fileno (bc->fp), &s ) != -1 failed.' from cvs server cvs [checkout aborted]: end of file from server (consult above messages if any) ------------------------------------------------------- which looks like WineHQ's cvs server sulking. Does any else get these? Cheers, Paul.

1 0

Linking with winelib
by Nikolay A. Liber 10 Sep '04

10 Sep '04

Hello I am using winelib with Mono hack to load windows DLL into python module. There is a dummy function wine_pthread_init_thread in libwine.so. wine_pthread_init_thread implemented in winelib.so.exe from mono shared winelib. I link module. gcc -shared mymodule.so module_code.o -lwine ./winelib.so.exe But when I load module init_thread from ntdll calls dummy wine_pthread_init_thread. How to override that dumy function? Thank you Nikolay

2 1

RE: modal dialog: Wait until message queue runs dry before calling ShowWindow()
by Zach Gorman 09 Sep '04

09 Sep '04

Yes, the test code is on its way. These patches are all from a few weeks ago, but Alexandre asked me to break them up into multiple smaller patches. I tested them with the latest tree and they seem to still work fine. Zach -----Original Message----- From: Mike McCormack [mailto:mike@codeweavers.com] Sent: Thursday, September 09, 2004 2:37 PM To: zach(a)archetypeauction.com Subject: Re: modal dialog: Wait until message queue runs dry before calling ShowWindow() Zach Gorman wrote: > My tests show that Windows behaves this way. If you could submit your test as a patch including it in the wine test suite, that would be great. If not, just posting it with a LGPL compatible license so others can adapt it to the test suite would be appreciated too. Mike

1 0

Re: edit control
by Robert Shearman 09 Sep '04

09 Sep '04

Ulrich Czekalla wrote: >ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > Allow copying selection when control is read only > > >------------------------------------------------------------------------ > >Index: dlls/user/edit.c >=================================================================== >RCS file: /home/wine/wine/dlls/user/edit.c,v >retrieving revision 1.1 >diff -u -r1.1 edit.c >--- dlls/user/edit.c 31 Aug 2004 01:10:08 -0000 1.1 >+++ dlls/user/edit.c 9 Sep 2004 13:01:26 -0000 >@@ -3604,7 +3604,8 @@ > > /* Protect read-only edit control from modification */ > if(es->style & ES_READONLY) >- return; >+ if (c != 0x03) /* Allow copying selection */ >+ return; > > control = GetKeyState(VK_CONTROL) & 0x8000; > > That read-only check looks completely bogus to me as the code below already checks for ES_READONLY. Rob

2 1

Settlers 3: bug in NTDLL_get_server_timeout??
by Stefan Dösinger 09 Sep '04

09 Sep '04

Hello list, I am trying to get Settlers 3(Siedler 3) working. This game crashes with a Integer divide by 0 exception very early. Wine version: cvs from September 7. 2004 Settlers 3 version: 1.60 with WinXp-patch. s3.exe produces a nice crash dump(attached errorlog.txt) and with a little debugging I found out that the crash occurs in RtlEnlargedUnsignedDivide(), file dlls/ntdll/large_int.c This is what I think is going on: *)s3.exe calls SetWaitableTimer() in dlls/kernel/sync.c *)NtSetTimer() in dlls/ntdll/sync.c is called, and this is where the problem beginns. NtSetTimer() calls NTDLL_get_server_timeout from time.c *)The 2nd case occurs(the else if) and RtlEnlargedUnsignedDivide is called. The interesting thing is that TICKSPERSEC is a constant(10000000) and this shouldn't give a divide by zero. But RtlEnlargedUnsignedDivide takes an UINT as 2nd arguemt, and 10000000 is too big for an UINT. For testing I enabled the C version of RtlEnlargedUnsignedDivide, and this time the exception didn't occur but wineserver blocked(kill -9 was necessary) The same thing happens if I move the divison to NTDLL_get_server_timeout(and do not call RtlEnlargedUnsignedDivide). I commented the call to NTDLL_get_server_timeout, and s3.exe starts successfully, but I don't think that's the correct way to solve this problem. I attached the output with normal debug options and a few TRACEs changed to ERRs. NTDLL_get_server_timeout is called quite often. The SetWaitableTimer call: err:ntdll:SetWaitableTimer called err:ntdll:NtSetTimer (0xf4,0x46d32104,(nil),(nil),00000000,0x000001f4,(nil)) stub err:ntdll:NTDLL_get_server_timeout called err:ntdll:NTDLL_get_server_timeout called err:ntdll:NTDLL_get_server_timeout called ... fixme:dialog:MSGBOX_OnInit system modal msgbox ! Not modal yet. -- The crash message err:ntdll:NTDLL_get_server_timeout called err:ntdll:NTDLL_get_server_timeout called Greetings, Stefan Dösinger

4 5

RE: Battlefield 1942 d3d8 crash
by Ann and Jason Edmeades 09 Sep '04

09 Sep '04

Hiya, Just an fyi - I installed it and gave it a try. The first problem (the one you mentioned) is easily solved by commenting out the hide and show calls around the setwindowpos. This may be the real fix - The problem is the app has a default window proc which is receiving a window activated message on the show, and assumes it had lost full screen and got it back. It then tries to reset everything but it never completed initialization! Anyway it then goes on to die on something I think is sound related, but might be my machines problem (sound on my test box is seriously screwed up). Note the game writes into a sub dir 'Logs' (from memory) a log of how far it gets. Try taking those 2 lines out and see if you get any further. I'll have another go at the 2nd trap I am seeing, but it would be interesting to see if you get any further. Jason

1 0

UltimaOnLine: X11DRV_CritSection deadlock
by Diego 'Flameeyes' Pettenò 09 Sep '04

09 Sep '04

Hi, I'm playing Ultima OnLine using wine in the last times, it works fine, except that wine processes eat all the cpu time and sometimes I have this fixme on stderr: fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIBcopy But the true problem is that if I'm idle for some time, I get this error, and kde stops responding at mouse (and sometimes also keyboard) events: err:ntdll:RtlpWaitForCriticalSection section 0x41bd6220 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0009, blocked by 000a, retrying (60 sec) Seems like a deadlock, but I don't know what can generate this problem, so I can't reproduce it after launching winedbg. Also when I close the client, wine remains open until I ctrl-c it. Trying to tracing this is quite impossible, because it's already heavy when launched directly, I don't think it's possible to have a +all with it without using the delayed debug, but I'm not able to find out the patch into wine-patches, if someone can point a link for it, I'll try to do that. If no one has idea of what problem is this, I'll report it as a bug, but maybe it's only an application's problem. TIA, -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/

5 7

Re: Drowning in FIXMEs...
by Jukka Heinonen 09 Sep '04

09 Sep '04

Chris Rankin: > OK, here's a first draft at a patch. Created with > reference to my old copies of Ralph Brown's Interrupt > List. Well, under DOS VGA text mode, mouse cursor is like "gpm" mouse cursor, a character cell which gets inverted or otherwise highlighted in order to show where mouse is currently located at. As far as I know, neither Wine nor Windows supports this and SetConsoleCursorInfo really has no effect on mouse cursor, anyway. So, under text mode, hide/show functions should do nothing. However, under VGA graphics mode, show/hide cursor really should call ShowCursor. And, if mouse driver is reset, hide count must be reset to one and cursor must be hidden. I have some more or less untested patch for show/hide somewhere but the last time I tried to get that working I had to fix IRQ handling, again, and after that I was too bored and too busy for doing DOS stuff. Anyway, it will take probably about half a week until I have time for digging out the patch, which I will do if this thing is not fixed before that. I guess I should also dig my other DOS related patches and submit them as well, I don't know if they really help much but at least I would not have pending stuff in my computer. -- Jukka Heinonen <http://www.iki.fi/jhei>

4 3

Re: Re: test.winehq.org site
by Chris Morgan 09 Sep '04

09 Sep '04

>From what I can tell on my xp machine it looks like winrash is running correctly, no errors downloading the winetest are reported. Maybe winetest is failing prematurely or the reporting of the results isn't occuring correctly? Chris > > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Date: 2004/09/08 Wed PM 12:06:04 EDT > To: Saulius Krasuckas <saulius2(a)ar.fi.lt> > CC: wine-devel(a)winehq.org > Subject: Re: test.winehq.org site > > On Wed, Sep 08, 2004 at 06:32:31PM +0200, Saulius Krasuckas wrote: > > When can we expect it to be up and running? > > It is up and running, we're just missing an index page. > Until that gets created, use this link instead: > > http://test.winehq.org/data/ > > Unfortunately, the testing process has been broken lately, > for unknown reasons. > > -- > Dimi. > >

3 2

The solution for the Delphi menu bug
by Michael Kaufmann 09 Sep '04

09 Sep '04

Hi all, I found a different approach to make the menus of Delphi applications work in WINE. I was working on a different bug (allow a single menu to be used in multiple windows), and found that my fix for this problem also fixes the Delphi menu bug. So we don't have to break a testcase! The fix is as simple as updating the menu bar's hWnd member every time the user clicks on a menu bar. This is even necessary if the menu is displayed in multiple windows, so it's not a "Delphi-only" fix. Thank you for the intensive discussion we had on the subject! My patch is here: http://www.winehq.org/hypermail/wine-patches/2004/09/0154.html Regards Michael

1 0

DirectInput suggestion
by Jonathan Wilson 08 Sep '04

08 Sep '04

I dont know how this stuff works on linux so my suggestion may be wrong but here goes. Basicly, my suggestion is that any joystick that is visible to linux apps be made visible to windows apps via DirectInput joystick APIs. This eliminates the need for WINE to care about USB and such.

2 1

Problem with change of DIDEVICEOBJECTDATA
by Stefan Dösinger 08 Sep '04

08 Sep '04

Hello, I have a problem with the change of struct DIDEVICEOBJECTDATA in CVS: DIDEVICEOBJECTDATA now has size 20, but Settler 3 still calls SysMouseAImpl_GetDeviceData with dodsize=16 and complains about the returned error. Stefan Dösinger

3 2

RE: [SHLWAPI] Implemented PathSearchAndQualify (fix)
by Rolf Kalbermatter 08 Sep '04

08 Sep '04

A few comments: /************************************************************************* @@ -3126,8 +3146,87 @@ */ BOOL WINAPI PathSearchAndQualifyW(LPCWSTR lpszPath, LPWSTR lpszBuf, UINT cchBuf) { - FIXME("(%s,%p,0x%08x)-stub\n", debugstr_w(lpszPath), lpszBuf, cchBuf); - return FALSE; + LPWSTR pathCopy; + LPWSTR bufPos = lpszBuf; + LPWSTR bufPos2 = bufPos; + BOOL ret = TRUE; + + if ( !(pathCopy = HeapAlloc(GetProcessHeap(), 0, cchBuf * sizeof(WCHAR)))) + return FALSE; + StrCpyW(pathCopy, lpszPath); + lpszPath = pathCopy; This is rather ugly. You shouldn't overwrite the pointer to the passed in buffer. Use for internal pointer reference handling one of the local variables instead of overwriting a parameter variable. + TRACE("(%s %p %d)\n", debugstr_w(lpszPath), lpszBuf, cchBuf); + + if (!lpszPath || !*lpszPath) + return FALSE; I think this is bad order! The trace should be on entry and definitely before you modify any passed in parameters. The same applies for the valid input parameter check. + if (*pathCopy == '\\' && pathCopy[1] == '\\') + { + /* Network share: skip share server and mount point */ + pathCopy += 2; + if ((pathCopy = StrChrW(pathCopy, '\\')) && + (pathCopy = StrChrW(pathCopy + 1, '\\'))) + pathCopy++; + } + + /* Check x:\ */ + if (pathCopy[0] && pathCopy[1] == ':' && pathCopy[2] == '\\') + pathCopy += 3; + + if ( pathCopy != lpszPath ) + { + StrCpyNW(bufPos, lpszPath, (pathCopy - lpszPath) +1); + bufPos += (pathCopy - lpszPath); + bufPos2 = bufPos; + *bufPos = '\0'; + lpszPath = pathCopy; + } else { + FIXME("must prepend current path"); + } + + while(*pathCopy) + { + if ( *pathCopy == '.' ) + { + if ( ! pathCopy[1] ) + { + ret = TRUE; + break; + } + + if ( pathCopy[1] == '\\' ) { pathCopy += 2; continue; } + + if ( pathCopy[1] == '.' && pathCopy[2] == '\\' ) + { + if ( bufPos == bufPos2 ) + { + pathCopy += 3; + continue; + } + + bufPos = StrRChrW(bufPos, bufPos2, '\\'); + *bufPos = '\0'; + continue; + } + } + + if ( StrChrW(pathCopy, '\\') ) + { + size_t len = (StrChrW(pathCopy, '\\') - pathCopy )+1; + StrCpyNW(bufPos, pathCopy, len+1); + bufPos += len; + pathCopy += len; + *bufPos = '\0'; + continue; + } else { + StrCpyW(bufPos, pathCopy); + break; + } + } + + HeapFree(GetProcessHeap(), 0, pathCopy); + return ret; } I don't see how pathCopy can be the original pointer here after having made so much of pointer increments on that variable inside the function. This would mean that HeapFree will completely fail or probably just crash. Rolf Kalbermatter

1 0

Revised menu patch
by Michael Kaufmann 08 Sep '04

08 Sep '04

Hi all My last menu patch didn't pass a test case. I've commented out this test case, because it tests undocumented behavior. We should re-activate this testcase as soon as WINE passes it. This will be the case when the menu code is moved to WineServer, as Dmitry pointed out. I've also added more bugfixes to the patch: Now WINE supports the (very rare) case where a menu is assigned to multiple windows. To test this, I'll attach a program which displays two windows using the same menu. The windows are from different window classes in order to test if WINE sends the ownerdraw messages to the correct window. Please test this patch and tell me if I should send it to wine-patches. Regards Michael Index: dlls/user/menu.c =================================================================== RCS file: /home/wine/wine/dlls/user/menu.c,v retrieving revision 1.1 diff -u -r1.1 menu.c --- dlls/user/menu.c 31 Aug 2004 01:10:08 -0000 1.1 +++ dlls/user/menu.c 7 Sep 2004 21:17:43 -0000 @@ -83,15 +83,14 @@ HWND hWnd; /* Window containing the menu */ MENUITEM *items; /* Array of menu items */ UINT FocusedItem; /* Currently focused item */ - HWND hwndOwner; /* window receiving the messages for ownerdraw */ BOOL bTimeToHide; /* Request hiding when receiving a second click in the top-level menu item */ /* ------------ MENUINFO members ------ */ - DWORD dwStyle; /* Extended mennu style */ - UINT cyMax; /* max hight of the whole menu, 0 is screen hight */ - HBRUSH hbrBack; /* brush for menu background */ + DWORD dwStyle; /* Extended menu style */ + UINT cyMax; /* Max height of the whole menu, 0 is screen height */ + HBRUSH hbrBack; /* Brush for menu background */ DWORD dwContextHelpID; - DWORD dwMenuData; /* application defined value */ - HMENU hSysMenuOwner; /* Handle to the dummy sys menu holder */ + DWORD dwMenuData; /* Application-defined value */ + HMENU hSysMenuOwner; /* Handle to the dummy system menu holder */ } POPUPMENU, *LPPOPUPMENU; /* internal flags for menu tracking */ @@ -171,6 +170,10 @@ * be tracked at the same time. */ static HWND top_popup; +/* Use a global owner window while tracking the menu. + * This window receives ownerdraw messages. */ +static HWND owner_window; + /* Flag set by EndMenu() to force an exit from menu tracking */ static BOOL fEndMenu = FALSE; @@ -181,6 +184,7 @@ /********************************************************************* * menu class descriptor */ + const struct builtin_class_descr MENU_builtin_class = { POPUPMENU_CLASS_ATOMA, /* name */ @@ -1405,8 +1409,9 @@ UINT u; for (u = menu->nItems, item = menu->items; u > 0; u--, item++) - MENU_DrawMenuItem( hwnd, hmenu, menu->hwndOwner, hdc, item, - menu->Height, FALSE, ODA_DRAWENTIRE ); + + MENU_DrawMenuItem( hwnd, hmenu, owner_window, hdc, item, + menu->Height, FALSE, ODA_DRAWENTIRE ); } } else @@ -1473,10 +1478,6 @@ menu->FocusedItem = NO_SELECTED_ITEM; } - /* store the owner for DrawItem */ - menu->hwndOwner = hwndOwner; - - MENU_PopupMenuCalcSize( menu, hwndOwner ); /* adjust popup menu pos so that it fits within the desktop */ @@ -2837,7 +2838,11 @@ */ static BOOL MENU_InitTracking(HWND hWnd, HMENU hMenu, BOOL bPopup, UINT wFlags) { + POPUPMENU* menu; + TRACE("hwnd=%p hmenu=%p\n", hWnd, hMenu); + + if (!(menu = MENU_GetMenu( hMenu ))) return FALSE; HideCaret(0); @@ -2849,9 +2854,8 @@ if (!(wFlags & TPM_NONOTIFY)) { - POPUPMENU *menu; SendMessageW( hWnd, WM_INITMENU, (WPARAM)hMenu, 0 ); - if ((menu = MENU_GetMenu( hMenu )) && (!menu->Height)) + if (!menu->Height) { /* app changed/recreated menu bar entries in WM_INITMENU Recalculate menu sizes else clicks will not work */ SetWindowPos( hWnd, 0, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | @@ -2859,6 +2863,13 @@ } } + + /* Multiple windows can use the same menu. + * The menu needs to know its owner window for the + * current tracking operation. */ + owner_window = hWnd; /* for DrawItem */ + menu->hWnd = hWnd; /* for MENU_TrackMenu and many other functions */ + return TRUE; } /*********************************************************************** @@ -2970,6 +2981,8 @@ { BOOL ret = FALSE; + if (!IsMenu( hMenu )) return FALSE; + MENU_InitTracking(hWnd, hMenu, TRUE, wFlags); /* Send WM_INITMENUPOPUP message only if TPM_NONOTIFY flag is not specified */ @@ -3554,6 +3567,36 @@ DestroyWindow( lppop->hWnd ); lppop->hWnd = 0; } + + /* Check if the menu is still in use by a window + * (fix for bug 1486) + * + * FIXME: - A menu used by multiple windows is not removed + * from all windows, but only from the window that + * used the menu most recently + * - Update or remove this code if you move the menu + * code to WineServer + */ + if (lppop->hWnd && IsWindow(lppop->hWnd) && + GetMenu(lppop->hWnd) == hMenu) + { + /* Handle this situation in the same way as Windows 9x. + + Windows 9x destroys the menu and sets the window's + menu handle to NULL, without repainting the menu bar. + The application has to call SetMenu or DrawMenuBar + afterwards. + + FIXME: Windows 2000 returns TRUE, but doesn't destroy + the menu immediately. It waits until the menu + is not used anymore. */ + + WARN("The menu %p is still in use by window %p\n", + hMenu, lppop->hWnd); + + MENU_SetMenu(lppop->hWnd, NULL); + lppop->hWnd = 0; + } if (lppop->items) /* recursively destroy submenus */ { @@ -3728,7 +3771,6 @@ if (!hMenu || !(lppop = MENU_GetMenu( hMenu ))) return FALSE; lppop->Height = 0; /* Make sure we call MENU_MenuBarCalcSize */ - lppop->hwndOwner = hWnd; SetWindowPos( hWnd, 0, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | SWP_NOACTIVATE | SWP_NOZORDER | SWP_FRAMECHANGED ); return TRUE; Index: dlls/user/tests/win.c =================================================================== RCS file: /home/wine/wine/dlls/user/tests/win.c,v retrieving revision 1.33 diff -u -r1.33 win.c --- dlls/user/tests/win.c 26 Aug 2004 18:33:40 -0000 1.33 +++ dlls/user/tests/win.c 7 Sep 2004 21:17:45 -0000 @@ -1606,7 +1606,7 @@ { HWND child; HMENU hMenu, ret; - BOOL is_win9x = GetWindowLongW(parent, GWL_WNDPROC) == 0; + /* BOOL is_win9x = GetWindowLongW(parent, GWL_WNDPROC) == 0; */ hMenu = CreateMenu(); assert(hMenu); @@ -1619,9 +1619,12 @@ ok(DestroyMenu(hMenu), "DestroyMenu error %ld\n", GetLastError()); ok(!IsMenu(hMenu), "menu handle should be not valid after DestroyMenu\n"); ret = GetMenu(parent); - /* This test fails on Win9x */ - if (!is_win9x) - ok(ret == hMenu, "unexpected menu id %p\n", ret); + + /* FIXME: This test fails on Win9x and WINE + WINE will pass this test after the menu + code has been moved to WineServer */ + /* if (!is_win9x) + ok(ret == hMenu, "unexpected menu id %p\n", ret); */ ok(SetMenu(parent, 0), "SetMenu(0) on a top level window should not fail\n"); test_nonclient_area(parent); #include <windows.h> LRESULT CALLBACK WndProc1 (HWND, UINT, WPARAM, LPARAM); LRESULT CALLBACK WndProc2 (HWND, UINT, WPARAM, LPARAM); char szAppName1[] = "MenuDemo1"; char szAppName2[] = "MenuDemo2"; #define MENU_FILE 0 #define MENU_QUIT 1 char* MenuStrings[] = {"File", "Quit"}; int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) { HWND hwnd1; HWND hwnd2; MSG msg; WNDCLASSEX wndclass; HMENU hMenu; HMENU hMenuPopup; // Window 1 with WndProc1 wndclass.cbSize = sizeof (wndclass); wndclass.style = CS_HREDRAW | CS_VREDRAW; wndclass.lpfnWndProc = WndProc1; wndclass.cbClsExtra = 0; wndclass.cbWndExtra = 0; wndclass.hInstance = hInstance; wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION); wndclass.hCursor = LoadCursor(NULL, IDC_ARROW); wndclass.hbrBackground = (HBRUSH) GetStockObject (WHITE_BRUSH); wndclass.lpszMenuName = 0; wndclass.lpszClassName = szAppName1; wndclass.hIconSm = LoadIcon(NULL, IDI_APPLICATION); RegisterClassEx (&wndclass); // Window 2 with WndProc2 wndclass.lpfnWndProc = WndProc2; wndclass.lpszClassName = szAppName2; RegisterClassEx (&wndclass); hMenu = CreateMenu(); hMenuPopup = CreateMenu(); AppendMenu(hMenuPopup, MF_STRING | MF_OWNERDRAW, 1, (char*) MENU_QUIT); AppendMenu(hMenu, MF_POPUP | MF_OWNERDRAW, (UINT)hMenuPopup, (char*) MENU_FILE); hwnd1 = CreateWindow (szAppName1, "Red Ownerdraw Menu", WS_OVERLAPPEDWINDOW, 50, 50, 300, 150, NULL, NULL, hInstance, NULL); SetMenu(hwnd1, hMenu); ShowWindow (hwnd1, iCmdShow); UpdateWindow (hwnd1); hwnd2 = CreateWindow (szAppName2, "Green Ownerdraw Menu", WS_OVERLAPPEDWINDOW, 350, 50, 300, 150, NULL, NULL, hInstance, NULL); SetMenu(hwnd2, hMenu); ShowWindow (hwnd2, iCmdShow); UpdateWindow (hwnd2); while (GetMessage (&msg, NULL, 0, 0)) { TranslateMessage (&msg); DispatchMessage (&msg); } return msg.wParam; } LRESULT CALLBACK WndProc1 (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam) { MEASUREITEMSTRUCT* m; DRAWITEMSTRUCT* d; HBRUSH brush; int savedDC; switch (iMsg) { case WM_COMMAND: switch (LOWORD (wParam)) { case 1: SendMessage (hwnd, WM_CLOSE, 0, 0L); return 0; } break; case WM_DESTROY: PostQuitMessage (0); return 0; case WM_MEASUREITEM: m = (MEASUREITEMSTRUCT*)lParam; m->itemWidth = 50; m->itemHeight = 20; return TRUE; case WM_DRAWITEM: d = (DRAWITEMSTRUCT*)lParam; savedDC = SaveDC(d->hDC); brush = CreateSolidBrush(RGB(255, 0, 0)); SelectObject(d->hDC, brush); FillRect(d->hDC, &(d->rcItem), brush); SetBkMode(d->hDC, TRANSPARENT); DrawText(d->hDC, MenuStrings[d->itemData], -1, &(d->rcItem), DT_CENTER | DT_SINGLELINE | DT_VCENTER); RestoreDC(d->hDC, savedDC); DeleteObject(brush); } return DefWindowProc (hwnd, iMsg, wParam, lParam); } // Only the brush color differs from WndProc1 LRESULT CALLBACK WndProc2 (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam) { MEASUREITEMSTRUCT* m; DRAWITEMSTRUCT* d; HBRUSH brush; int savedDC; switch (iMsg) { case WM_COMMAND: switch (LOWORD (wParam)) { case 1: SendMessage (hwnd, WM_CLOSE, 0, 0L); return 0; } break; case WM_DESTROY: PostQuitMessage (0); return 0; case WM_MEASUREITEM: m = (MEASUREITEMSTRUCT*)lParam; m->itemWidth = 50; m->itemHeight = 20; return TRUE; case WM_DRAWITEM: d = (DRAWITEMSTRUCT*)lParam; savedDC = SaveDC(d->hDC); brush = CreateSolidBrush(RGB(0, 255, 0)); SelectObject(d->hDC, brush); FillRect(d->hDC, &(d->rcItem), brush); SetBkMode(d->hDC, TRANSPARENT); DrawText(d->hDC, MenuStrings[d->itemData], -1, &(d->rcItem), DT_CENTER | DT_SINGLELINE | DT_VCENTER); RestoreDC(d->hDC, savedDC); DeleteObject(brush); } return DefWindowProc (hwnd, iMsg, wParam, lParam); }

7 11

Re: PATCH: use standard offsetof()
by Alexandre Julliard 08 Sep '04

08 Sep '04

Marcus Meissner <marcus(a)jet.franken.de> writes: > gcc 3.5 no longer likes our own OFFSETOF() macro in winebuild, so we should > use the standard one from <stddef.h> Not all platforms have offsetof (or even stddef.h). What's wrong with our definition? -- Alexandre Julliard julliard(a)winehq.org

3 3

rejected patch? libw32sys.so linked to win32s/libw32skrnl.so
by Peter Petrakis 08 Sep '04

08 Sep '04

Hello All, Citing this email from way back in 2000. http://www.mail-archive.com/wine-devel%40winehq.com/msg00914.html Talks about a crash when capture.exe is run from the orcad suite. I'm using orcad lite 9.2 (student edition), I can get everything to work except capture. I've upgraded to the latest rpm availble for suse 9.1 (wine-20040716-0.1, x86) but the problem remains. I tried some troubleshooting which included getting the actual w32sys dll and issuing an override, which seems to be ignored. I also destroyed the symlink that aliased aforementioned library to libw32skml. It still crashes. For whatever reason it is not honoring the override. The relevant config section is the following: [DllOverrides] ; some dlls you may want to change "oleaut32" = "builtin, native" "ole32" = "builtin, native" "comdlg32" = "builtin, native" "shell32" = "builtin, native" "shfolder" = "builtin, native" "shlwapi" = "builtin, native" "shdocvw" = "builtin, native" "advapi32" = "builtin, native" "w32sys" = "native, builtin" "w32skrnl" = "native, builtin" "msvcrt" = "native, builtin" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" "msi" = "native, builtin" "d3drm" = "native, builtin" "d3dxof" = "native, builtin" "dpnhpast" = "native, builtin" ; you can specify applications too ; this one will apply for all notepad.exe ;"*notepad.exe" = "native, builtin" ; this one will apply only for a particular file ;"C:\\windows\\regedit.exe" = "native, builtin" ; default for all other dlls "*" = "builtin, native" [AppDefaults\\capture.exe\\DllOverrides] "w32sys" = "native" Some debugging info, petrakis@prin-92:~/.wine/fake_windows/Program Files/OrcadLite/Capture> export WINEDEBUG=+dll petrakis@prin-92:~/.wine/fake_windows/Program Files/OrcadLite/Capture> wine capture.exe trace:dll:fill_init_list (krnl386.exe) - START trace:dll:fill_init_list (krnl386.exe) - END trace:dll:fill_init_list (system.drv) - START trace:dll:fill_init_list (system.drv) - END trace:dll:fill_init_list (gdi.exe) - START trace:dll:fill_init_list (gdi.exe) - END trace:dll:fill_init_list (user.exe) - START trace:dll:fill_init_list (user.exe) - END trace:dll:fill_init_list (keyboard.drv) - START trace:dll:fill_init_list (keyboard.drv) - END trace:dll:fill_init_list (mmsystem.dll) - START trace:dll:fill_init_list (mmsystem.dll) - END trace:dll:NE_CallDllEntryPoint Calling mmsystem.dll DllEntryPoint, cs:ip=1187:0ac1 err:module:load_builtin_dll loaded .so for L"W32SYS.DLL" but got L"w32skrnl.dll" instead - probably 16-bit dll fixme:ole:CoRegisterMessageFilter stub wine: Unhandled exception (thread 0021), starting debugger... trace:dll:fill_init_list (krnl386.exe) - START trace:dll:fill_init_list (krnl386.exe) - END trace:dll:fill_init_list (system.drv) - START trace:dll:fill_init_list (system.drv) - END Usage: winedbg [--auto] [--gdb] cmdline I'm very curious that the patch mentioned or something like it never made it into the source tree. I will integrate it myself the weekend (or as soon as friday) and see for myself. If this patch can work, I could switch ALOT of EE and CSE students over to Linux. Is there a work around that does not require a rebuild? Thanks in advance. Peter

2 1

Re: Acknowledgement page
by Brian Vincent 08 Sep '04

08 Sep '04

On Sun, 5 Sep 2004 00:34:48 +0200, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > Hmm, just found that some other major developers are missing: > Aric Stewart (or is that "Codeweavers"?), Marcus Meissner, > Eric Poeuch (and that was 3 out of 5 author tries that I did). Should have explained that bit.. anyone listed on the Who's Who page doesn't show up here. This list will fall right under that on the introduction page.. but perhaps I need to add a reference back to the Who's Who page. -Brian

2 1

Simple bugzilla question
by Ann and Jason Edmeades 08 Sep '04

08 Sep '04

Hiya, I've just set up a temporary Linux system to try to get back into doing some wine development following a break and thought I'd start by looking at some bugzilla bugs for now. I'm sure there used to be a page which showed the lifespan of a bug but for the life of me I cant see it. My understanding is I accept it and assign to myself, then fix it, then what... Do I put the bug in fixed state and submit the patch or leave that change to the raised? Jason

2 1

Re: Allow assignment of olefonts to other olefonts
by Mike Hearn 08 Sep '04

08 Sep '04

Alexandre, is there anything wrong with this patch? > ChangeLog: > Allow assignment of olefonts to other olefonts

2 2

Installing Platform SDK on Wine
by Dan Kegel 08 Sep '04

08 Sep '04

After (more or less) installing IE6 on Wine, I tried installing the Platform SDK. Looks like their Setup.exe program invokes IE and some ActiveX control. And it looks like I don't know how to install the msi packages without their setup.exe (maybe someone else knows?). This was with Wine-20040813, I think. I'm trying to get a valid windows.h for use with cl out of this. I may punt and just use the windows.h that comes with wine -- it doesn't work off the bat, but maybe it's easier to fix (possibly by just adding some -D's to the commandline) than the real platform sdk install. - Dan p.s. here's how I tried to install the Platform SDK #!/bin/sh # Download and install Platform SDK # See # http://www.eggheadcafe.com/ng/microsoft.public.vstudio.development/post2716… and # http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm set -ex # Platform SDK for file in \ PSDK-FULL.1.cab PSDK-FULL.2.cab PSDK-FULL.3.cab PSDK-FULL.4.cab PSDK-FULL.5.cab PSDK-FULL.6.cab \ PSDK-FULL.7.cab PSDK-FULL.8.cab PSDK-FULL.9.cab PSDK-FULL.10.cab PSDK-FULL.11.cab PSDK-FULL.12.cab \ PSDK-FULL.13.cab ; do wget -c http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-… done # Extract. Requires 1.4 GB free space! # We could download Extract.exe from the above dir, and use wine to run it, but # may as well use the native command. cabextract -d ~/.wine/c/psdk *.cab # Install. Tries to invoke IE. Doesn't work for me... cd ~/.wine/c/psdk wine Setup.exe # Directly install part of it. Doesn't work for me either; just chews CPU? cd setup wine msiexec /i CoreSDK-x86.msi -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

1 0

Re: define RPC_NO_WINDOWS_H to prevent rpc.h from including windows.h
by Alexandre Julliard 08 Sep '04

08 Sep '04

Mike McCormack <mike(a)codeweavers.com> writes: > ChangeLog: > * define RPC_NO_WINDOWS_H to prevent rpc.h from including windows.h Why do you need this? -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: Wine and industrial communication like OPC
by Rickard Svensson 08 Sep '04

08 Sep '04

> > > > Now I also got some questions from your answers: > > > > * Did I understand correctly. Wine doesn't have a built in support for DCom, to be abel to use Dcom I have to add the DCom support from Windows 98 to the Linux system? > > And the problem with that is the MS License, it stops me from distribute those XXX.dll with a Linux product (hardware and software in this case.) > > It doesn't stop you, basically the license says "you must have a Windows > license to use this code". Because it's technically a part of Windows, see? Yyyy! I hate license issues! I can see that for many people this wouldn't be an issue, because they probably have some old Win 98 CD/Licens somewhere (if they even care). But for a company that would like to send it as part of an embedded computer with Linux I can se a lot of problems. > However a Windows license is quite cheap relative to $3000-$4000 for the > APIs so maybe this isn't a problem. But that was per development project, not per system we want to use OPC in. > You could even buy copies of Windows 98 off ebay or something for > ultra-cheap living. The license can be for any version of Windows AFAIK. That could perhaps be an idea.... What does AFAIK stand for? > The difficulty may be that nobody has tested network DCOM servers on > Wine as far as I know, even using Microsofts implementation. So you'd be > doing some pioneering work :) That is good ;-) In the industry we are a lot of people who really question the total madness of letting the OPC standard be that depended on Windows, when it is supposed to be a "free" organization. My hope if I can get this to work is to publish a site on the net so all who want to use Linux in the industrial computing can do that quite easy... But then we have the license issues to :-( > - Wines own, builtin code. This is incomplete and cannot do what you want. > > - Microsofts DCOM implementation > > Wine *does* have support for MSRPC, and I think it's wire compatible > with Windows these days and capable of making simple RPCs. However the > RPC runtime (rpcrt4.dll) is just the first layer of DCOM, all the rest > don't work right yet. Ok, now I understand, and also why I got confused before. And there is a lot of work needed to make DCom to work in Wine? Is someone working on it or is it something that not is that important in other cases? Thanks a lot Mike for you answer! /Rickard -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

5 4

Re: Fix bin2res Help Text
by Dimitrie O. Paun 07 Sep '04

07 Sep '04

On Mon, Sep 06, 2004 at 02:37:05AM +0100, Robert Shearman wrote: > " /* BINRES idb_std_small.bmp */\n" > - " {}\n" > + " IDB_STD_SMALL BITMAP idb_std_small.bmp\n" > + " /* {\n" > + " } */\n" What's wrong with the current help. I thought BINRES is the marker... -- Dimi.

1 0

More winecfg todos
by Mike Hearn 07 Sep '04

07 Sep '04

On Thu, 29 Jul 2004 23:19:11 -0500, Alexandre Julliard wrote: > Log message: > James Hawkins <truiken(a)gmail.com> > Under the Drives tab, remove the 'Windows Drive' section. You probably want to increase the size of the drive mappings list so it fills the tab, currently there is just a lot of empty space at the top of the pane now you removed the old stuff. Also we should kill the autodetect button. This is done by wineprefixcreate these days, or should be. Other things are: - Drive editing seems broken. The list box only updates the second time I hit edit. err:winecfg:applyDriveChanges unable to set volume label for devicename of 'H:\', label of '' - Browse in the "Add/Edit drive" dialog is a WRITEME - Build system isn't right: I did a cvs update but the res files weren't recreated properly. I had to do a make clean to get the gui updates. - "Add Application" has poor usability: we always use a file browser dialog box even though the most common use case is just "foo.exe", ie the user knows the name and doesn't care about the location. Worse we start in the c:\windows\desktop folder for some reason, meaning users might accidentally select a .lnk file! Ditto for Libraries tab. - The Add/Remove application buttons are *way* too big! - Obviously, once audio autodetection has been moved into the drivers we need to kill the audio tab. - Libraries tab just has generally poor usability, actually. The first item in the radio group is "Builtin" meaning that's the one users are most likely to select, it should be "builtin, native" followed by "native, builtin" - We ask the user to understand a magic * symbol to set the default - what is up with that? - There are no helpful default entries in the drop down box for setting a DLL override, and when you add one the tree does not expand so to actually *set* it you have to expand the tree then select the new override. - We have way too many (eg, more than zero) tree controls in this app. - Drive mappings list is really unclear, there's no separation between the "Drive X:" label and the unix path its mapped to. Basically I'd recommend reading the GNOME HIG: http://developer.gnome.org/projects/gup/hig/ it's a very informative read. Obviously we have to use Win32 UI conventions at least at first, but there's a lot of generically good advice there. Well worth reading for anybody who is going to work on winecfg. thanks -mike

4 4

Re: Create DLL stub files in c:\windows\system
by Hans Leidekker 07 Sep '04

07 Sep '04

On Saturday 4 September 2004 14:25, Mike Hearn wrote: > Make apps that search for the DLL files directly happy by creating empty > files for each shipped library There are applications (eDonkey is one of them IIRC) that call LoadLibray() themselves on a number of DLLs. Could be that they do their own linking as part of some anti-debugging technique, I don't know, but it's perfectly legal for application to do that anyway. For these apps having empty DLL files will not be enough. I actually was able to fool the app by putting MinGW cross compiled Wine DLLs in the system directory until it needed kernel32.dll, which doesn't compile. I had to resort to a native win2k kernel32.dll to get it past this but this may still be a good alternative to your empty DLL files. -Hans

8 17

Re: windos: fix EXTENDED COUNTRY INFORMATION
by Vincent Béron 07 Sep '04

07 Sep '04

Le mar 07/09/2004 à 06:10, Markus Amsler a écrit : [snip] > *** wine/dlls/winedos/int21.c Tue Aug 24 17:45:23 2004 > --- wine-20040615/dlls/winedos/int21.c Fri Aug 6 11:57:04 2004 > *************** > *** 2116,2123 **** > static void INT21_ExtendedCountryInformation( CONTEXT86 *context ) > { > BYTE *dataptr = CTX_SEG_OFF_TO_LIN( context, context->SegEs, context->Edi ); > ! BYTE buffsize = CX_reg (context); > ! > TRACE( "GET EXTENDED COUNTRY INFORMATION, subfunction %02x\n", > AL_reg(context) ); Please send your patches in diff unified (diff -u) format. Vincent

1 0

Re: Wine Developer Cheatsheet, v1
by Rolf Kalbermatter 07 Sep '04

07 Sep '04

"Diego 'Flameeyes' =?ISO-8859-1?Q?Petten=F2?=" wrote: >I have only a doubt: > >> - Is it possible to implement the ANSI version by converting to unicode >> then calling the wide version, rather than duplicate it? > >How can I convert an ansi string to a unicode one and reverse? So I can redo >the patch with the calls :) Typically you use MultiByteToWideChar() for any input strings and then WideCharToMultiByte() for possible output strings. You can look at shlwapi/path.c and other files in there to see how this is usually done. Depending on the place where you do it, it might be preferable to use dynamically allocated buffers instead of using stack space as Wine is already using quite a lot of stack. Principle: WCHAR *textW; INT countW = MultiByteToWideChar(CP_ACP, 0, textA, -1, NULL, 0); if((textW = HeapAlloc(GetProcessHeap(), 0, countW * sizeof(WCHAR)))) { MultiByteToWideChar(CP_ACP, 0, textA, -1, textW, countW); /* Do the Widechar call */ HeapFree(GetProcessHeap(), 0, textW); } Rolf Kalbermatter

4 4

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