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

pshpack8.h:47:6: warning: #warning "8 as alignment
by Gerald Pfeifer 28 Jan '03

28 Jan '03

On all platforms I have access to (GNU/Linux, FreeBSD) I have been seeing the following for quite some time now: ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" ../../include/pshpack8.h:47:6: warning: #warning "8 as alignment is not supported" Is this really useful, resp. couldn't we avoid that somehow? Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

1 0

Re: Windows API database
by Dave Miller 28 Jan '03

28 Jan '03

So for starters, we want something like this? It doesn't look very impressive. :) http://home.ptd.net/~compsol/imported_dll.txt However, my system is by no means a clean install of WinXP home so most of thos DLLs probably don't belong to windows. -----Original Message----- From: Dan Kegel [mailto:dank(a)kegel.com] Sent: Thursday, January 23, 2003 5:20 PM To: Dave Miller Cc: wine-devel(a)winehq.com Subject: Re: Windows API database Oh, ok. Cross-referencing DLL imports and exports. Yeah, that sounds like a job for a simple perl script. All you need to output is DLL name and what DLLs it imports from. Just generate a flat text file for starters, then later postprocess that into an ascii tree or graph. It's going to be a messy little graph, I bet. - Dan Dave Miller wrote: > The project I am considering is mentioned on the contributing page here: > http://fgouget.free.fr/wine/contributing-en.shtml. (Build a database of > Windows APIs and dependencies) It sounds like less work to simply create > text files containing the imports and exports, although I think the point is > partially for the results to be easily cross referenced by developers. > Hence the suggestion of a database of some kind. I've considered scanning > applications as well. If I have any success with the Windows APIs I may try > tackling that at some point as well. > > ----- Original Message ----- > From: "Dan Kegel" <dank(a)kegel.com> > To: "David Miller" <compsol(a)ptd.net> > Cc: <wine-devel(a)winehq.com> > Sent: Thursday, January 23, 2003 3:38 PM > Subject: Re: Windows API database > > > >>David Miller wrote: >> >>>I would be interested in knowing more about the goals of this project. >>>Don't consider me officially working on such a thing just yet. I have >>>no real perl experience, but would like to learn. First I'd like to >>>know more about what I'm up against. >> >>I'm not sure what project you're talking about, but I can make a few >>wild guesses... >> >> >>>1. Is there a specific set of dll's and exe's we want included in the >>>database or does it need to scan and gather a list of all dll and exe >>>files? That would suggest a clean OS install is necessary. >> >>Sure, a clean OS install is probably good. Many of the >>APIs exposed by even the clean OS install may not be >>needed if no application calls them, but it's hard to know >>that in advance. >> >>We might want to also scan applications to see what APIs >>they actually use, but that's real hard. >> >> >>>2. What information should be in the database? (OS ver, name of dll or >>>exe, name of imported dll, APIs and whether they are imported or >>>exported, etc.) >> >>Maybe use the same format as we use in the souce tree? e.g. >>scanning advapi32.dll should produce something that looks very >>much like > > http://cvs.winehq.com/cvsweb/wine/dlls/advapi32/advapi32.spec?rev=1.32 > >>>3. Will a single MySQL table do or does it need to be a relational >>>database with multiple tables? >> >>IMHO no SQL is needed. The database should be plain text >>files checked into CVS. >> >> >>>4. Anything else you can tell me about this task? >> >>Compare with other standards which provide lists of API's, for example: >>http://www.linuxbase.org/spec/ >>http://www.unix.org/ >>http://www.ecma.ch/ecma1/STAND/ECMA-234.HTM >>to get some ideas. Of course, these are formatted all fancily, >>and cover different operating systems, but the goal is similar: >>to provide an authoritative list of APIs. >>Ideally, the result could be part of a submission to a >>standards body. >>(See also http://www.kegel.com/remedy/remedy2.html#fix.info ) >>- Dan >> >>-- >>Dan Kegel >>http://www.kegel.com >>http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 >> >> >> > > > > -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

2 1

Re: PATCH: dlls/ole32/storage.c
by Dan Kegel 28 Jan '03

28 Jan '03

Gerald Pfeifer wrote: > - int lastblocknr; > + int lastblocknr=-1; FWIW, some compilers will complain on that line (though only us K&R vets remember why). Safer to use whitespace between the = and the -, e.g. > - int lastblocknr; > + int lastblocknr = -1; - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 0

