- wine-devel - winehq.org

Re: help with linking needed
by Ralf Juengling 22 Nov '03

22 Nov '03

> I have successfully compiled sources of a Windows application, but > when starting up, it tries to locate and link to a windows dll > to access some C library functions: > > ... > err:module:import_dll No implementation for cw3230.DLL._strlen imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._strncpy imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._strtok imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._tolower imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:import_dll No implementation for cw3230.DLL._toupper imported > from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", > setting to 0xdeadbeef > err:module:LdrInitializeThunk Main exe initialization failed, status > c0000135 > > First of all: Where does the name "cw3230.DLL" come from -- Wine didn't > install such a dll on my system? Okay, I found the answer to this myself, it is quite embarrassing: Amid the sources that I got there was also the executable compiled on a Windows system by a Borland compiler. Since the winelib-generated make file creates a shared library and not an executable, the spurious native Windows executable was not overwritten by my built. The wineapploader script then started wine with the native Windows executable instead of the shared library "memview.exe.so", and the missing DLL reported above is probably Borlands C runtime library or part of it. So forget about the other questions in my previous posting. Now the problem is that the applicaiton doesn't start but immediately fails with a Segmentation Fault. The problem seems to be in the function GetFullName in files/dos_fs.c; here are the last four lines of a startup trace: 0009:trace:nls:WideCharToMultiByte cp 65010 L"memview.exe" -> "memview.exe" 0009:trace:dosfs:DOSFS_FindUnixName (/local/builts/phaeaco-20031119/src/memview,L"memview.exe") -> L"memview.exe" (L"MEMVIEW.EXE") 0009:trace:heap:RtlFreeHeap (0x401e0000,00000002,401e0918): returning TRUE 0009:trace:dosfs:DOSFS_GetFullName returning /local/builts/phaeaco-20031119/src/memview/memview.exe = L"Z:\\LOCAL\\BUILTS\\PHAE~WVJ\\SRC\\MEMVI\ EW\\MEMVIEW.EXE" Segmentation fault (Note: I had renamed the file "memview.exe.so" to "memview.exe"). I haven't looked into and tried to fix GetFullName yet but will do so next week. Of course, I hope somebody who knows the code well will come up with a fix before I try. :-) Thanks for the Wine, Ralf

1 0

Configuration parameters
by Dimitrie O. Paun 22 Nov '03

22 Nov '03

Hi folks, I've finally managed to do the table I've promised for so long. My appologies for the delay. This has been mind numbing work, and as such I haven't payed that much attention to the values I've filled in those columns. Please send me your comments so I can post a final version of this to the WineHQ site soon. Note: best viewed in a web browser, but an editor that can display about 150 columns would do just fine as well. -- Dimi.

7 20

Re: winmm: move MCI settings from system.ini to the registry
by Eric Pouech 22 Nov '03

22 Nov '03

