wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Re: sharpdevelop and .NET
by Sylvain Petreolle 04 Jan '03

04 Jan '03

--- tom potts <madtom1999(a)yahoo.com> a écrit : > Sylvain > I cant get on the list from home but I tried copying > mscoree.dll and sharpdevelop got as far as asking for > some registry settings to be set!! lol :) that was an evidence ! otherwise microsoft wouldn't give a 20 Mb file to download. > I tried installing the redistributable but I need > IE5.01 or higher and the M$ download fails under wine! > I beleive I have a CD install at work so I'll try that > on monday and then try installing .Net again. shouldnt fail... check the wine-users archive. many work has been done to make this possible. if this really fails, make a bygreport on wine-users and set these entries. this will an ie6 installed. [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer] "Build"="62800" "Version"="6.0.2800.1106" "W2kVersion"="6.0.2800.1106" "IntegratedBrowser"=dword:00000001 "MkEnabled"="Yes" > All I want is a good IDE for .NET/Mono on Linux and > then I can help to get Mono up and running.... > Tom understood ;) does mono already run .NET ? ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

IE browsing local files
by Mike Hearn 04 Jan '03

04 Jan '03

Hi all, When entering a local address, for instance "C:\" into the IE address bar, it dies with a crash somewhere inside comctrl32 (it seems). Is this because it tries to engage the Explorer view COM object, and that isn't present in Wine? Also, a bit OT this one, but I've been told that the MS EULA in Office XP forbids running it on anything other than Windows. Is this true, and if so, is it legal for them to say this? thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 1

NT4 SP 6a entries
by Sylvain Petreolle 04 Jan '03

04 Jan '03

On Dec 19, you made a patch to add the SP6a registry key to winedefault.reg. Today, I made a cvs update and imported winedefault.reg into my registry. Trying to install the .NET Framework Package, with nt40 as windows version, it says to install SP6a ot higher. Are you sure its the right hotfix/is there an another way to check if SP6a is installed ? ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 2

Mac OS X/Darwin port of Wine
by Jim White 04 Jan '03

04 Jan '03

Hi Gang. A few weeks ago when I thought how cool it would be to marry Wine and Bochs to run Windows progams on Mac OS X & Darwin, I checked around, including this list, and didn't find any activity. So I opened a SourceForge project to focus on just that goal: http://darwine.sf.net After I uploaded the home page tonight, I checked here again and found this topic had just come up last week! I don't know yet whether it makes sense to maintain a separate discussion and/or repository for this purpose. Seems like it would at least be useful during active initial work and then perhaps phase out. In any case, the resource is ready-to-use and I'ld like to hear from others interested in this port. Jim

2 1

Update: Wine & Mozilla
by Dimitrie O. Paun 04 Jan '03

04 Jan '03

Hi folks, For those of you who follow my Winelib quest, one of the most ambitious projects is compiling Mozilla under Wine. Needless to say, this would be quite something to accomplish, and would provide Wine with a formidable test for it's headers, and it's tools (wine{build,gcc,wrap), wrc). The goal of course is to port the entire beast with very little changes. For anyone who looked at the source, it should be clear that this is the only way it can happen. If it requires massive work, I'm just not going to do it. To accomplish this task, Mozilla needs to build first on mingw. Unfortunately, Mozilla still requires MSVC to compile on Windows. There is an ongoing effort that is tracked in bug #134113: http://bugzilla.mozilla.org/show_bug.cgi?id=134113 I will be lending those guys a hand with the port. Mostly the work seems to be done, they just need a gentle nudge to get it in the tree (I hope :)). As always, your comments and suggestions are highly appreciated. -- Dimi.

3 4

Make argv[0] an absolute path so 'wine d:setup' works (2nd try)
by Dan Kegel 04 Jan '03

04 Jan '03

My last version broke the existing regression tests. This one doesn't, and I've added a regression test to make sure argv[0] is an absolute path. This patch should be reviewed carefully, as I don't really understand Wine's internals yet. Changelog: * scheduler/process.c: make argv[0] absolute so 'wine d:setup' works * dlls/kernel/tests/process.c: verify that argv[0] is absolute and contains drive letter Copyright 2003, Dan Kegel. LGPL. -- Dan Kegel Linux User #78045 http://www.kegel.com Index: scheduler/process.c =================================================================== RCS file: /home/wine/wine/scheduler/process.c,v retrieving revision 1.205 diff -d -u -r1.205 process.c --- scheduler/process.c 5 Dec 2002 19:56:15 -0000 1.205 +++ scheduler/process.c 4 Jan 2003 04:13:31 -0000 @@ -577,6 +577,7 @@ { char error[100], *p; DWORD stack_size = 0; + char main_exe_name_copy[MAX_PATH]; /* Initialize everything */ if (!process_init( argv )) exit(1); @@ -610,6 +611,10 @@ MESSAGE( "%s: cannot open builtin library for '%s': %s\n", argv0, main_exe_name, error ); ExitProcess(1); } + + /* absolutify argv[0] so 'wine d:setup' works */ + strcpy(main_exe_name_copy, main_exe_name); + argv[0] = main_exe_name_copy; switch( MODULE_GetBinaryType( main_exe_file )) { Index: dlls/kernel/tests/process.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/process.c,v retrieving revision 1.7 diff -d -u -r1.7 process.c --- dlls/kernel/tests/process.c 18 Dec 2002 20:51:33 -0000 1.7 +++ dlls/kernel/tests/process.c 4 Jan 2003 04:13:32 -0000 @@ -624,6 +624,7 @@ char buffer[MAX_PATH]; PROCESS_INFORMATION info; STARTUPINFOA startup; + const char *pstr; memset(&startup, 0, sizeof(startup)); startup.cb = sizeof(startup); @@ -640,6 +641,12 @@ WritePrivateProfileStringA(NULL, NULL, NULL, resfile); okChildInt("Arguments", "argcA", 4); + pstr = getChildString("Arguments", "argvA0"); + ok(pstr != NULL, "expected non-null argv[0]"); + if (pstr) { + ok(pstr[1] == ':', "expected drive letter in argv[0], got %s", pstr); + ok(pstr[2] == '\\', "expected absolute path in argv[0], got %s", pstr); + } okChildString("Arguments", "argvA3", "C:\\Program Files\\my nice app.exe"); okChildString("Arguments", "argvA4", NULL); okChildString("Arguments", "CommandLineA", buffer);