building a windows API database
by Dave Miller 28 Jan '03

28 Jan '03

Francois, I am interested in taking on the "build a database of windows APIs and dependencies" task. I have started work on scripts to scan a windows system and list import/export information. So far I can gather a list of dlls and run dumpbin on them, then parse imports (mostly, I think). I've started with simply printing the parsed output in three columns. The first is the DLL being scanned, the second is the DLL being imported, and the third is API imported. I am unsure of one thing. There is a 1 - 3 character hexadecimal number preceding almost every API. What is it, and should it be included in the output? Here is an example of what I am referring to: The hexadecimal number, in the third column. c:\windows\system32/atiiiexx.dll KERNEL32.dll 1AD InterlockedDecrement c:\windows\system32/atiiiexx.dll KERNEL32.dll 1B0 InterlockedIncrement c:\windows\system32/atiiiexx.dll KERNEL32.dll 126 GetModuleHandleA c:\windows\system32/atiiiexx.dll USER32.dll 2AC wsprintfA c:\windows\system32/atiiiexx.dll USER32.dll 1DE PostMessageA c:\windows\system32/atiiiexx.dll USER32.dll 15E GetWindowTextA Also I could use some direction on what the goals of this task are. Do we want text output? That makes a very large text file when listing all imported/exported APIs. Do we actually want a database for this?

1 0

Re: dlls/comcat Makefile.in version.rc include/wine wine_common_ver.rc
by John K. Hohm 27 Jan '03

27 Jan '03

> Changelog: > John K. Hohm <jhohm(a)acm.org> > Added optional OLESelfRegister to wine_common_ver.rc, used in dlls/comcat. This apparently was not applied; was it flawed, or simply missed?

1 0

WWN interview idea
by Brian Vincent 27 Jan '03

27 Jan '03

For a while now I've kicked around adding interviews to the Wine Weekly News. Basically how it would work is I'll email a bunch of you some questions, you can answer as many as you'd like, and I'll include the interview in the Wine Weekly News. More than likely there will be a bit of an email exchange so I can put some detail into it. (For instance, I never liked the interviews that were done on kde.org but the ones on kerneltrap.org are excellent.) What I'd like to do is get about ten of them completed first and publish them one at a time. They'll focus mostly on your involvement with Wine and the parts you've worked on. With a little luck they'll get into some of the technical details that someone wouldn't normally see discussed on the mailing list. I guess I'm more interested to hear from you if you _don't_ want to take part. Otherwise I'll assume you're a target. If you have any questions/comments/gripes or any other suggestions for the Wine Weekly News let me know. -Brian vinn(a)theshell.com

1 0

App works almost perfectly, but one MDI screen won't draw
by Dan Kegel 27 Jan '03

27 Jan '03

Installing my company's app is still a bear -- the only way I've found to avoid the dreaded "object reference not set" is to run with --debugmsg +ole and redirect to a file (not to the screen, and not to /dev/null). Once installed, the app runs quite well... except for one screen, which remains nearly blank. The MDI frames draw fine, but the contents (which include a hex memory dump area and a tree control) remain blank. Since there were a few richtext fixmes, I threw in native richtext dlls, and that got rid of lots of fixmes, but didn't help the display. Here's the Wine log file, passed through uniq -c: 1 fixme:win32:PE_CreateModule Security directory ignored 1 err:win32:PE_fixup_imports No implementation for WSOCK32.dll.1141 imported from blahblah.dll, setting to 0xdeadbeef 1 fixme:ole:CoRegisterMessageFilter stub 1 fixme:commdlg:GetFileName95 Flags 0x00800002 not yet implemented 1 fixme:winsock:WS_bind Setting WS_SO_REUSEADDR on socket before we binding it 2 fixme:mdi:MDIRefreshMenu partially function stub 1 fixme:dc:LockWindowUpdate ((nil)), partial stub! 3 fixme:mdi:MDIRefreshMenu partially function stub 1 fixme:winsock:WS_bind Setting WS_SO_REUSEADDR on socket before we binding it 8 fixme:mdi:MDIRefreshMenu partially function stub 1 fixme:ole:CoRegisterMessageFilter stub Grr. Nothing's really obvious to this non-windows-programmer, and the guy who wrote this program is on vacation, so I can't pick his brains. Anyone have suggestions for what to try next? Thanks, Dan p.s. FWIW, here's sort | uniq -c of the log file before I threw in the native DLLs: 1 err:win32:PE_fixup_imports No implementation for WSOCK32.dll.1141 imported from blahblah.dll, setting to 0xdeadbeef 1 fixme:dc:LockWindowUpdate ((nil)), partial stub! 9 fixme:mdi:MDIRefreshMenu partially function stub 2 fixme:ole:CoRegisterMessageFilter stub 1 fixme:richedit:RICHED32_WindowProc Unknown message 0x24 Passed to default hwnd=0x110023, wParam=00000000, lParam=40791e18 622 fixme:richedit:RICHED32_WindowProc Unknown message 0x363 Passed to default hwnd=0x110023, wParam=00000001, lParam=00000000 1 fixme:win32:PE_CreateModule Security directory ignored 2 fixme:winsock:WS_bind Setting WS_SO_REUSEADDR on socket before we binding it