Dimitrie O. Paun wrote: > Eric, > > I think these values (*.drv) sit under > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MCI > and not under > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\MCI32 > as you suggested. On NT, MCI key is for 16 bit drivers and MCI32 key is for 32 bit drivers. The registry key for Win9x is not the same (it's HKML\System\CurrentControlSet\Control\MediaResources\mci). And most of the programs for Win9x still want to advertize their drivers in system.ini and not especially in the registry, so we'll have to provide some backup for that too. And to add the final touch, native drivers are 16bits (even on NT, at least 'til 2k, didn't check on XP), wine's are 32 bits. Wine current code should take of this (ie load a 16 bit driver when a 32 bit was requested, and do all the 16 <=> 32 transformation). So, what I'd suggest is to support all the schemes for configuring drivers, in this order of (decreasing) priority: registry-NT key (16+32), registry-Win9x key (16+32), system.ini (16+32). We also need to be consistent about this for all the drivers (and not only the MCI ones), which mean a deeper look at the code (video, acm...). I also think, since we're about to use the native registry settings, that we need to support the "Disabled" key in driver configuration, otherwise we might get lots of errors (for not correctly working devices). I won't have too much time to look at this in details right now, so if someone wants to jump in, I'll be happy to give him (her ?) a hand. A+ -- Eric Pouech

1 0

RFC: {Global,Local}{Re,}Alloc()
by Dimitrie O. Paun 22 Nov '03

22 Nov '03

Hi folks, There are a few places in Wine where we're not using the Heap*() functions, but rather the old {Global,Local}{Re,}Alloc() ones. IIRC we need to do so in controls/edit.c for compatibility with old Win16 code, but why do we do so in places like: * print dialog * ole32 * shell32 * shlwapi Here is a list of places where {Global,Local}ReAlloc() are used. I'd like to replace them with Heap* functions where it is possible, but before I do, I need to know where we need the old calls. ./controls/edit.c: hloc32W_new = LocalReAlloc(es->hloc32W, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT); ./controls/edit.c: if ((hNew32W = LocalReAlloc(es->hloc32W, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT))) { ./controls/edit.c: hloc32A_new = LocalReAlloc(es->hloc32A, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT); ./controls/edit.c: hloc16_new = LOCAL_ReAlloc(hInstance, es->hloc16, alloc_size, LMEM_MOVEABLE | LMEM_ZEROINIT); ./dlls/commdlg/printdlg.c: *hmem = GlobalReAlloc(*hmem, size, GMEM_MOVEABLE); ./dlls/commdlg/printdlg.c: *hmem = GlobalReAlloc(*hmem, size, GMEM_MOVEABLE); ./dlls/commdlg/printdlg.c: lppd->hDevMode = GlobalReAlloc(lppd->hDevMode, ./dlls/commdlg/printdlg.c: lppd->hDevMode = GlobalReAlloc(lppd->hDevMode, ./dlls/commdlg/printdlg16.c: *hmem = GlobalReAlloc16(*hmem, size, GMEM_MOVEABLE); ./dlls/commdlg/printdlg16.c: lppd->hDevMode = GlobalReAlloc16(lppd->hDevMode, ./dlls/kernel/local16.c: hseg = GlobalReAlloc16( hseg, 0x10000, GMEM_FIXED ); ./dlls/kernel/local16.c:HLOCAL16 LOCAL_ReAlloc( HANDLE16 ds, HLOCAL16 handle, WORD size, WORD flags ) ./dlls/kernel/local16.c:HLOCAL16 WINAPI LocalReAlloc16( HLOCAL16 handle, WORD size, UINT16 flags ) ./dlls/kernel/local16.c: return LOCAL_ReAlloc( CURRENT_DS, handle, size, flags ); ./dlls/kernel/local16.c:DWORD WINAPI Local32ReAlloc16( HANDLE heap, DWORD addr, INT16 type, ./dlls/kernel/resource16.c: handle = GlobalReAlloc16( hMemObj, pNameInfo->length << sizeShift, 0 ); ./dlls/kernel/resource16.c: handle = GlobalReAlloc16( hMemObj, pNameInfo->length << sizeShift, 0 ); ./dlls/ole32/hglobalstream.c: This->supportHandle = GlobalReAlloc(This->supportHandle, ./dlls/ole32/ifs.c: Malloc32.SpyedBlocks = (LPVOID*)LocalReAlloc((HLOCAL)Malloc32.SpyedBlocks, NewLength, GMEM_ZEROINIT); ./dlls/ole32/memlockbytes.c: This->supportHandle = GlobalReAlloc(This->supportHandle, ./dlls/ole32/memlockbytes16.c: This->supportHandle = GlobalReAlloc16(This->supportHandle, ./dlls/shell32/shell32_main.c: hargv=GlobalReAlloc(hargv, size, 0); ./dlls/shell32/shellole.c: addr = (LPVOID) LocalReAlloc((HANDLE) pv, cb, GMEM_ZEROINIT | GMEM_MOVEABLE); ./dlls/shlwapi/clist.c: lpTemp = (LPSHLWAPI_CLIST)LocalReAlloc((HLOCAL)pItem, ulSize, ./dlls/shlwapi/clist.c: lpIter = (LPSHLWAPI_CLIST)LocalReAlloc((HLOCAL)*lppList, ./dlls/shlwapi/clist.c: lpList = (LPSHLWAPI_CLIST)LocalReAlloc((HLOCAL)*lppList, ulNewSize, ./dlls/user/dde/misc.c: hData = GlobalReAlloc((HGLOBAL)hData, new_sz + sizeof(DDE_DATAHANDLE_HEAD), ./objects/gdiobj.c: if ((new_handle = (HGDIOBJ)(ULONG_PTR)LOCAL_ReAlloc( GDI_HeapSel, h, size, LMEM_MOVEABLE ))) ./objects/metafile.c: return (HMETAFILE16)GlobalReAlloc16( hMeta, 0, -- Dimi.

3 2

Re: wn20031121_197.xml
by Brian Vincent (C) 21 Nov '03

21 Nov '03

> If I am not mistaken, I offered him commit access a while ago. He was > content at the time to have my slow butt commit. The offer still > stands. Yeah.. maybe it's time I take you up on it. Up until recently I didn't have reliable shell access. Now I've got a nice shell account and have reliable access from home. CVS access won't make my life any easier, however. I still have to mail Zack Brown the issues for his Kernel Traffic site. But adding a few steps shouldn't be a big deal. I think Eric always did the commits himself a few years ago. > I try to commit as soon as I see the XML, but when he sends it to > wine-patches at midnight on a Friday, well... it just may not get up > until Monday morning. Or, more likely, 2am on Saturday. I'm usually not drunk enough by midnight to finish a WWN issue ;) CVS access might be a good thing since my winter schedule is going to be changing quite a bit. The late Thursday/early Friday approach might be harder. One nice thing about posting these by midday on Friday is that we probably get a few more people reading them as opposed to publishing them on a Saturday. -brian

1 0

Re: wn20031121_197.xml
by Shachar Shemesh 21 Nov '03

21 Nov '03

Vincent Béron wrote: >Le ven 21/11/2003 à 14:44, Shachar Shemesh a écrit : > > >>Wouldn't you say that it's time to give Vincent commit access to the web >>site? >> >> > >That'd be Brian, not me. > >Vincent > > > Luckily, it has recently rained, and so there is plenty of mud for my face. Sorry about that. On a totally different subject - wouldn't you say it was time to give Brian Vincent commit access to the web site? Shachar -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/

2 1

Re: wine/ graphics/x11drv/xfont.c graphics/x11drv/ ...
by Dimitrie O. Paun 21 Nov '03

21 Nov '03

On November 20, 2003 07:17 pm, Alexandre Julliard wrote: > Get rid of a bunch of TSX functions. Yay! Getting rid of the TSX functions seems to be within our reach now. I hope this is the plan, right? :) -- Dimi.

3 6

Re: wn20031121_197.xml
by Shachar Shemesh 21 Nov '03

21 Nov '03

Wouldn't you say that it's time to give Vincent commit access to the web site? Brian Vincent wrote: >wn20031121_197.xml > >-brian > > >------------------------------------------------------------------------ > ><?xml version="1.0" ?> ><kc> > ><title>Wine Traffic</title> > > >

1 0

Agent 2.0: escape key problem.
by Rein Klazes 21 Nov '03

21 Nov '03

Hi, Next problem with Agent 2.0 beta. The problem is when composing a message (email/usenet) and pressing the escape key. Expected is a dialog to confirm whether you want to save the message, not to save it or to cancel. Instead the dialog flashes and disappears again and nothing happens. Here is cut from the debug (relay,message,msg,key,hook) trace, leaving out most uninteresting lines. | trace:key:X11DRV_KeyEvent KeyPress : keysym=FF1B (Escape), # of chars=1 / 0x1b / '' | trace:key:EVENT_event_to_vkey e->keycode = 9 | trace:key:X11DRV_KeyEvent keycode 0x9 converted to vkey 0x1b | trace:key:X11DRV_KeyEvent bScan = 0x01. | 000b:Call user32.SendInput(00000001,406cf020,0000001c) ret=40d9cf6a | trace:key:queue_kbd_event wParam=001b, lParam=00010001, InputKeyState=81 | 000b:Ret user32.SendInput() retval=00000001 ret=40d9cf6a key press gets queued. | 000b:Call user32.GetMessageA(008f4478,00000000,00000000,00000000) ret=005e1c89 | trace:msg:MSG_peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x10064 wp 1b lp 10001 | trace:hook:HOOK_CallHooks calling hook 0x5fa990 WH_KEYBOARD code 0 wp 1b lp 10001 module L"" | 000b:Call hook proc 0x5fa990 (id=WH_KEYBOARD,code=0,wp=0000001b,lp=00010001) Getmessage picks up the keystroke and calls a hook. |000b:Call user32.MessageBoxA(00010026,41cefa3c "Save changes to message \"No Subject\"?",41cefa8c "Agent",00000023) ret=0066e78c The hook calls up the confirmation dialog. | trace:key:X11DRV_KeyEvent KeyRelease : keysym=0 (No Name), # of chars=0 / 0x00 / '' | trace:key:EVENT_event_to_vkey e->keycode = 9 | trace:key:X11DRV_KeyEvent keycode 0x9 converted to vkey 0x1b | trace:key:X11DRV_KeyEvent bScan = 0x01. | 000b:Call user32.SendInput(00000001,406ce7bc,0000001c) ret=40d9cf6a | trace:key:queue_kbd_event wParam=001b, lParam=c0010001, InputKeyState=1 | 000b:Ret user32.SendInput() retval=00000001 ret=40d9cf6a The keyup message is queued. | trace:msg:MSG_peek_message got type 7 msg 101 (WM_KEYUP) hwnd 0x1006f wp 1b lp c0010001 | trace:key:TranslateMessage (WM_KEYUP, 001B, C0010001) | trace:message:SPY_EnterMessage (0x1006f) L"&Ja" message [0101] WM_KEYUP dispatched wp=0000001b lp=c0010001 | 000b:Call window proc 0x40711b20 (hwnd=0x1006f,msg=WM_KEYUP,wp=0000001b,lp=c0010001) | 000b:Ret window proc 0x40711b20 (hwnd=0x1006f,msg=WM_KEYUP,wp=0000001b,lp=c0010001) retval=00000000 | trace:message:SPY_ExitMessage (0x1006f) L"&Ja" message [0101] WM_KEYUP returned 00000000 and is picked up and processed by the message box without much happening | trace:msg:MSG_peek_message got type 7 msg 100 (WM_KEYDOWN) hwnd 0x1006f wp 1b lp 10001 This is the riddle: the next message found is a escape-key down message. | 000b:Ret x11drv.DestroyWindow() retval=00000001 ret=4076df8b Of course it closes the message box. | 000b:Ret user32.MessageBoxA() retval=00000002 ret=0066e78c Message box finished | 000b:Ret hook proc 0x5fa990 (id=WH_KEYBOARD,code=0,wp=0000001b,lp=00010001) retval=00000001 hook returns | trace:msg:MSG_peek_message dropping msg 100 | trace:msg:MSG_peek_message got type 6 msg 0 (WM_NULL) hwnd 0x10026 wp 0 lp 0 | 000b:Ret user32.GetMessageA() retval=00000001 ret=005e1c89 and the Getmessage is finished. Suggestions? An unedited version of the log above is on http://www.xs4all.nl/~rklazes/temp/agkey.log.bz2 Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

Re: removed problem with OpenGL extensions under X11
by Lionel Ulmer 21 Nov '03

21 Nov '03

On Thu, Nov 20, 2003 at 11:50:13PM +0100, Daniel Skorka wrote: > This patch fixes a problem with bad OpenGL libraries wich uncorrectly > report the Extensions they support. Those libs would incorrectly report > not supporting glXGetProcAddresARB, on which wine relies for OpenGL > extension support. The problem was noticed with libGL from XFree86 4.2 > under Linux x86. Well, this poses the question : what should we do regarding broken libraries Wine depends upon ? Add 'incorrect' code in Wine (although in this case, it's not THAT incorrect :-) ) or report the bug to the library maintainers and wait for them to fix the issue ? Note that according to some DRI maintainer 'I had forgotten that the old libGL was that broken' :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 3

building wine docs
by Ivan Leo Murray-Smith 21 Nov '03

21 Nov '03

Hi list, how can I build the wine docs in different little files (index.html, wine-stats.html and so on, like the docs for download on the web site) instead of one big file? make doc generates one big file, but this isn't what I want. Ivan.

3 2

[OT] HOWTO use unnamed KRun objects ?
by Subhobroto Sinha 21 Nov '03

21 Nov '03

I thought a simple 'KRun(KURL("SomeBinaryFilename"))' should work, but it doesn't ? (I get ld telling me that there was an undefined reference to KRun::KRun(const KURL&...) !) Please tell me/redirect me(just make sure that the reference is working!) to an example where I can use KRun in such a manner, because KDE3API really does not come with sample code to help the uninitiated. I really just want to open files with their bound apps through my program, for ex: A KRun("Page.html") should open the 'Page.html' in Konqueror Thanks for letting me bug you ;) Regards Subhobroto Sinha __________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree

1 0

Visuals and GL contexts
by Jason Edmeades 21 Nov '03

21 Nov '03

Hello, I've finally pinned down a problem (with help from Lucho) to do with blending and its back to the same old problem that by the time D3D8 gets initialized, the windows has already been created, but the properties of the visual are insufficient to handle the requirements of D3D. In my case for example by default, the visual used for my windows has double buffering, but no alpha channel. X11DRV process attach has some code which allows control over the visual created, but this is before we know what is going to be required, and this only gets called if DesktopDoubleBuffer is set to Y. In my case, I need an alpha channel on the back buffer. By default, I havent got one. I can add code into the X11DRV_setup_opengl_visual to ask for an 8 bit alpha and everything works perfectly. So.... 1. Should I add a new config option (something like RequireAlphaChannel) - FWIW I hate this idea 2. Is it ever going to be possible to replace a wine Xwindows visual? What is involved in doing this? This is the 'perfect' solution. 3. Can I default double buffering and alpha on regardless and remove the doublebuffering property. How does this affect non game apps? We need to resolve this to ever support games properly without lots of config options Jason

3 2

Default handler for OLE interface
by olivier evalet 21 Nov '03

21 Nov '03

Hello, I'm looking to create a default handler for these interfaces: - IStorage - IOleInPlaceFrame not - IOleClientSite - IOleInPlaceSite not - IOleContainer not The reason of this... I just want to display an OLE component without binding with the native atl.dll. I have found a pure win32 example to implement this. So, If I want to use a "null" IStorage default handler, does there already exist or I must implement it? As I can see in the source code, OLE is really hard for my head. Regards, Olivier

2 2

FreeBSD Compilation Issue
by FLRBA Web Master 21 Nov '03

21 Nov '03

I acquired wine from source (version 20031118) just this morning, and I ran into some issues with an error stopping make in /dll/glu32/, the last few lines of the output: ------//------ rm -f libwine_unicode.so.1 && ln -s unicode/libwine_unicode.so.1 libwine_unicode .so.1 gcc -shared -Wl,-Bsymbolic,-z,defs glu32.spec.o glu.o glu32.dll.dbg.o -o glu 32.dll.so -L../../libs/wine -lwine -L/usr/X11R6/lib -lSM -lICE -lXxf86dga -lXxf 86vm -lXrandr -lXrender -lXv -lXext -lX11 -lGL -lGLU -L../../libs/port -lwine_p ort -lm -lc *** Error code 1 Stop in /usr/home/dan/wine/dlls/glu32. *** Error code 1 Stop in /usr/home/dan/wine/dlls. *** Error code 1 Stop in /usr/home/dan/wine. Compilation failed, aborting install. ------//------ - I am running FreeBSD 4.8-RELEASE #1 - I can compile and run wine via the ports tree but I want to be able to use the latest CVS for development purposes. A couple of things I am wondering about. 1) The error I am getting is not coming with a whole lot of information, is there a way for me to generate a more specific error message? 2) I am not expecting this problem to necessarily be solved by someone else for me unless this is a common problem (where a link to relevant information would be nice), but instead do you have any pointers on debugging/fixing this? I don't mind doing the work to get it working. I am just beginning to work with Wine and hope that I might be able to contribute something to the project and I figure making compilation on FreeBSD as seamless as possible is a good place to start. Thanks for your assistance, -Dan-

1 0

Re: imagehlp: add ImageRvaToSection() and ImageRvaToVa()
by Dmitry Timoshkov 21 Nov '03

21 Nov '03

"Marcus R. Brown" <mrbrown(a)0xd6.org> wrote: > * dlls/imagehlp/access.c: > Marcus R. Brown <mrbrown(a)0xd6.org> > Implement ImageRvaToSection() and ImageRvaToVa(). Why not simply forward them to ntdll where the real implementation resides instead of duplicating code? -- Dmitry.

1 0

include files
by Martin Fuchs 21 Nov '03

21 Nov '03

[Ralf Juengling] > > What is the status of the include files in msvcrt? [Alexandre Julliard] > They should work just fine. Make sure you also import msvcrt if you > use the headers. [Ralf Juengling] > > So my solution to make it compile was to remove wine's > > 'math.h'. That's why I would say the include files are > > incomplete. How do other people deal with a case like the > > one I described? [Alexandre Julliard] > By submitting a patch to add the missing definitions <g> Well, but you did not accept my patch as it declares the functions at the wrong location. I didn't yet have the time looking in it deeper. So you agree, they do not "work just fine". There are missing lots of declarations in msvcrt headers: at least math, and string functions. Martin

1 0

Re: Patch of wine/dlls/ntdll/path.c
by Thomas Mertes 21 Nov '03

21 Nov '03

Ok, my fault. There is no error in the patch of wine/dlls/ntdll/path.c which was checked in. The patch has the line + if (!newname) RtlFreeHeap(GetProcessHeap(), 0, name); instead of that I read + if (newname) RtlFreeHeap(GetProcessHeap(), 0, name); which changes the meaning from If the RtlReAllocateHeap fails, release the memory of name and set name to NULL. to If the RtlReAllocateHeap succeeds, throw the memory of name away. Which looks like somebody did not understand RtlReAllocateHeap. The only one who did not understand, was me. I apologize Thomas Mertes -- NEU F�R ALLE - GMX MediaCenter - f�r Fotos, Musik, Dateien... Fotoalbum, File Sharing, MMS, Multimedia-Gru�, GMX FotoService Jetzt kostenlos anmelden unter http://www.gmx.net +++ GMX - die erste Adresse f�r Mail, Message, More! +++

1 0

Re: Patch to add glut32.dll.
by Lionel Ulmer 21 Nov '03

21 Nov '03

Jacek, It seems your patch was line-wrapped (which is not a good thing). Moreover, it's not necessary to add the patch against 'configure', you just need to tell Alexandre in the patch mail that he needs to re-generate it himself when comitting. Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Compiler problems
by Marcelo Duarte 21 Nov '03

21 Nov '03

Updating wine to current cvs, I get an error, can someone help me: I run ./configure; make depend && make make[2]: Entering directory `/home/mduarte/wine-cvs/dlls/winmm/winearts' gcc -shared -Wl,-Bsymbolic,-z,defs winearts.drv.spec.o arts.o audio.o winearts.drv.dbg.o -o winearts.drv.so -L../../../libs/wine -lwine -L/usr/lib/kde3/lib -ldl -lartsc -lpthread -L../../../libs/uuid -lwine_uuid -L../../../libs/port -lwine_port -lm -lc /usr/bin/ld: cannot find /usr/lib/libpthread_nonshared.a collect2: ld returned 1 exit status make[2]: ** [winearts.drv.so] Erro 1 make[2]: Leaving directory `/home/mduarte/wine-cvs/dlls/winmm/winearts' make[1]: ** [winmm/winearts] Erro 2 make[1]: Leaving directory `/home/mduarte/wine-cvs/dlls' make: ** [dlls] Erro 2 Entering in directory loader and make: [mduarte@mduarte loader]$ make clean rm -f *.o *.a *.so *.ln *.so \#*\# *~ *% .\#* *.bak *.orig *.rej *.flc *.spec.c *.spec.def *.dbg.c y.tab.c y.tab.h lex.yy.c core rm -f wine-glibc wine-kthread wine-pthread wine [mduarte@mduarte loader]$ make gcc -c -I. -I. -I../include -I../include -Wall -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o glibc.o glibc.c gcc -o wine-glibc -Wl,--section-start,.interp=0x3c000100 -Wl,--export-dynamic glibc.o -L../libs/wine -lwine -L../libs/port -lwine_port glibc.o(.text+0x84): In function `get_threading': /home/mduarte/wine-cvs/loader/glibc.c:61: undefined reference to `pthread_create' glibc.o(.text+0x90):/home/mduarte/wine-cvs/loader/glibc.c:62: undefined reference to `pthread_join' collect2: ld returned 1 exit status make: ** [wine-glibc] Erro 1 -- Marcelo Duarte

1 1

Compiling winearts - please replay!
by Marcelo Duarte 21 Nov '03

21 Nov '03

I updated to new wine version and had errors, cvs update, and errors persists: make[2]: Entering directory `/home/mduarte/wine-20031118/dlls/winmm/winearts' gcc -shared -Wl,-Bsymbolic,-z,defs winearts.drv.spec.o arts.o audio.o winearts.drv.dbg.o -o winearts.drv.so -L../../../libs/wine -lwine -L/usr/lib/kde3/lib -ldl -lartsc -lpthread -L../../../libs/uuid -lwine_uuid -L../../../libs/port -lwine_port -lm -lc /usr/bin/ld: cannot find /usr/lib/libpthread_nonshared.a collect2: ld returned 1 exit status make[2]: ** [winearts.drv.so] Erro 1 make[2]: Leaving directory `/home/mduarte/wine-20031118/dlls/winmm/winearts' make[1]: ** [winmm/winearts] Erro 2 make[1]: Leaving directory `/home/mduarte/wine-20031118/dlls' make: ** [dlls] Erro 2 Someone knows what is happen? -- Marcelo Duarte

1 0

help with linking needed
by Ralf Juengling 21 Nov '03

21 Nov '03

I have successfully compiled sources of a Windows application, but when starting up, it tries to locate and link to a windows dll to access some C library functions: ... err:module:import_dll No implementation for cw3230.DLL._strlen imported from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", setting to 0xdeadbeef err:module:import_dll No implementation for cw3230.DLL._strncpy imported from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", setting to 0xdeadbeef err:module:import_dll No implementation for cw3230.DLL._strtok imported from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", setting to 0xdeadbeef err:module:import_dll No implementation for cw3230.DLL._tolower imported from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", setting to 0xdeadbeef err:module:import_dll No implementation for cw3230.DLL._toupper imported from L"Z:\\local\\builts\\phaeaco-20031119\\src\\memview\\memview.exe", setting to 0xdeadbeef err:module:LdrInitializeThunk Main exe initialization failed, status c0000135 First of all: Where does the name "cw3230.DLL" come from -- Wine didn't install such a dll on my system? Second, all these functions seem to be C library functions and I want to link against the library available on my linux system. So I added 'c' to LIBRARIES in the Makefile.in created by winemaker. But this didn't make any difference. I hope somebody can introduce me to secrets of simultaneously linking against Winelib & Unix dynamic libraries.. Ralf -- Ralf Juengling <juenglin(a)cse.ogi.edu>

1 0

Re: regedt: fix couple of HeapReAlloc()s
by Steven Edwards 21 Nov '03

21 Nov '03

I think HeapReAlloc problem exists in the listbox control. We have a patch in ReactOS CVS for it but I dont have time to try and merge it. Thanks Steven --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > ChangeLog > HeapReAlloc() does not allocate memory. > > Index: programs/regedit/regproc.c __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/

2 1

include files
by Ralf Juengling 21 Nov '03

21 Nov '03

A Makefile created by winemake & configure adds /whereever/include/wine/windows to the include paths. Why doesn't it also add /whereever/include/wine/msvcrt ? What is the status of the include files in msvcrt? Ralf -- Ralf Juengling <juenglin(a)cse.ogi.edu>

3 5

Re: _end Symbol and Mac OS X
by Alexandre Julliard 21 Nov '03

21 Nov '03

"Pierre d'Herbemont" <stegefin(a)free.fr> writes: > On Mac OS X There is no _end symbol. There is a convenience function > get_end() to replace it, mainly because of the Mach-O file format. So > we have to get the value of get_end at launch time and store it in the > nt_header. Does get_end really return the _end value of the current library? I suspect it returns the value for the main executable in all cases, which is not what we need here. -- Alexandre Julliard julliard(a)winehq.com

2 2

Windows programs no more running with the new wine-glibc
by Sylvain Petreolle 20 Nov '03

20 Nov '03

With yesterday cvs update, whch adds a glibc-threading detection, wine doesnt load a _Windows_ program anymore. Using the RedHat rpm Yarrow kernel, I get : err:virtual:map_image Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load L"C:\\arakas.exe" as Win32 binary Funny thing : If I set up a symlink to the wine-glibc in another directory, it works without problems. [syl@wine c]$ ls -l /usr/local/bin/wine /home/wine/loader/wine-* -rwxr-xr-x 1 syl wine 97265 nov 13 20:08 /home/wine/loader/wine-glibc -rwxr-xr-x 1 syl wine 156037 nov 13 20:08 /home/wine/loader/wine-kthread -rwxr-xr-x 1 syl wine 109482 nov 13 20:08 /home/wine/loader/wine-pthread -rwxr-xr-x 1 root root 97265 nov 13 20:29 /usr/local/bin/wine With plain binary, not working : [syl@wine c]$ which wine /usr/local/bin/wine [syl@wine c]$ wine arakas.exe err:virtual:map_image Standard load address for a Win32 program (0x00400000) not available - security-patched kernel ? wine: could not load L"C:\\arakas.exe" as Win32 binary With the symlink : [syl@wine c]$ ls -l /c/wine lrwxrwxrwx 1 syl wine 28 nov 13 20:41 /c/wine -> /home/wine/loader/wine-glibc [syl@wine c]$ ./wine arakas.exe fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (French keyboard layout) for scancode mapping. Please define your layout in dlls/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. Any thoughts ? ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

5 13

removed problem with OpenGL extensions under X11
by Daniel Skorka 20 Nov '03

20 Nov '03

This patch fixes a problem with bad OpenGL libraries wich uncorrectly report the Extensions they support. Those libs would incorrectly report not supporting glXGetProcAddresARB, on which wine relies for OpenGL extension support. The problem was noticed with libGL from XFree86 4.2 under Linux x86. ChangeLog: * dlls/opengl32/wgl.c: Daniel Skorka <skorka(a)gmx.net> Fixed a problem using glXGetProcAddresARB with bad OpenGL libs. ---snip--- ? patch.diff ? miscemu/Makefile Index: dlls/opengl32/wgl.c =================================================================== RCS file: /home/wine/wine/dlls/opengl32/wgl.c,v retrieving revision 1.39 diff -u -u -r1.39 wgl.c --- dlls/opengl32/wgl.c 17 Sep 2003 20:04:25 -0000 1.39 +++ dlls/opengl32/wgl.c 20 Nov 2003 22:33:51 -0000 @@ -671,12 +671,12 @@ XFree(vis); LEAVE_GL(); - if ((extensions != NULL) && (strstr(extensions, "GLX_ARB_get_proc_address"))) { - opengl_handle = wine_dlopen(SONAME_LIBGL, RTLD_NOW|RTLD_GLOBAL, NULL, 0); - if (opengl_handle != NULL) { - p_glXGetProcAddressARB = wine_dlsym(opengl_handle, "glXGetProcAddressARB", NULL, 0); - wine_dlclose(opengl_handle, NULL, 0); - } + opengl_handle = wine_dlopen(SONAME_LIBGL, RTLD_NOW|RTLD_GLOBAL, NULL, 0); + if (opengl_handle != NULL) { + p_glXGetProcAddressARB = wine_dlsym(opengl_handle, "glXGetProcAddressARB", NULL, 0); + wine_dlclose(opengl_handle, NULL, 0); + if (p_glXGetProcAddressARB == NULL) + TRACE("could not find glXGetProcAddressARB in libGL.\n"); } if (default_cx == NULL) { ---snip---

1 1

Re: wineps: fix a few HeapReAlloc()s
by Huw D M Davies 20 Nov '03

20 Nov '03

On Thu, Nov 20, 2003 at 03:33:48PM -0500, Dimitrie O. Paun wrote: > Huw, > I didn't dig deep enough to see if glyphList/->glyph_sent > can't be NULL at that point, but it wasn't obvious to me > that they can't. You know this part a lot better than myself, > can you please check that I'm not adding extranous uglifying > bits to the code? Hi Dimi, All of these are unnecessary afaics. glyphList gets alloc'ed in GlyphListInit and the two glyph_sent's are alloc'ed in T{1|42}_download_header Huw.

2 1

[624] Agent 2.0 Beta Dialog crashes
by Gerhard W. Gruber 20 Nov '03

20 Nov '03

When I download newsgroup articles and I selecte any article in any newsgroup, then right-click and choose Index from the context menu, Agent crashes. This works under Windows, so this is a Wine problem. Maybe it will crash also when not downloading, just to open that dialog. I haven't tried this yet, but I would bet this is the case. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://sourceforge.net/projects/pice Fast application launcher - http://sourceforge.net/projects/launchmenu

2 2

Re: rpcrt4: fix NULL pointer access
by Gregory M. Turner 20 Nov '03

20 Nov '03

On Thursday 20 November 2003 02:26 pm, Dimitrie O. Paun wrote: > Ran into this while browsing the code, it seems to > be a NULL pointer reference waiting to happen. > Am I missing something? > > ChangeLog > Bail when we're out of memory. > > Index: dlls/rpcrt4/rpc_binding.c > =================================================================== > RCS file: /var/cvs/wine/dlls/rpcrt4/rpc_binding.c,v > retrieving revision 1.15 > diff -u -r1.15 rpc_binding.c > --- dlls/rpcrt4/rpc_binding.c 7 Oct 2003 22:54:17 -0000 1.15 > +++ dlls/rpcrt4/rpc_binding.c 20 Nov 2003 06:33:52 -0000 > @@ -516,7 +516,11 @@ > { > DWORD len = strlen(dst), slen = strlen(src); > LPSTR ndst = HeapReAlloc(GetProcessHeap(), 0, dst, > (len+slen+2)*sizeof(CHAR)); - if (!ndst) HeapFree(GetProcessHeap(), 0, > dst); > + if (!ndst) > + { > + HeapFree(GetProcessHeap(), 0, dst); > + return NULL; > + } > ndst[len] = ','; > memcpy(ndst+len+1, src, slen*sizeof(CHAR)); > ndst[len+slen+1] = 0; > @@ -527,7 +531,11 @@ > { > DWORD len = strlenW(dst), slen = strlenW(src); > LPWSTR ndst = HeapReAlloc(GetProcessHeap(), 0, dst, > (len+slen+2)*sizeof(WCHAR)); - if (!ndst) HeapFree(GetProcessHeap(), 0, > dst); > + if (!ndst) > + { > + HeapFree(GetProcessHeap(), 0, dst); > + return NULL; > + } > ndst[len] = ','; > memcpy(ndst+len+1, src, slen*sizeof(WCHAR)); > ndst[len+slen+1] = 0; looks like a real bug to me... but the consumers of those functions probably assume success, so maybe the right solution is really to raise an exception. There are lots of places in rpcrt4 where exceptions ought to raise on error conditions but don't, mainly due to developer laziness. I guess it's hard to justify fixing error paths when success doesn't work either ;) So, at some point there needs to be an error-handling audit of rpcrt4; until then, your patch is better than nothing, and probably should go in. -- gmt "It is to be the assent and ratification of the several States, derived from the supreme authority in each State, the authority of the people themselves. The act, therefore, establishing the Constitution, will not be a NATIONAL, but a FEDERAL act." --James Madison, Federalist No. 39

1 0

Re: WineX relation to Wine
by Gerhard W. Gruber 20 Nov '03

20 Nov '03

On Thu, 20 Nov 2003 15:17:22 -0500, "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: [LaunchMenu Windowsversion under Wine] >> Are hooks supported under Wine? > >What do you need? I just tried it under Wine. the dialog and everything works, but the hook doesn't respond. I would have to debug it to see whats not working, but I guess that it is the hookfunction. When the hook couldn't be installed I raise a dialog and this does not appear, so the the CreateHook appears to return something. I don't see any errormessages from wine, though. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://sourceforge.net/projects/pice Fast application launcher - http://sourceforge.net/projects/launchmenu

1 0

Further loader/pthread.c issues
by Gerald Pfeifer 20 Nov '03

20 Nov '03

After last night's changes to loader/pthread.c,v revision 1.2 date: 2003/11/09 01:25:23; author: julliard; state: Exp; lines: +67 -11 Moved the remaining SYSDEPS_* functions to the wine_pthread interface. Let the pthread library allocate the stack itself. we have a new portability problem, namely wine/loader/pthread.c:97: undefined reference to `pthread_getattr_np' Given that loader/pthread.c is about POSIX threads, is it really correct/good to use a non-POSIX function? Gerald PS: On FreeBSD, pthread_getattr_np does not exist, but there is a function pthread_attr_get_np which seems to be equivalent. On Solaris, neither seems to exist.

3 4

Re: Reject wildcards in directory names
by Alexandre Julliard 20 Nov '03

20 Nov '03

Hans Leidekker <hans(a)it.vu.nl> writes: > Changelog: > - Reject wildcards in directory names There's no need to check in both A and W functions since the A one calls the W one anyway. Also you should only check the part of the filename that is actually being created, and there are probably other invalid characters to check for too. -- Alexandre Julliard julliard(a)winehq.com

2 2

Redrawing windows
by flyker 20 Nov '03

20 Nov '03

I made some experiments and I understand one thing. Exaple two windows /-------------------\ | W1 | | control1 | | | | /------------------------\ \------------- | | | | | | -----------> Move | W2 | | | \------------------------/ The window W1 is under window W2 When I move window W2 wine paint all rect of W1 window ! And it may hide control1 that inside area of W1. It is not good idea because not all rect of window need to repaint. Good idea is repaint only the part of W1 that under W2. Only rect that have any changes on screen. It will increase speed of drawing windows. But may be I mistake......

1 0

How to speed up drawing controls ?
by flyker 20 Nov '03

20 Nov '03

The drawing speed of window controls and windows is very slow under wine. I set option "PerfectGraphics" = "Y" but it is still slow. May be it is not so good optimised ? Is there other way to improve performance ? Thanks.

2 1

Does wine supports database applications
by saravanan 20 Nov '03

20 Nov '03

Hai all, I would like to know is it possible to run a Windows database application in linux using wine. For eg. How can I run a VB application which uses MS Access as backend in linux. Does wine supports MDB files. I could only run stand alone windows applications in linux using wine. Does wine supports database applications. Thanks in advance for your reply. Saravanan ______________________________________ Scanned and protected by Email scanner

1 0

QuickTime Installer/Remote Display
by Kevin Cousins 19 Nov '03

19 Nov '03

Hello, Given that I've got a situation in which my WineLib application (thank you for your help earlier in the year) needs to run against the Win32 QuickTime components, then in my development environment (RH9), I can quite happily run the downloaded QuickTime installer QuickTimeInstaller.exe to completion (so long as I have [AppDefaults\\QuickTimeInstaller.exe\\x11drv] "Managed" = "Y" "Desktop" = "800x600" ) and all is well. Running all this, however, in a test environment (RH8 under VMWare), and the QuickTimeInstaller.exe does not run to completion. I can make "wineserver -d3" and "wine -debugmsg +all" output available on private request. Can anyone suggest a mechanism for a problem here, or even an approach to a solution? -- Kevin.

1 2

out of treee builds broken
by Marcus Meissner 19 Nov '03

19 Nov '03

Hi, Out of tree builds are broken due to the authors.c generation: ../../tools/winebuild/winebuild -D__WINESRC__ -D_SHELL32_ -DCOM_NO_WINDOWS_H -o shell32.dll.dbg.c --debug -C/suse/meissner/projects/marcus-wine-20031016/dlls/shell32 authors.c brsfolder.c changenotify.c classes.c clipboard.c control.c dataobject.c debughlp.c dialogs.c dragdrophelper.c enumidlist.c folders.c iconcache.c memorystream.c pidl.c regsvr.c shell32_main.c shelllink.c shellole.c shellord.c shellpath.c shellreg.c shellstring.c shfldr_desktop.c shfldr_fs.c shfldr_mycomp.c shlexec.c shlfileop.c shlfolder.c shlfsbind.c shlmenu.c shlview.c shpolicy.c shv_bg_cmenu.c shv_item_cmenu.c systray.c shell.c Cannot open file '/suse/meissner/projects/marcus-wine-20031016/dlls/shell32/authors.c' It looks for authors.c in the srcdir, not in the objdir. Ciao, Marcus

2 2

question new to the group
by Nathan Hack 19 Nov '03

19 Nov '03

Ok here's the deal. I wanted to start helping but i've been reading the auncments and stuff but i did see this topic come up. So i thought i would just through it out and see what the wine community had to say. I have build a few (simple)delphi programs test wine out to start working on it(wine that is). fixme:commctrl:FlatSB_SetScrollProp stub ok my question is this since this API is no longer in windows ( Comctl32.dll version 6 and higher do not support flat scroll bars) show i go ahead and write in the code or just go find something else more productive? If this is a stupid question just let me know like( hey it's in the doc's on wine and heres the web site.... ) that would be great. Thanks, -NH -Better living through Wine-

5 4

using glXGetProcAddressARB
by Daniel Skorka 19 Nov '03

19 Nov '03

Hi! I am having trouble with OpenGL under wine (specifically Half-Life). The problem is some code in $(TOPDIR)/dlls/opengl32/wgl.c. The function wglGetProcAddress would like to call glXGetProcAddressARB, but can't, due to the DLL's initialisation routines, namely process_attach. process_attach calls glxQueryExtensionsString, and expects to find "GLX_ARB_get_proc_address" in the returned string. However, it does not find this string on my libGL and so deems that glXGetProcAddressARB is not available. The problem is that glXGetProcAddress is available and working. The question I'm asking me now is: Is it a bug in my libGL because it is returning a wrong string, or is it a bug in wine because it is expecting something it shouldn't (there's a configure check for glXGetProcAddress as well)? I'm running Debian 3.0r1 with an libGL built (not by me), from the dri-mach64 CVS and using the wine CVS source. Thank you for your help with this, Daniel

3 5

Another driver wrapper
by Uwe Bonnes 19 Nov '03

19 Nov '03

http://sourceforge.net/projects/ndiswrapper/ is another wrapper for windows drivers, this time GPL. Can this be of help for us? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Re: [ros-kernel] suggestion regarding d3d8thk (and directx in general)
by Jonathan Wilson 19 Nov '03

19 Nov '03

Personally, I would like to see Transgaming release all the code that they have that is not copy-protection and is not directx under a true open-source licence. In particular, any enhancements (whatever they may be) to OLE and COM. I think that Transgaming, WineHQ, Codeweavers and ReactOS should work together to produce one definitive clone of Microsofts OLE and COM libraries incorperating all the reverse engineering, code hacking and so on necessary to clone these key windows components. ReactOS benifits in that they get the OLE support needed to make lots of modern stuff run. WINE benifits in that people wont need to install dcom98 anymore to get usable OLE libraries (which is probobly illegal under the dcom98 licence anyhow). And Codeweavers and Transgaming benifit in that the apps/games they support all use OLE and COM.

2 1

Re: config.diff
by Marcus Meissner 19 Nov '03

19 Nov '03

On Tue, Nov 18, 2003 at 11:39:30PM -0500, Tom wrote: > > Hi, > > Tom > > Changelog > > updates to the config file --- config 16 Oct 2003 19:09:57 -0000 1.52 +++ config 19 Nov 2003 06:32:54 -0000 ... -"Path" = "/c" +"Path" = "${HOME}/c" ... Will break. ... -"Path" = "%HOME%" +"Path" = "${HOME}" ... Same here. Ciao, Marcus

1 0

Map and Guide & ADO
by Olaf Leidinger 18 Nov '03

18 Nov '03

Hello! I'm trying to run MAP and Guide 9.0, but it needs ADO V.2.5 So I tried to install mdac from Microsoft, but both version 2.5 and 2.6 crash before installing anything. I've extracted the cabs and installed everything, but it would be cool to have the registry entries added by the installer, so that M&G knows, that ADO is there. Does anybody have an idea of what to do? Ciao, Olaf Information follows: fake_windows with working IE 5.5 wine 20031016. mdac_type v. 2.5 trace:loaddll:load_dll Loaded module L"ADVAPI32.dll" : builtin trace:loaddll:load_dll Loaded module L"GDI32.dll" : builtin trace:loaddll:load_dll Loaded module L"USER32.dll" : builtin trace:loaddll:load_dll Loaded module L"C:\\WINDOWS\\SYSTEM\\COMCTL32.dll" : builtin trace:loaddll:load_dll Loaded module L"x11drv.dll" : builtin trace:loaddll:load_dll Loaded module L"C:\\Program Files\\mg9\\prog\\IXP026.TMP\\dasetupr.dll" : native trace:loaddll:load_dll Loaded module L"C:\\WINDOWS\\SYSTEM\\ole32.dll" : native trace:loaddll:load_dll Loaded module L"lz32.dll" : builtin trace:loaddll:load_dll Loaded module L"VERSION.dll" : builtin trace:loaddll:load_dll Loaded module L"C:\\Program Files\\mg9\\prog\\IXP026.TMP\\advpack.dll" : native trace:loaddll:load_dll Loaded module L"C:\\Program Files\\mg9\\prog\\IXP026.TMP\\CABINET.DLL" : native trace:loaddll:MODULE_FlushModrefs Unloaded module L"C:\\Program Files\\mg9\\prog\\IXP026.TMP\\CABINET.DLL" : native trace:loaddll:load_dll Loaded module L"C:\\WINDOWS\\SYSTEM\\shlwapi.dll" : builtin trace:loaddll:load_dll Loaded module L"C:\\WINDOWS\\SYSTEM\\SHELL32.dll" : builtin trace:loaddll:load_dll Loaded module L"C:\\WINDOWS\\SYSTEM\\winspool.drv" : builtin trace:loaddll:load_dll Loaded module L"C:\\WINDOWS\\SYSTEM\\comdlg32.dll" : builtin trace:loaddll:load_dll Loaded module L"C:\\Program Files\\mg9\\prog\\IXP026.TMP\\CFGMGR32.dll" : native trace:loaddll:load_dll Loaded module L"MPR.dll" : builtin trace:loaddll:load_dll Loaded module L"C:\\WINDOWS\\SYSTEM\\RPCRT4.dll" : nativetrace:loaddll:load_dll Loaded module L"C:\\Program Files\\mg9\\prog\\IXP026.TMP\\SETUPAPI.DLL" : native trace:loaddll:MODULE_FlushModrefs Unloaded module L"C:\\Program Files\\mg9\\prog\\IXP026.TMP\\SETUPAPI.DLL" : native trace:loaddll:MODULE_FlushModrefs Unloaded module L"C:\\WINDOWS\\SYSTEM\\RPCRT4.dll" : native trace:loaddll:MODULE_FlushModrefs Unloaded module L"C:\\WINDOWS\\SYSTEM\\mpr.dll" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"C:\\Program Files\\mg9\\prog\\IXP026.TMP\\CFGMGR32.dll" : native trace:loaddll:MODULE_FlushModrefs Unloaded module L"C:\\WINDOWS\\SYSTEM\\comdlg32.dll" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"C:\\WINDOWS\\SYSTEM\\winspool.drv" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"C:\\WINDOWS\\SYSTEM\\shell32.dll" : builtin trace:loaddll:MODULE_FlushModrefs Unloaded module L"C:\\WINDOWS\\SYSTEM\\shlwapi.dll" : builtin trace:loaddll:load_dll Loaded module L"C:\\Program Files\\mg9\\prog\\IXP026.TMP\\CABINET.DLL" : native trace:loaddll:MODULE_FlushModrefs Unloaded module L"C:\\Program Files\\mg9\\prog\\IXP026.TMP\\CABINET.DLL" : native wine: Unhandled exception (thread 000b), starting debugger... trace:loaddll:load_dll Loaded module L"advapi32.dll" : builtin WineDbg starting on pid a No debug information in ELF 'wine' ((nil)) Breakpoint 1 at 0x492591a0 No debug information in ELF '/usr/lib/wine/lib/libwine.so.1' (0x40001000) Loaded debug information from ELF '/usr/lib/wine/lib/wine/ntdll.dll.so' (0x40019000) No debug information in ELF '/usr/lib/wine/lib/libwine_unicode.so.1' (0x40083000) No debug information in ELF '/lib/libnss_compat.so.2' (0x40191000) Loaded debug information from ELF '/usr/lib/wine/lib/wine/kernel32.dll.so' (0x402b0000) Loaded debug information from ELF '/usr/lib/wine/lib/wine/advapi32.dll.so' (0x40813000) Loaded debug information from ELF '/usr/lib/wine/lib/wine/gdi32.dll.so' (0x40842000) Loaded debug information from ELF '/usr/lib/wine/lib/wine/user32.dll.so' (0x408be000) Loaded debug information from ELF '/usr/lib/wine/lib/wine/comctl32.dll.so' (0x409fb000) Loaded debug information from ELF '/usr/lib/wine/lib/wine/x11drv.dll.so' (0x40aa2000) No debug information in ELF '/usr/lib/libGL.so.1' (0x40b1f000) No debug information in ELF '/usr/lib/libGLcore.so.1' (0x40b88000) *** Invalid address 0xf6cc6000 (_end+0xb61c05d0) No debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/xlcDef.so.2' (0x4018b000) No debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2' (0x410fd000) No debug information in ELF '/usr/lib/gconv/ISO8859-15.so' (0x4018e000) Loaded debug information from ELF '/usr/lib/wine/lib/wine/version.dll.so' (0x41790000) Loaded debug information from ELF '/usr/lib/wine/lib/wine/lz32.dll.so' (0x40b06000) Loaded debug information from ELF '/usr/lib/wine/lib/wine/setupx.dll.so' (0x41c3a000) No debug information in ELF '/lib/libnss_files.so.2' (0x41e1c000) No debug information in 32bit DLL 'C:\Program Files\mg9\prog\IXP026.TMP\dasetup.exe' (0x1000000) No debug information in 32bit DLL 'NTDLL.DLL' (0x40030000) No debug information in 32bit DLL 'KERNEL32.DLL' (0x402e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x40820000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x40860000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x408e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMCTL32.DLL' (0x40a10000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40ab0000) No debug information in 32bit DLL 'C:\PROGRAM FILES\MG9\PROG\IXP026.TMP\DASETUPR.DLL' (0x400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x65f00000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\LZ32.DLL' (0x40b10000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\VERSION.DLL' (0x417a0000) No debug information in 32bit DLL 'C:\PROGRAM FILES\MG9\PROG\IXP026.TMP\ADVPACK.DLL' (0x70e90000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SETUPAPI.DLL' (0x41c50000) Unhandled exception: privileged instruction in 32-bit code (0x493458ed). In 32-bit mode. 0x493458ed (NTDLL.DLL.memcpy+0x67d8d): movl %gs:0x418,%eax First chance exception: privileged instruction in 32-bit code (0x493458ed). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:14d7 EIP:493458ed ESP:40804de8 EBP:40804dec EFLAGS:00210302( R- 00 IT - - 1 ) EAX:00000001 EBX:49389de0 ECX:49494854 EDX:00002014 ESI:00002014 EDI:00000000 Stack dump: 0x40804de8 (_end+0x44a1dc): 49389de0 4080543c 492aca1c 00002014 0x40804df8 (_end+0x44a1ec): 49494851 00000000 00000000 00000000 0x40804e08 (_end+0x44a1fc): 00000000 00000000 00000000 00000000 0x40804e18 (_end+0x44a20c): 00000000 00000000 00000000 00000000 0x40804e28 (_end+0x44a21c): 00000000 49494852 40804fdc 00000000 0x40804e38 (_end+0x44a22c): 492af4e5 4080541c 00000000 00000000 0x40804e48 (_end+0x44a23c): 0011: sel=008f base=400812e0 limit=00000fff 32-bit rw- Backtrace: =>0 0x493458ed (NTDLL.DLL.memcpy+0x67d8d) (ebp=40804dec) 1 0x492aca1c (NTDLL.DLL.strtoul+0x1b17c) (ebp=4080543c) 2 0x492c823c (NTDLL.DLL.vsprintf+0x8c) (ebp=4080551c) 3 0x492b588d (NTDLL.DLL.sprintf+0x2d) (ebp=4080553c) 4 0x49437e36 (NTDLL.DLL.sqrt+0x9f5f6) (ebp=408095ac) 5 0x49437b7d (NTDLL.DLL.sqrt+0x9f33d) (ebp=40809dfc) 6 0x49407709 (NTDLL.DLL.sqrt+0x6eec9) (ebp=40809f3c) 7 0x494078d3 (NTDLL.DLL.sqrt+0x6f093) (ebp=40809f5c) 8 0x49407a49 (NTDLL.DLL.sqrt+0x6f209) (ebp=40809f8c) 9 0x40aebe75 (X11DRV_SetWindowText+0x245(hwnd=0x10034, text=0x402033a8) [window.c:841] in x11drv.dll.so) (ebp=40809fe4) 10 0x4092e4f6 (DEFWND_SetTextA+0x176(hwnd=0x10034, text=0x4080c32c) [defwnd.c:108] in user32.dll.so) (ebp=4080a08c) 11 0x4092ff27 (DefWindowProcA+0x187(hwnd=0x10034, msg=0xc, wParam=0x0, lParam=0x4080c32c) [defwnd.c:817] in user32.dll.so) (ebp=4080a0d8) 12 0x409207e9 (.L67+0x6d [static.c] in user32.dll.so) (ebp=4080a148) 13 0x40920cf5 (StaticWndProcA+0x65(hWnd=0x10034, uMsg=0xc, wParam=0x0, lParam=0x4080c32c) [static.c:411] in user32.dll.so) (ebp=4080a16c) 14 0x40959d6f (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=4080a190) 15 0x40959de7 (WINPROC_CallWndProc+0x67(proc=0x40920c90, hwnd=0x10034, msg=0xc, wParam=0x0, lParam=0x4080c32c) [winproc.c:229] in user32.dll.so) (ebp=4080a1c4) 16 0x409600fb (CallWindowProcA+0xeb(func=0x40920c90, hwnd=0x10034, msg=0xc, wParam=0x0, lParam=0x4080c32c) [winproc.c:2898] in user32.dll.so) (ebp=4080a1f4) 17 0x40972fd0 (call_window_proc+0x170(hwnd=0x10034, msg=0xc, wparam=0x0, lparam=0x4080c32c, unicode=0x0, same_thread=0x1) [message.c:1453] in user32.dll.so) (ebp=4080a250) 18 0x40974020 (SendMessageTimeoutA+0x240(hwnd=0x10034, msg=0xc, wparam=0x0, lparam=0x4080c32c, flags=0x0, timeout=0xffffffff, res_ptr=0x4080a2e0) [message.c:1959] in user32.dll.so) (ebp=4080a2bc) 19 0x40974102 (SendMessageA+0x52(hwnd=0x10034, msg=0xc, wparam=0x0, lparam=0x4080c32c) [message.c:2004] in user32.dll.so) (ebp=4080a2e8) 20 0x4093273c (SendDlgItemMessageA+0x4c(hwnd=0x10032, id=0x3ee, msg=0xc, wParam=0x0, lParam=0x4080c32c) [dialog.c:1139] in user32.dll.so) (ebp=4080a304) 21 0x01005e66 (dasetup.exe..text+0x4e66 in dasetup.exe) (ebp=4080e330) 22 0x010091bb (dasetup.exe..text+0x81bb in dasetup.exe) (ebp=4080e350) 23 0x40959d6f (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=4080e374) 24 0x40959de7 (WINPROC_CallWndProc+0x67(proc=0x100916f, hwnd=0x10032, msg=0x4fb, wParam=0x0, lParam=0x41298e88) [winproc.c:229] in user32.dll.so) (ebp=4080e3a8) 25 0x409600fb (CallWindowProcA+0xeb(func=0x409ea930, hwnd=0x10032, msg=0x4fb, wParam=0x0, lParam=0x41298e88) [winproc.c:2898] in user32.dll.so) (ebp=4080e3d8) 26 0x4092dec8 (DefDlgProcA+0x68(hwnd=0x10032, msg=0x4fb, wParam=0x0, lParam=0x41298e88) [defdlg.c:354] in user32.dll.so) (ebp=4080e404) 27 0x40959d6f (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=4080e428) 28 0x40959de7 (WINPROC_CallWndProc+0x67(proc=0x4092de60, hwnd=0x10032, msg=0x4fb, wParam=0x0, lParam=0x41298e88) [winproc.c:229] in user32.dll.so) (ebp=4080e45c) 29 0x4095fb68 (WINPROC_CallProc32WTo32A+0x68(func=0x4092de60, hwnd=0x10032, msg=0x4fb, wParam=0x0, lParam=0x41298e88) [winproc.c:2718] in user32.dll.so) (ebp=4080e48c) 30 0x4096020b (CallWindowProcW+0xeb(func=0x409ea4f8, hwnd=0x10032, msg=0x4fb, wParam=0x0, lParam=0x41298e88) [winproc.c:2937] in user32.dll.so) (ebp=4080e4bc) 31 0x4093dd8b (DispatchMessageW+0xbb(msg=0x4080e524) [message.c:888] in user32.dll.so) (ebp=4080e4f0) 32 0x40932411 (.L313+0x19 [dialog.c] in user32.dll.so) (ebp=4080e514) 33 0x40974e34 (IsDialogMessageA+0x64(hwndDlg=0x10021, pmsg=0x40812da0) [message.c:2395] in user32.dll.so) (ebp=4080e54c) 34 0x40a53ce1 (PROPSHEET_IsDialogMessage+0x91(hwnd=0x10021, lpMsg=0x40812da0) [propsheet.c:2709] in comctl32.dll.so) (ebp=4080e574) 35 0x40a54799 (PROPSHEET_DialogProc+0x7e9(hwnd=0x10021, uMsg=0x475, wParam=0x0, lParam=0x40812da0) [propsheet.c:3051] in comctl32.dll.so) (ebp=4080e7ac) 36 0x40959d6f (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=4080e7d0) 37 0x40959de7 (WINPROC_CallWndProc+0x67(proc=0x40a53fb0, hwnd=0x10021, msg=0x475, wParam=0x0, lParam=0x40812da0) [winproc.c:229] in user32.dll.so) (ebp=4080e804) 38 0x409600fb (CallWindowProcA+0xeb(func=0x409ea8c4, hwnd=0x10021, msg=0x475, wParam=0x0, lParam=0x40812da0) [winproc.c:2898] in user32.dll.so) (ebp=4080e834) 39 0x4092dec8 (DefDlgProcA+0x68(hwnd=0x10021, msg=0x475, wParam=0x0, lParam=0x40812da0) [defdlg.c:354] in user32.dll.so) (ebp=4080e860) 40 0x40959d6f (WINPROC_wrapper+0x17 in user32.dll.so) (ebp=4080e884) 41 0x40959de7 (WINPROC_CallWndProc+0x67(proc=0x4092de60, hwnd=0x10021, msg=0x475, wParam=0x0, lParam=0x40812da0) [winproc.c:229] in user32.dll.so) (ebp=4080e8b8) 42 0x409600fb (CallWindowProcA+0xeb(func=0x4092de60, hwnd=0x10021, msg=0x475, wParam=0x0, lParam=0x40812da0) [winproc.c:2898] in user32.dll.so) (ebp=4080e8e8) 43 0x40972fd0 (call_window_proc+0x170(hwnd=0x10021, msg=0x475, wparam=0x0, lparam=0x40812da0, unicode=0x0, same_thread=0x1) [message.c:1453] in user32.dll.so) (ebp=4080e944) 44 0x40974020 (SendMessageTimeoutA+0x240(hwnd=0x10021, msg=0x475, wparam=0x0, lparam=0x40812da0, flags=0x0, timeout=0xffffffff, res_ptr=0x4080e9d4) [message.c:1959] in user32.dll.so) (ebp=4080e9b0) 45 0x40974102 (SendMessageA+0x52(hwnd=0x10021, msg=0x475, wparam=0x0, lparam=0x40812da0) [message.c:2004] in user32.dll.so) (ebp=4080e9dc) 46 0x01005611 (dasetup.exe..text+0x4611 in dasetup.exe) (ebp=40812de0) 47 0x01009612 (dasetup.exe.EntryPoint+0x152 in dasetup.exe) (ebp=40812e6c) 48 0x400537a5 (LdrInitializeThunk+0x2b5(main_file=0x4, CreateFileW_ptr=0x402f90d0, unknown3=0x0, unknown4=0x0) [loader.c:1845] in ntdll.dll.so) (ebp=40812f20) 49 0x40332613 (start_process+0xb3(arg=0x0) [process.c:171] in kernel32.dll.so) (ebp=40812ff4) 50 0x40005101 (dasetup.exe..rsrc+0x3efd8101 in libwine.so.1) (ebp=00000000) 0x493458ed (NTDLL.DLL.memcpy+0x67d8d): movl %gs:0x418,%eax

1 0

Delay setting breakpoints
by Shachar Shemesh 18 Nov '03

18 Nov '03

Hi list, Does anyone remeber how to delay setting a breakpoint in GDB? Due to human-machine incompatibilities, I am using GDB rather than winedbg, and setting breakpoints inside the actual program would be greatly simplified if I could ask for the breakpoint before starting Wine. Can anyone point me again to the doc describing running winedbg as a gdb backend? Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

3 2

Mac OS X Compilation broken
by Pierre d'Herbemont 18 Nov '03

18 Nov '03

Hi! I am getting trouble on Mac OS X with a modification to WineBuild. Here is the patch I am refering to: http://cvs.winehq.com/patch.py?id=9949 I'd like to know to what symbol "_end" should refer to? "_end" is flagged as an external symbol in the spec.c file, but I don't see any definition of it. I am getting the following error when launching wine: iMac:~ steg$ wine wine: failed to initialize: dlcompat: dyld: wine Undefined symbols: __end In fact the error appears when loading ntdll. Any idea? Thanks, Pierre

2 1

Re: Reject wildcards in directory names
by Paul Millar 18 Nov '03

18 Nov '03

Hi Hans, Which conformance tests fail currently? I don't see any problems with the kernel DLL tests right at the moment, which is somewhat disconcerting. I do see a problem with the listbox tests (in the user dll tests). There's also various bugs in pipe tests (under kernel) that mysteriously vanished after closing my eyes and counting to ten: http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php Anyone have any idea what might have happened? Cheers, Paul. On Mon, 17 Nov 2003, Hans Leidekker wrote: > This makes Wine pass the kernel directory conformance test without failures. ---- Paul Millar

3 5

Where has Freetype config gone?
by Shachar Shemesh 18 Nov '03

18 Nov '03

When trying to compile CVS Wine, I don't have freetype support. The configure script claims that I don't have freetype-dev installed (I do). configure.log shows the message: In file included from conftest.c:95: /usr/include/freetype2/freetype/freetype.h:20:2: #error "`ft2build.h' hasn't been included yet!" /usr/include/freetype2/freetype/freetype.h:21:2: #error "Please always use macros to include FreeType header files." /usr/include/freetype2/freetype/freetype.h:22:2: #error "Example:" /usr/include/freetype2/freetype/freetype.h:23:2: #error " #include <ft2build.h>" /usr/include/freetype2/freetype/freetype.h:24:2: #error " #include FT_FREETYPE_H" This message repeats several times (for several tests). My system is a Debian Sid, and I have freetype2-dev installed properly. -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

2 2

Re: Small winedefault.reg changes
by Alexandre Julliard 18 Nov '03

18 Nov '03

Francois Gouget <fgouget(a)codeweavers.com> writes: > [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug] > # command line to start a debugger when an exception occurs > -"Debugger"="winedbg --debugmsg -all %ld %ld" > +"Debugger"="winedbg.exe --debugmsg -all %ld %ld" This shouldn't make any difference; if it does it's a bug. > [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0002E005-0000-0000-C000-000000000046}\InProcServer32] > -@="comcat.dll" > +@="C:\\Windows\\System\\comcat.dll" This is wrong, the system directory is not necessarily c:\windows\system. -- Alexandre Julliard julliard(a)winehq.com

1 0

re: Potential forum at linuxquestions.org
by Dan Kegel 18 Nov '03

18 Nov '03

Mike Hearn wrote: > > It's not meant to replace wine-users, and especially not wine-devel of > course. > > Why a forum rather than a mailing list? That question, plus all the 'advantages' you list, indicate that you do indeed intend it to replace wine-users, at least for some users. A web interface that let you post to the mailing list would be fine. A web forum would not. It would mean that, if I wanted to answer user questions, I'd have to get used to another strange interface that probably has crappy indexing and is full of fruity HTML that gets in the way. I have read linuxquestions.org a bit, and don't like it much; I dislike the idea of encouraging people to use closed discussion forums like that, which don't support any sort of external archiving. Now, if you want to make things easier for users, there's room for improvement on the winehq forums page. For starters, the Forums link on the main page is buried a bit; it ought to be higher up (say, right after FAQ; the HowTo link should be part of Documentation). On the Forums page, the wine-users(a)winehq.com list should probably be the first thing on the page. The newsgroup link is currently wrong(!); it's currently news://comp.emulators.ms-windows.wine/ but should be news:comp.emulators.ms-windows.wine And we should probably link to the newsgroups at gmane.org, too. Shall I prepare patches for the website to implement these changes so people can see what I'm suggesting? - Dan

5 7

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