1 0

GlobalAlloc GlobalReAlloc problem
by Michael Stefaniuc 04 Jan '03

04 Jan '03

Hello, the Minolta "DiMAGE Image Viewer" (Minolta Dimage digicams use a wider gamut colorspace and to transform that to sRGB you need this tool) makes strange ASSumptions about Global{Alloc,ReAlloc,Size} in it's jpeg exporter (JPEG.GEX, a dll de facto) thus corrupting the output jpg if it's bigger then 1 MB. Deducing from the +relay,+global,+heap debug output it does basicaly this (in pseudo C code): LPVOID ptr; hGlobal = GlobalAlloc(GMEM_MOVEABLE | GMEM_ZEROINIT, 0); still_needed_space = size_of_output_jpeg; while (still_needed_space > 0) { old_size = GlobalSize(hGlobal); want = (still_needed_space / 0x100000) ? 0x100000 : still_needed_space; still_needed_space -= want; GlobalReAlloc(hGlobal, old_size + want, GMEM_ZEROINIT); ptr = GlobalLock(hGlobal) + old_size; GlobalUnlock(hGlobal) Do_the_work using ptr } WriteFile(output_jpg_h, GlobalLock(hGlobal), size_of_output_jpeg, ...) The problem is that msdn states for GlobalAlloc (i implicitly assume that it applies for GlobalReAlloc too) that the memory is alligned on an 8byte boundary and that it allocates "at least" the requested number of bytes. That means more memory can be allocate and even msdn recommends to check the actual allocated size with GlobalSize. With the above code wine allocates 0x100004 bytes for the first call to GlobalReAlloc thus inserting four 0 bytes at position 0x100000 and cutting 4 bytes from the end of the jpeg. And this leads to corrupted jpeg's. Here are some snippets from the debug log to demonstrate it: 082c5d08:Call kernel32.GlobalAlloc(00000042,00000000) ret=46bd004a trace:global:GlobalAlloc () flags=0042 trace:heap:RtlAllocateHeap (0x40240000,00000002,00000080): returning 402baec0 08076498:Ret ntdll.RtlAllocateHeap() retval=402baec0 ret=40731b96 08076498:Call ntdll.RtlFreeHeap(40240000,00000000,402baec0) ret=40731b69 trace:heap:RtlAllocateHeap (0x40240000,00000002,00000018): returning 402b64f8 082c5d08:Ret kernel32.GlobalAlloc() retval=402b64fa ret=46bd004a [snip] 082c5d08:Call kernel32.GlobalSize(402b64fa) ret=46bce386 082c5d08:Ret kernel32.GlobalSize() retval=00000000 ret=46bce386 082c5d08:Call kernel32.GlobalReAlloc(402b64fa,00100000,00000040) ret=46bce39b trace:heap:HEAP_FindFreeBlock created new sub-heap 475c0000 of 00100040 bytes for heap 40240000 trace:heap:RtlAllocateHeap (0x40240000,0000000a,00100008): returning 475c0020 082c5d08:Ret kernel32.GlobalReAlloc() retval=402b64fa ret=46bce39b 082c5d08:Call kernel32.GlobalLock(402b64fa) ret=46bce3bd 082c5d08:Ret kernel32.GlobalLock() retval=475c0024 ret=46bce3bd 082c5d08:Call kernel32.GlobalUnlock(402b64fa) ret=46bce3d3 082c5d08:Ret kernel32.GlobalUnlock() retval=00000000 ret=46bce3d3 [snip] 082c5d08:Call kernel32.GlobalSize(402b64fa) ret=46bce41d trace:heap:RtlSizeHeap (0x40240000,00000002,475c0020): returning 00100008 082c5d08:Ret kernel32.GlobalSize() retval=00100004 ret=46bce41d The first GlobalReAlloc adds 4 (sizeof(HGLOBAL)) to the size (0x100000) and calls RtlAllocateHeap where ROUND_SIZE() increases the size to 0x100008. What makes me wonder is the different behaviour of Global[Re]Alloc regarding the allocated size when it's called without GMEM_MOVEABLE: with whithout GMEM_MOVEABLE GlobalAlloc(size=0) 0 0x18 GlobalAlloc(size=1MB) 0x100004 0x100000 GlobalReAlloc(size=1MB) 0x100004 0x100000 To demonstrate this i did a small patch to dlls/kernel/tests/alloc.c (Still need to install mingw to test it on Windows). Do we want to mimic the GlobalAlloc/GlobalReAlloc behaviour of Windows (the DiMage Viewer dosn't corrupt the images at least on Win98 and it's the same binary for Win2000 too)? Could be that some other broken, real life programs are dependent of that behaviour). At a quick glance i don't know how to fix GlobalAlloc/GlobalReAlloc without breaking it. I'll do a bugzilla report but want to save me the work if it will get anyway a WONTFIX resolution. The version of DiMage Viewer tested is 1.1 and it's not free. Minolta offers only a free upgrade from 2.0 -> 2.1 so I can't test it on a newer version (but i suspect it will still have the bug because the jpeg lib is bought from somebody else and has copyright 1999 whereas the rest is copyright 2001). bye michael P.S.: Not fixing this "bug" wont keep the linux users from enjoying their Minolta DiMage cams without windows because there is a Gimp plugin that can do the color space transformations (and Murphy sei Dank i found this AFTER debugging and finding the problem). -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 1

Re: [D3D 72] Various stuff to get Monkey4 working in D3D mode
by Tony Lambregts 04 Jan '03

04 Jan '03