5 11

qpro200.dll is its own little DLL hell
by Dan Kegel 27 Jan '03

27 Jan '03

The VB app I'm trying to bring up (Yardi) installs qpro200.dll. Amusingly, their setup utility crashes on startup if you run it again, in that dll's init routine. Deleting it seems to fix things. Good old DLL hell. Partial relay and traceback attached in case anyone's curious. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 080f0590:Call kernel32.GetModuleHandleA(411021b0 "C:\\WINDOWS\\SYSTEM\\qpro200.dll") ret=41160128 080f0590:Ret kernel32.GetModuleHandleA() retval=00000000 ret=41160128 080f0590:Call kernel32.LoadLibraryExA(411021b0 "C:\\WINDOWS\\SYSTEM\\qpro200.dll",00000000,00000002) ret=4116013c 080f0590:Ret kernel32.LoadLibraryExA() retval=00000000 ret=4116013c 080f0590:Call kernel32.LoadLibrary16(411021b0 "C:\\WINDOWS\\SYSTEM\\qpro200.dll") ret=41160354 080f0590:CallTo16(func=02e7:00fb,ds=0417) ss:sp=0267:1530 ax=0000 bx=0000 cx=0800 dx=0000 si=0000 di=0416 bp=155a es=0417 fs=0000 080f0590:Call KERNEL.4: LOCALINIT(0417,0000,0800) ret=02e7:0120 ds=0417 080f0590:Ret KERNEL.4: LOCALINIT() retval=0001 ret=02e7:0120 ds=0417 wine: Unhandled exception, starting debugger... ... Unhandled exception: privileged instruction in 16-bit code (02ef:00ab). In 16-bit mode. 0x02ef:0x00ab: ljmp *%ss:0x0020 Wine-dbg>Backtrace: =>0 0x02ef:0x00ab (bp=1528) 1 0x02ef:0x0127 (bp=155a) 2 0x4007951b (NE_InitDLL+0x113(pModule=0x402750b8) [segment.c:680] in libntdll.dll.so) (ebp=41101c30) 3 0x40075b9a (MODULE_LoadModule16+0x10e(libname=0x411021b0, implicit=0x0, lib_only=0x1) [module.c:999] in libntdll.dll.so) (ebp=41101c60) 4 0x40075e23 (LoadModule16+0xc3(name=0x411021b0, paramBlock=0xffffffff) [module.c:1084] in libntdll.dll.so) (ebp=41101c84) 5 0x400761f2 (LoadLibrary16+0x1a(libname=0x411021b0) [module.c:1245] in libntdll.dll.so) (ebp=41101c98) 6 0x4009ac27 (.L119+0x4 [relay386.c] in libntdll.dll.so) (ebp=41101cac) 7 0x4009aeb8 (RELAY_CallFrom32+0x68(ret_addr=0x41160354) [relay386.c:426] in libntdll.dll.so) (ebp=41101d30) 8 0x40a4f02d (KERNEL32.DLL.LoadLibrary16+0x5 in kernel32.dll.so) (ebp=41101d58) 9 0x41160815 (GetFileVersionInfoA+0x85(filename=0x411021b0, handle=0x0, datasize=0x3e8, data=0x40274cc8) [info.c:524] in ver.dll.so) (ebp=41101d7c) 10 0x4116155e (_fetch_versioninfo+0x3e [install.c] in ver.dll.so) (ebp=41101da0) 11 0x41161952 (VerInstallFileA+0x2fa(flags=0x2, srcfilename=0x4026297c, destfilename=0x4026270a, srcdir=0x402619ae, destdir=0x40262a1a, curdir=0x402628de, tmpfile=0x40262840, tmpfilelen=0x411022f4) [install.c:445] in ver.dll.so) (ebp=411022cc) 12 0x4115f75d (VerInstallFile16+0x31(flags=0x2, lpszSrcFilename=0x4026297c, lpszDestFilename=0x4026270a, lpszSrcDir=0x402619ae, lpszDestDir=0x40262a1a, lpszCurDir=0x402628de, lpszTmpFile=0x40262840, lpwTmpFileLen=0x40262c06) [ver16.c:80] in ver.dll.so) (ebp=411022fc) 13 0x4115f5b6 (__wine_ver_dll_CallFrom16_p_long_wtttttpp+0xa6(proc=0x4115f72c, args=0x402626e8) [ver.spec.c:138] in ver.dll.so) (ebp=4110232c) 14 0x400b9cf5 (__wine_call_from_16_long+0x8d [relay16.s] in libntdll.dll.so) (ebp=41102364) 15 0x025f:0x250a (bp=1a8c) 16 0x025f:0x1f89 (bp=1ae2) 17 0x00f7:0x0000 (bp=1b1c, far call assumed) 18 0x4009ac30 (.L120+0x7 [relay386.c] in libntdll.dll.so) (ebp=4110237c) 19 0x4009aeb8 (RELAY_CallFrom32+0x68(ret_addr=0x40888153) [relay386.c:426] in libntdll.dll.so) (ebp=41102400) 20 0x40a5336d (KERNEL32.DLL.wine_call_to_16_regs_short+0x5 in kernel32.dll.so) (ebp=4110270c) 21 0x4089f1cc (SendMessage16+0xe8(hwnd16=0x21, msg=0x720, wparam=0x0, lparam=0x0) [msg16.c:72] in user32.dll.so) (ebp=41102778) 22 0x40834b02 (__wine_user_exe_CallFrom16_p_long_wwwl+0x1a(proc=0x4089f0e4, args=0x40262caa) [user.exe.spec.c:1449] in user32.dll.so) (ebp=41102790) 23 0x400b9cf5 (__wine_call_from_16_long+0x8d [relay16.s] in libntdll.dll.so) (ebp=411027c8) 24 0x025f:0x1f4a (bp=1b7e) 25 0x00f7:0x0000 (bp=1bb8, far call assumed) 26 0x4009ac30 (.L120+0x7 [relay386.c] in libntdll.dll.so) (ebp=411027e0) 27 0x4009aeb8 (RELAY_CallFrom32+0x68(ret_addr=0x40888153) [relay386.c:426] in libntdll.dll.so) (ebp=41102864) 28 0x40a5336d (KERNEL32.DLL.wine_call_to_16_regs_short+0x5 in kernel32.dll.so) (ebp=41102b70) 29 0x4089f787 (DispatchMessage16+0xaf(msg=0x40262e70) [msg16.c:301] in user32.dll.so) (ebp=41102bb8) 30 0x408347ba (__wine_user_exe_CallFrom16_p_long_p+0x2e(proc=0x4089f6d8, args=0x40262d46) [user.exe.spec.c:1288] in user32.dll.so) (ebp=41102bc8) 31 0x400b9cf5 (__wine_call_from_16_long+0x8d [relay16.s] in libntdll.dll.so) (ebp=41102c00) 32 0x025f:0x1e15 (bp=1cfc) 33 0x025f:0x00d2 (bp=1d0a)

3 4

open_master_socket ???
by Auge Mike 27 Jan '03

27 Jan '03

/* open the master server socket and start waiting for new clients */ open_master_socket Who can explain for me the task of the above function in more words? Why we need to do fork() inside this function, although the parent of this process will terminate after the child do call acquire_lock()? Thanx _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

trouble with spy++
by Dan Kegel 27 Jan '03

27 Jan '03

I am trying out spy++, and it works great under Windows; both the version from MSVC4.0 and MSVC6.0 can display the Windows Messages apps receive on, say, getting focus. Unfortunately, spy++ doesn't seem to do diddly under Wine. I see no messages, no matter what window I ask for details about, or what I do to that window. Is there some trick to running spy++ under Wine? Thanks, Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

1 1