January 2003 - Wine-devel - list.winehq.org

problem using msvcmaker to build conformance test suite project file
by Dan Kegel 04 Jan '03

04 Jan '03

http://www.winehq.com/Docs/wine-devel/testing-windows.shtml says: > Run msvcmaker to generate Visual C++ project files for > the tests. ... > > $ ./tools/winapi/msvcmaker --no-wine I did that in my cvs wine directory, and all I got was .: searching for /\.spec$/ .: searching for /^Makefile.in$/ <internal>: options.pm: member W0B5 does not exists Um, did I do something wrong? Or is there a bug in msvcmaker? I'm on Red Hat 8.0, btw. - Dan -- Dan Kegel Linux User #78045 http://www.kegel.com

1 0

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