Lionel Ulmer wrote: > >PS: I updated the d3d_status.html page (http://www.bbrox.org/d3d_status.html) > > > <nit>The links to the screenshots for Aliens vs predator demo are local ie: file:///home/ulmer/Wine/avp_1.png</nit> -- Tony Lambregts

1 0

Re: wine/ library/debug.c include/wine/library.h i ...
by Dimitrie O. Paun 03 Jan '03

03 Jan '03

On January 2, 2003 10:12 pm, Alexandre Julliard wrote: > Added wine_dbg_sprintf function that allocates a temporary buffer > in the per-thread strings area. Cool. But what about functions that need to build the string. For example, look at debuglvitem_t() in listview.c. Can we get somehow to the max_size? > Added inline functions to format POINT, SIZE and RECT structures. Can we pretty please get shorter names for them in Wine? Like without the wine_ prefix? :) -- Dimi.

4 19

Re: MAX_LIGHTS redefinition
by Lionel Ulmer 03 Jan '03

03 Jan '03

On Thu, Jan 02, 2003 at 10:35:55PM -0800, Francois Gouget wrote: > > MAX_LIGHTS is defined in two places: > > * mesa.c > #define MAX_LIGHTS 8 > > * d3d_private.h > #define MAX_LIGHTS 16 > > So this patch removes the definition from mesa.c. Hopefully this is ok. This is fixed in one of the 10 or so pending D3D patches. At least, in my working tree I do not have the problem anymore :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 1

Problema running wine20021219 with Xfree 4.2.99
by Alejandro Lorenzo 03 Jan '03

03 Jan '03

I have problems running wine with the snapshot of the new Xfree86 the wine release is 200211219 and i have compiled it from sources without any error. Anytime i try to use wine i get: err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/local/lib/wine/x11drv.dll.so: undefined symbol: XF86VidModeSetGammaRamp Could not load graphics driver 'x11drv' err:win:GetDesktopWindow Wine init error: either you're trying to use an invalid native USER.EXE config, or some graphics/GUI libraries or DLLs didn't initialize properly. Aborting. also tried to make a --debugmsg +relay but i cannot get nothing clear: i get a lot of output of the style (i think this is the interesting part of the log for this, if it necessary, i can attach all the log) 08077198:Ret advapi32.RegOpenKeyA() retval=00000000 ret=40801f57 08077198:Call advapi32.RegQueryValueExA(00000030,408185ff "GraphicsDriver",00000000,40692cd8,40692ce4,40692cdc) ret=40801f89 08077198:Call ntdll.RtlInitAnsiString(40692af4,408185ff "GraphicsDriver") ret=40906280 08077198:Ret ntdll.RtlInitAnsiString() retval=0000000f ret=40906280 08077198:Call ntdll.RtlAnsiStringToUnicodeString(40110178,40692af4,00000000) ret=4090629c 08077198:Ret ntdll.RtlAnsiStringToUnicodeString() retval=00000000 ret=4090629c 08077198:Call ntdll.NtQueryValueKey(00000030,40110178,00000002,40692afc,00000100,40692af0) ret=409062d4 08077198:Ret ntdll.NtQueryValueKey() retval=00000000 ret=409062d4 08077198:Call ntdll.RtlUnicodeToMultiByteSize(40692aec,40692b08 L"x11drv",0000000e) ret=409063e3 08077198:Ret ntdll.RtlUnicodeToMultiByteSize() retval=00000000 ret=409063e3 08077198:Call ntdll.RtlUnicodeToMultiByteN(40692ce4,00000007,00000000,40692b08,0000000e) ret=40906418 08077198:Ret ntdll.RtlUnicodeToMultiByteN() retval=00000000 ret=40906418 08077198:Call ntdll.RtlNtStatusToDosError(00000000) ret=409064dd 08077198:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=409064dd 08077198:Ret advapi32.RegQueryValueExA() retval=00000000 ret=40801f89 08077198:Call advapi32.RegCloseKey(00000030) ret=40801f95 08077198:Call ntdll.NtClose(00000030) ret=409056f6 08077198:Ret ntdll.NtClose() retval=00000000 ret=409056f6 08077198:Call ntdll.RtlNtStatusToDosError(00000000) ret=409056fc 08077198:Ret ntdll.RtlNtStatusToDosError() retval=00000000 ret=409056fc 08077198:Ret advapi32.RegCloseKey() retval=00000000 ret=40801f95 08077198:Call kernel32.LoadLibraryA(40692ce4 "x11drv") ret=40801f9b err:module:BUILTIN32_dlopen failed to load .so lib for builtin x11drv.dll: /usr/local/lib/wine/x11drv.dll.so: undefined symbol: XF86VidModeSetGammaRamp 08077198:Ret kernel32.LoadLibraryA() retval=00000000 ret=40801f9b Could not load graphics driver 'x11drv' 08077198:Ret PE DLL (proc=0x40802830,module=0x40770000,type=1,res=0x1) retval=0 08077198:Call user32.UserSignalProc(00000100,08074198,00000007,00000000) ret=400b7355 08077198:Ret user32.UserSignalProc() retval=00000000 ret=400b7355 08077198:Call user32.UserSignalProc(00000010,08077198,00000007,00000000) ret=400b7341 08077198:Ret user32.UserSignalProc() retval=00000000 ret=400b7341 08077198:Call user32.UserSignalProc(00000200,08074198,00000007,00000000) ret=400b7355 08077198:Ret user32.UserSignalProc() retval=00000000 ret=400b7355 08077198:Call user32.UserSignalProc(00000600,08074198,00000007,00000000) ret=400b7355 08077198:Ret user32.UserSignalProc() retval=00000000 ret=400b7355

1 0

RFH: ICON statement
by Dimitrie O. Paun 03 Jan '03

03 Jan '03

Visual-MinGW uses the following: visual-mingw ICON Mainicon.ico which apparently windres accepts, but fails with wrc because of the '-' in 'visual-mingw'. Can someone please check if it works with the MS tools, to determine if we need to fix wrc? Tnx. -- Dimi.

2 6

Re: sharpdevelop and .NET
by tom potts 03 Jan '03

03 Jan '03

Last nite I loaded wine. sharpdevelop installed ok!! I tried installing the .NET sdk but that caused a segmentation fault. I tried installing the .NET redistributable but that complained of invalid version of windows - can I fix that?? I tried runninf sharpdevelop and it complained about a missing dll so I'll try copying those over from my windows setup..... _____________________________________________________________ Get 25MB, POP3, Spam Filtering with LYCOS MAIL PLUS for $19.95/year. http://login.mail.lycos.com/brandPage.shtml?pageId=plus&ref=lmtplus

2 1

Re: tchar fixes: _tcs{dup,icmp}
by Francois Gouget 03 Jan '03

03 Jan '03

On Mon, 23 Dec 2002, Dimitrie O. Paun wrote: > That's what I have to do on my system. > > Francois, does this seem OK to you? If the fix is right, > what about the other _str* symbols? According to the latest sdk I have (2000), _tcsdup is supposed to map to _strdup and _tcsicmp to _stricmp. I think the catch is you are supposed to link with the msvcrt library since these symbols are only exported there. Now, pointing _tcsdup to strdup should not make any difference. However I am not sure that _stricmp really behaves exactly like strcasecmp: you would need to check how each of these handles accentuated characters and locale. Then the question is whether tchar.h should be considered to be a pure msvcrt thing, i.e. don't use it if you don't link to msvcrt, or whether we want to make is usable in Ansi mode with a regular C library. Currently we set the macros based on _MBCS and _UNICODE. Maybe we need to add a WINE_LIBC flag and add mappings to the native C library routines? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ A black hole is just God dividing by zero.

5 7

Re: IE browsing local files
by Alberto Massari 03 Jan '03

03 Jan '03

At 15.11 03/01/2003 +0000, you wrote: >Hi all, > >When entering a local address, for instance "C:\" into the IE address >bar, it dies with a crash somewhere inside comctrl32 (it seems). Is this >because it tries to engage the Explorer view COM object, and that isn't >present in Wine? I am currently able to browse the local file system only if I use the native version of shell32.dll (btw, I use Wine with the "nt40" setting) Alberto ------------------------------- Alberto Massari eXcelon Corp. http://www.StylusStudio.com

1 0

Re: Install Error with current CVS
by Steven Tower 03 Jan '03

03 Jan '03

I don't remember seeing this err before, I can try to pull different CVS builds to see where it broke, but figured I would post first. I get this when trying to install any version of I.E. err:setupapi:SetupDefaultQueueCallbackA copy error 5 "C:\\WINDOWS\\msdownld.tmp\\AS02BB23.tmp\\w95inf16.dll" -> "C:\\WINDOWS\\SYSTEM\\w95inf16.dll" err:setupapi:SetupDefaultQueueCallbackA copy error 5 "C:\\WINDOWS\\msdownld.tmp\\AS02BB23.tmp\\w95inf32.dll" -> "C:\\WINDOWS\\SYSTEM\\w95inf32.dll" err:setupapi:SetupDefaultQueueCallbackA copy error 5 "C:\\WINDOWS\\msdownld.tmp\\AS02BB23.tmp\\regsvr32.exe" -> "C:\\WINDOWS\\SYSTEM\\regsvr32.exe" fixme:setupapi:GenInstall16 unsupported flag: GENINSTALL_DO_CFGAUTO fixme:reg:RegUnLoadKeyW (0x80000002,L"AINF0000"): stub fixme:reg:RegFlushKey (0xf0): stub fixme:reg:RegUnLoadKeyW (0x80000002,L"AINF0000"): stub err:module:BUILTIN32_LoadLibraryExA loaded .so but dll regsvr32.exe still not found - 16-bit dll or version conflict. err:module:BUILTIN_LoadModule loaded .so but dll regsvr32.exe still not found err:module:BUILTIN32_LoadLibraryExA loaded .so but dll regsvr32.exe still not found - 16-bit dll or version conflict. err:module:BUILTIN_LoadModule loaded .so but dll regsvr32.exe still not found

1 0

Debugger / wineconsole problem
by Lionel Ulmer 03 Jan '03

03 Jan '03

Hi all, I have a little annoying problem with the wineconsole / winedbg : as soon as I switch to another window and come back to the debugger, I loose keyboard input. Mouse input still works fine. I have also often graphical glitches (ie I have only garbage when scrolling due to a newline being displayed). The scollbar seems also to be non-functionnal. Lionel -- Lionel Ulmer - http://www.bbrox.org/

3 5

Re: wineboot - initial version
by Sylvain Petreolle 03 Jan '03

03 Jan '03

Trying wineboot, I realize that it deletes wininit.ini. Real wininit.ini doesn't do this. It renames the file as wininit.bak. Could this updated or should I submit a small patch later ? (or do you disagree ?) ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

__WINE__ vs. __WINESRC__
by Dimitrie O. Paun 03 Jan '03

03 Jan '03

Hi folks, Here is another problem: we are currently defining the __WINE__ symbol to signal the headers that we are compiling Wine. This is fine. The problem that I'm facing is that there are apps (such as wxWindows) that want to know that they are _compiled_ (not run) under Wine. All platforms (and Wine is a platform, even if a virtual one) define standard symbols by default: __WIN32__, __MINGW32__, you name it. There are valid reasons for a program to be able to test that is being compiled under Wine, and not under MinGW for example. Thus, we need to define a standard symbol, and __WINE__ seems to be the most appropriate. I think it's better to expose the prettier name, and use a longer/uglier one internally. So, my proposal is: let's rename the __WINE__ symbol (as it's currently used) to something else (__WINESRC__, or whatever, suggestions welcome), once that's done, define __WINE__ when __WINESRC__ is not defined (the symbols would be mutually exclusive). I can send in a patch if people don't object... -- Dimi.

6 10

Re: wine-devel digest, Vol 1 #1558 - 19 msgs
by Kevin 03 Jan '03

03 Jan '03

Hello: Who has the document about COM?? The websit has information about COM,But it isn't detailed. Thanks very much! ----- Original Message ----- From: <wine-devel-request(a)winehq.com> To: <wine-devel(a)winehq.com> Sent: Friday, January 03, 2003 10:03 AM Subject: wine-devel digest, Vol 1 #1558 - 19 msgs > Send wine-devel mailing list submissions to > wine-devel(a)winehq.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.winehq.com/mailman/listinfo/wine-devel > or, via email, send a message with subject or body 'help' to > wine-devel-request(a)winehq.com > > You can reach the person managing the list at > wine-devel-admin(a)winehq.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wine-devel digest..." > > > Today's Topics: > > 1. Re: __WINE__ vs. __WINESRC__ (Dimitrie O. Paun) > 2. Re: argv[0] needs to be an absolute path (Dan Kegel) > 3. Re: tchar fixes: _tcs{dup,icmp} (Dimitrie O. Paun) > 4. Re: Fixing include quotes (was: Re: conformance test for ShellExecute) (Alexandre Julliard) > 5. Re: tchar fixes: _tcs{dup,icmp} (Alexandre Julliard) > 6. Re: __WINE__ vs. __WINESRC__ (Alexandre Julliard) > 7. Re: Fixing include quotes (was: Re: conformance test for ShellExecute) (Dimitrie O. Paun) > 8. Re: Make RECT === RECTL, fix compile warnings, use uniform format (Alexandre Julliard) > 9. Re: Fixing include quotes (was: Re: conformance test for ShellExecute) (Dan Kegel) > 10. Re: Fixing include quotes (was: Re: conformance test for ShellExecute) (Dimitrie O. Paun) > 11. Fixing SUBLANG_NEUTRAL (was: Re: Fixing include quotes (was: Re: > conformance test for ShellExecute)) (Shachar Shemesh) > 12. Re: Fixing SUBLANG_NEUTRAL (was: Re: Fixing include quotes (was: Re: conformance test for ShellExecute)) (Dimitrie O. Paun) > 13. regression with CFLAGS=-g (Shachar Shemesh) > 14. wine.m4 install bug (Enrico Horn) > 15. Re: wine.m4 install bug (Alexandre Julliard) > 16. Avoid some tests (=?iso-8859-1?q?Sylvain=20Petreolle?=) > 17. Re: RFH: ICON statement (Dimitrie O. Paun) > 18. Re: wineboot - initial version (=?iso-8859-1?q?Sylvain=20Petreolle?=) > > --__--__-- > > Message: 1 > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Reply-To: dpaun(a)rogers.com > Organization: DSSD Software Inc. > To: Alexandre Julliard <julliard(a)winehq.com> > Subject: Re: __WINE__ vs. __WINESRC__ > Date: Thu, 2 Jan 2003 12:02:35 -0500 > Cc: Francois Gouget <fgouget(a)free.fr>, Wine Devel <wine-devel(a)winehq.com> > > On January 2, 2003 12:30 pm, Alexandre Julliard wrote: > > It doesn't really matter, just pick the one you prefer. > > I know, but I was hoping people had better suggestions :) > I like __WINESRC__ the best (but that doesn't mean much <g>), > so unless people have a better idea, that's going to be it. > > > Sure, we can do the rename first. > > Probably a script to do it would be best, no? > > > No, these should be removed. The same effect can be achieved by > > defining COM_NO_WINDOWS_H in the C files that use the include. > > What about defining COM_NO_WINDOWS_H globally in Wine? > > -- > Dimi. > > > --__--__-- > > Message: 2 > Date: Thu, 02 Jan 2003 10:27:43 -0800 > From: Dan Kegel <dank(a)kegel.com> > To: Sylvain Petreolle <spetreolle(a)yahoo.fr> > CC: Wine Devel <wine-devel(a)winehq.com> > Subject: Re: argv[0] needs to be an absolute path > > "sometimes" == "if the program was invoked with a relative path" > > BTW the one-line patch I submitted seems to just preserve > the D: in the example I gave. This is good enough to make > my test case work, but won't fix all uses, I think. > - Dan > > Sylvain Petreolle wrote: > > What do you mean by "sometimes" ? > > > > > >>outputs an absolute path on Windows, but sometimes > >>outputs a relative path on Wine. This causes the > >>commandline > >> $ wine d:setup > >>to fail to find its files properly if it uses the > >>basename of argv[0]. One example of this is msvc4.0 > >>(although it only tries this if an earlier method fails, > >>so there's another bug lurking). > >> > >>I am about to submit a one-line patch to fix this to > >>wine-patches. (If I weren't a wimp, I'd figure out > >>a way to submit a regression test, too, although > >>it'd be a strange one; most of our tests don't need > >>to invoke Wine itself from the Unix commandline!) > >> > >>The same problem exists for programs launched from other > >>wine programs, e.g. from inside wcmd. > >>That's another code path, and I couldn't find a > >>one-line fix for that one. > >>- Dan > > > > -- > Dan Kegel > Linux User #78045 > http://www.kegel.com > > > --__--__-- > > Message: 3 > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Reply-To: dpaun(a)rogers.com > Organization: DSSD Software Inc. > To: Alexandre Julliard <julliard(a)winehq.com> > Subject: Re: tchar fixes: _tcs{dup,icmp} > Date: Thu, 2 Jan 2003 12:23:52 -0500 > Cc: Francois Gouget <fgouget(a)free.fr>, wine-devel(a)winehq.com > > On January 2, 2003 12:38 pm, Alexandre Julliard wrote: > > tchar.h should not depend on msvcrt IMO, at least not in ASCII mode, > > so it should use the normal function names without underscores. It's > > not 100% compatible, but it should still do the right thing, both with > > and without msvcrt. > > Sounds good. But since we are on the subject, here's another thing that's > been troubling me: we have 3 flavors of the crt to worry about: glibc, > msvcrt, and cygwin libc (let's call it cygcrt). To be honest, I haven't > looked in detail at cygcrt but I guess it's a derivative of glibc (as it > is used to port Unix stuff). However, it has stuff such as io.h which is > not present in Unix, and is reminiscent of msvcrt. > > When compiling stuff on Windows with gcc (mingw), it links by default with > cygcrt if available. If the -mno-cygwin option is used, or cygwin is not > available, it links against crtdll. Of course, the appropriate headers are > used automatically. > > For winegcc, I mapped the -mno-cygwin option to use msvcrt, otherwise we > use the native glibc. This is the closest mapping I could find, and it > works fairly well, with a few caveats such as the missing io.h in glibc. > > Anyhow, and ideas on how to deal with all this? > > -- > Dimi. > > > --__--__-- > > Message: 4 > To: "Patrik Stridvall" <ps(a)leissner.se> > Cc: <dpaun(a)rogers.com>, <wine-devel(a)winehq.com>, "Dan Kegel" <dank(a)kegel.com> > Subject: Re: Fixing include quotes (was: Re: conformance test for ShellExecute) > From: Alexandre Julliard <julliard(a)winehq.com> > Date: 02 Jan 2003 10:31:37 -0800 > > "Patrik Stridvall" <ps(a)leissner.se> writes: > > > I think it is better than Alexandre runs > > winapi_cleanup --include-quotes > > himself if he thinks it does the correct things. > > If not please inform me what the problem is. > > > > In my tree, the patch is over 800k. > > I'm not sure there's much point in fixing all the C files. It works > fine the way it is now, the only thing that we need the change is the > exported headers. > > -- > Alexandre Julliard > julliard(a)winehq.com > > --__--__-- > > Message: 5 > To: dpaun(a)rogers.com > Cc: Francois Gouget <fgouget(a)free.fr>, wine-devel(a)winehq.com > Subject: Re: tchar fixes: _tcs{dup,icmp} > From: Alexandre Julliard <julliard(a)winehq.com> > Date: 02 Jan 2003 10:46:35 -0800 > > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > For winegcc, I mapped the -mno-cygwin option to use msvcrt, otherwise we > > use the native glibc. This is the closest mapping I could find, and it > > works fairly well, with a few caveats such as the missing io.h in glibc. > > > > Anyhow, and ideas on how to deal with all this? > > I don't think cygwin is really a big issue, it should be mostly Unix > compatible, and it shouldn't be hard to work around the problems if > any appear. I don't think we need any special infrastructure for that. > > -- > Alexandre Julliard > julliard(a)winehq.com > > --__--__-- > > Message: 6 > To: dpaun(a)rogers.com > Cc: Francois Gouget <fgouget(a)free.fr>, Wine Devel <wine-devel(a)winehq.com> > Subject: Re: __WINE__ vs. __WINESRC__ > From: Alexandre Julliard <julliard(a)winehq.com> > Date: 02 Jan 2003 10:45:07 -0800 > > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > > Sure, we can do the rename first. > > > > Probably a script to do it would be best, no? > > I don't think there are that many, a patch would be fine. > > > > No, these should be removed. The same effect can be achieved by > > > defining COM_NO_WINDOWS_H in the C files that use the include. > > > > What about defining COM_NO_WINDOWS_H globally in Wine? > > That's a possibility too. I think I'd prefer to do it in the > individual C files, but I haven't looked how many would need it, so > maybe it's too much work (though Patrik can probably come up with a > magic script to do it...) > > -- > Alexandre Julliard > julliard(a)winehq.com > > --__--__-- > > Message: 7 > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Reply-To: dpaun(a)rogers.com > Organization: DSSD Software Inc. > To: Alexandre Julliard <julliard(a)winehq.com>, > "Patrik Stridvall" <ps(a)leissner.se> > Subject: Re: Fixing include quotes (was: Re: conformance test for ShellExecute) > Date: Thu, 2 Jan 2003 12:41:34 -0500 > Cc: <wine-devel(a)winehq.com>, "Dan Kegel" <dank(a)kegel.com> > > On January 2, 2003 01:31 pm, Alexandre Julliard wrote: > > I'm not sure there's much point in fixing all the C files. It works > > fine the way it is now, the only thing that we need the change is the > > exported headers. > > Exported headers do need fixing, to avoid hard to detect errors. While > the C files work the way they are now, they are confusing for newcomers. > I think our current trend of doing things as standard as possible, is > a Good Thing(TM). Trying to violate the Principle of Least Surprise as > little as possible can only be good. Moreover, current source code is > many times used as a template by other contributors, which provides > even more incentive to have current code as good/clean as possible <g>. > > Bottom line, since the change is free (the work is done by a script), > and there is little chance of conflicts with other patches (it touches > only the include statements), I think it's worth doing now. > > -- > Dimi. > > > --__--__-- > > Message: 8 > To: dpaun(a)rogers.com > Cc: Dan Kegel <dank(a)kegel.com>, Wine Devel <wine-devel(a)winehq.com> > Subject: Re: Make RECT === RECTL, fix compile warnings, use uniform format > From: Alexandre Julliard <julliard(a)winehq.com> > Date: 02 Jan 2003 10:49:27 -0800 > > "Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > > > As for the new debug* functions, most nontrivial ones are not that > > small. Do you want them defined as static inline in wine/debug.h, > > or exported from ntdll as the other ones? In fact, why not create > > a helper DLL (winedebug) that holds all of this, and that can be > > used on Windows as well, when we port most of our stuff over? > > IMO this would be a mechanism to use only for trivial functions that > can be put inline; more complex ones should be implemented in their > respective dlls. We definitely don't want a big centralized module > that dumps all known structures. > > -- > Alexandre Julliard > julliard(a)winehq.com > > --__--__-- > > Message: 9 > Date: Thu, 02 Jan 2003 11:07:51 -0800 > From: Dan Kegel <dank(a)kegel.com> > To: dpaun(a)rogers.com > CC: Alexandre Julliard <julliard(a)winehq.com>, > Patrik Stridvall <ps(a)leissner.se>, wine-devel(a)winehq.com > Subject: Re: Fixing include quotes (was: Re: conformance test for ShellExecute) > > Dimitrie O. Paun wrote: > > Bottom line, since the change is free (the work is done by a script), > > and there is little chance of conflicts with other patches (it touches > > only the include statements), I think it's worth doing now. > > There is one downside: it may make old patches harder to > apply, and it may make it harder to sync with other > trees (e.g. rewind). > > On the other hand, encouraging people to use the tool > to tidy up any files they're working on makes > patches harder to read, as it mixes formatting changes > with real changes. > > Six of one, half dozen of another... > - Dan > > -- > Dan Kegel > Linux User #78045 > http://www.kegel.com > > > --__--__-- > > Message: 10 > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Reply-To: dpaun(a)rogers.com > Organization: DSSD Software Inc. > To: Dan Kegel <dank(a)kegel.com> > Subject: Re: Fixing include quotes (was: Re: conformance test for ShellExecute) > Date: Thu, 2 Jan 2003 12:54:35 -0500 > Cc: Alexandre Julliard <julliard(a)winehq.com>, > Patrik Stridvall <ps(a)leissner.se>, wine-devel(a)winehq.com > > On January 2, 2003 02:07 pm, Dan Kegel wrote: > > There is one downside: it may make old patches harder to > > apply, and it may make it harder to sync with other > > trees (e.g. rewind). > > In general yes, but I don't think it's a big problem in this > particular case where _only_ #include statements are touched. > These are seldomly changed anyway. As for other trees, all of > Patrik work is BSD AFAIK, so everybody can run the script on > their trees as well. > > -- > Dimi. > > > --__--__-- > > Message: 11 > Date: Thu, 02 Jan 2003 23:05:42 +0200 > From: Shachar Shemesh <wine-devel(a)sun.consumer.org.il> > To: dpaun(a)rogers.com > CC: Dan Kegel <dank(a)kegel.com>, Alexandre Julliard <julliard(a)winehq.com>, > Patrik Stridvall <ps(a)leissner.se>, wine-devel(a)winehq.com > Subject: Fixing SUBLANG_NEUTRAL (was: Re: Fixing include quotes (was: Re: > conformance test for ShellExecute)) > > While we are on the subject of api_check and such, how about changing > SUBLANG_NEUTRAL in all non-neutral languages to SUBLANG_DEFAULT, as it > should be? > > Sh. > > > Dimitrie O. Paun wrote: > > >On January 2, 2003 02:07 pm, Dan Kegel wrote: > > > > > >>There is one downside: it may make old patches harder to > >>apply, and it may make it harder to sync with other > >>trees (e.g. rewind). > >> > >> > > > >In general yes, but I don't think it's a big problem in this > >particular case where _only_ #include statements are touched. > >These are seldomly changed anyway. As for other trees, all of > >Patrik work is BSD AFAIK, so everybody can run the script on > >their trees as well. > > > > > > > > > > --__--__-- > > Message: 12 > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Reply-To: dpaun(a)rogers.com > Organization: DSSD Software Inc. > To: Shachar Shemesh <wine-devel(a)sun.consumer.org.il> > Subject: Re: Fixing SUBLANG_NEUTRAL (was: Re: Fixing include quotes (was: Re: conformance test for ShellExecute)) > Date: Thu, 2 Jan 2003 15:21:32 -0500 > Cc: Dan Kegel <dank(a)kegel.com>, Alexandre Julliard <julliard(a)winehq.com>, > Patrik Stridvall <ps(a)leissner.se>, wine-devel(a)winehq.com > > On January 2, 2003 04:05 pm, Shachar Shemesh wrote: > > While we are on the subject of api_check and such, how about changing > > SUBLANG_NEUTRAL in all non-neutral languages to SUBLANG_DEFAULT, as it > > should be? > > Are you volunteering? :) If it's supposed to be this way, a patch would > be most appreciated, me thinks <g> > > -- > Dimi. > > > --__--__-- > > Message: 13 > Date: Fri, 03 Jan 2003 00:02:01 +0200 > From: Shachar Shemesh <wine-devel(a)sun.consumer.org.il> > To: Wine Devel <wine-devel(a)winehq.org> > Subject: regression with CFLAGS=-g > > Hi, > > There is a regression when compiling wine with CFLAGS=-g. The latest CVS > throws an unhandled exception when exiting notepad. When notepad is > compiled with CFLAGS=-g -O2 (the defaults), there is no crash even if > the rest of the libraries are compiled with -g. This also happens on > Wine 20021216. > > Any idea? > > Shachar > > > > --__--__-- > > Message: 14 > From: Enrico Horn <farmboy1(a)subdimension.com> > Reply-To: farmboy1(a)subdimension.com > To: wine-devel(a)winehq.com > Subject: wine.m4 install bug > Date: Thu, 2 Jan 2003 23:25:35 +0100 > > Hi, > When installing the wine.m4 macro file you cant just use the > <prefix>/share/aclocal dir of wine as destination. > You need to use the <prefix>/share/aclocal dir of automake > as this is the only path where the m4 files will be found. > > Ciao > Enrico > farmboy1(a)subdimension.com > > --__--__-- > > Message: 15 > To: farmboy1(a)subdimension.com > Cc: wine-devel(a)winehq.com > Subject: Re: wine.m4 install bug > From: Alexandre Julliard <julliard(a)winehq.com> > Date: 02 Jan 2003 16:07:28 -0800 > > Enrico Horn <farmboy1(a)subdimension.com> writes: > > > When installing the wine.m4 macro file you cant just use the > > <prefix>/share/aclocal dir of wine as destination. > > You need to use the <prefix>/share/aclocal dir of automake > > as this is the only path where the m4 files will be found. > > No, Wine shouldn't install things outside of its own prefix. If you > install Wine in a non-standard directory then you need to tell > autoconf about it with the -I option. > > -- > Alexandre Julliard > julliard(a)winehq.com > > --__--__-- > > Message: 16 > Date: Fri, 3 Jan 2003 01:39:58 +0100 (CET) > From: =?iso-8859-1?q?Sylvain=20Petreolle?= <spetreolle(a)yahoo.fr> > Subject: Avoid some tests > To: wined <wine-devel(a)winehq.com> > > Having problem with Nvidia driver when making tests, I disabled opengl. > All tests pass. > > If I reenable opengl, dsound test will fail (crash to debugger). > I tried to touch dsound.ok, but test is launched after a 'make > testclean' > so it doesn't work as expected. > > Do someone have tips ? Don't want to edit the Makefile by hand to avoid this. > > ===== > Sylvain Petreolle > spetreolle(a)users.sourceforge.net > Fight against Spam ! http://www.euro.cauce.org/en/index.html > ICQ #170597259 > > "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. > > ___________________________________________________________ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran�ais ! > Yahoo! Mail : http://fr.mail.yahoo.com > > --__--__-- > > Message: 17 > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Reply-To: dpaun(a)rogers.com > Organization: DSSD Software Inc. > To: Mehmet YASAR <myasar(a)free.fr> > Subject: Re: RFH: ICON statement > Date: Thu, 2 Jan 2003 19:02:55 -0500 > Cc: Wine Devel <wine-devel(a)winehq.com> > > On January 2, 2003 12:37 pm, Mehmet YASAR wrote: > > I just tested icon ressource beginning with weird characters like > > "!icon" or "-icon" and that works (tested under VC++/sp5). > > Cool, thanks. I've sent a patch in to support them. BTW, are these > chars also accepted in filenames? > > -- > Dimi. > > > --__--__-- > > Message: 18 > Date: Fri, 3 Jan 2003 03:01:28 +0100 (CET) > From: =?iso-8859-1?q?Sylvain=20Petreolle?= <spetreolle(a)yahoo.fr> > Subject: Re: wineboot - initial version > To: wined <wine-devel(a)winehq.com> > > Trying wineboot, I realize that it deletes wininit.ini. > Real wininit.ini doesn't do this. It renames the file as wininit.bak. > Could this updated or should I submit a small patch later ? (or do you > disagree ?) > > > ===== > Sylvain Petreolle > spetreolle(a)users.sourceforge.net > Fight against Spam ! http://www.euro.cauce.org/en/index.html > ICQ #170597259 > > "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. > > ___________________________________________________________ > Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran�ais ! > Yahoo! Mail : http://fr.mail.yahoo.com > > > --__--__-- > > _______________________________________________ > wine-devel mailing list - wine-devel(a)winehq.com > http://www.winehq.com/mailman/listinfo/wine-devel > > > End of wine-devel Digest > >

1 0

Avoid some tests
by Sylvain Petreolle 03 Jan '03

03 Jan '03

Having problem with Nvidia driver when making tests, I disabled opengl. All tests pass. If I reenable opengl, dsound test will fail (crash to debugger). I tried to touch dsound.ok, but test is launched after a 'make testclean' so it doesn't work as expected. Do someone have tips ? Don't want to edit the Makefile by hand to avoid this. ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus in Matrix, chapter 15. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

1 0

wine.m4 install bug
by Enrico Horn 03 Jan '03

03 Jan '03

Hi, When installing the wine.m4 macro file you cant just use the <prefix>/share/aclocal dir of wine as destination. You need to use the <prefix>/share/aclocal dir of automake as this is the only path where the m4 files will be found. Ciao Enrico farmboy1(a)subdimension.com

2 1

regression with CFLAGS=-g
by Shachar Shemesh 02 Jan '03

02 Jan '03

Hi, There is a regression when compiling wine with CFLAGS=-g. The latest CVS throws an unhandled exception when exiting notepad. When notepad is compiled with CFLAGS=-g -O2 (the defaults), there is no crash even if the rest of the libraries are compiled with -g. This also happens on Wine 20021216. Any idea? Shachar

1 0

Re: Fixing include quotes (was: Re: conformance test for ShellExecute)
by Dan Kegel 02 Jan '03

02 Jan '03

Dimitrie O. Paun wrote: > Bottom line, since the change is free (the work is done by a script), > and there is little chance of conflicts with other patches (it touches > only the include statements), I think it's worth doing now. There is one downside: it may make old patches harder to apply, and it may make it harder to sync with other trees (e.g. rewind). On the other hand, encouraging people to use the tool to tidy up any files they're working on makes patches harder to read, as it mixes formatting changes with real changes. Six of one, half dozen of another... - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

3 3

Re: Make RECT === RECTL, fix compile warnings, use uniform format
by Dimitrie O. Paun 02 Jan '03

02 Jan '03

On December 28, 2002 04:10 pm, Dan Kegel wrote: > Decided to leave debugrect for later, too much of a pain for now. > This patch just uses a uniform format for RECTs where possible. > It reorders three or so TRACEs that had the coordinates in > nonstandard order, too. Patch against current CVS attached. > Should compile fine, but I haven't tested it (so do look it over :-) Cool stuff. Can you please turn this thing: Index: dlls/comctl32/datetime.c =================================================================== RCS file: /home/wine/wine/dlls/comctl32/datetime.c,v retrieving revision 1.34 diff -d -u -r1.34 datetime.c --- dlls/comctl32/datetime.c 2 Dec 2002 18:11:00 -0000 1.34 +++ dlls/comctl32/datetime.c 28 Dec 2002 20:43:22 -0000 @@ -1098,7 +1098,7 @@ infoPtr->rcClient.bottom = HIWORD(lParam); infoPtr->rcClient.right = LOWORD(lParam); - TRACE("Height=%d, Width=%d\n", infoPtr->rcClient.bottom, infoPtr->rcClient.right); + TRACE("Height=%ld, Width=%ld\n", infoPtr->rcClient.bottom, infoPtr->rcClient.right); /* use DrawEdge to adjust the size of rcEdge to get rcDraw */ memcpy((&infoPtr->rcDraw), (&infoPtr->rcClient), sizeof(infoPtr->rcDraw)); Into a standard [(%ld,%ld)-(%ld,%ld)]? As for debugrect(), it seems like half of the printed rectangles are in commctrl, so what we can do is use debugrect() in there without having to introduce any infrastructure changes. We can do that after Alexandre commits this change, so we don't cram too much stuff into one patch. -- Dimi.

3 7

Jump to page:

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