wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

To strip or not to strip
by Jeremy White 13 Jul '01

13 Jul '01

We've always built the CodeWeavers Wine RPM unstripped, in the theory that it made supporting Wine newbies easier. However, AFAICT from watching cemw, we never get into a situation where a newbie goes into winedbg; more often, they shift first to the CVS tip, and from there maybe to winedbg. So, it seems like shipping debug symbols may just be a waste of bandwidth. (Note, we build with all full logging enabled, and we'll never change that). However, before we go ahead and yank the debug info out of our RPM, I thought I'd post a note, and let someone tell me if I'm wrong. Thanks, Jer

1 0

Re: Documentation fixes
by Alexandre Julliard 12 Jul '01

12 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > Like: > > /*********************************************************************** > * strcpy (MSVCRT.@) > */ > #if 0 /* Suppress warnings */ > extern char *strcpy(char *dest, const char *src); > #endif > > Perhaps we could do the same with atom functions and lstrcmpi? > The #if 0 #endif isn't even needed for them I believe. That's quite ugly IMO. As long as we require comments, we might as well put everything explicitly in the comment, something like: /* ##spec## msvcrt "@ cdecl strcpy(ptr str) strcpy" */ (we can probably come up with a better syntax, but you get the idea). Then we can simply grep for '##spec##' and extract everything into the spec file. We can do the same for forwards etc. (and in fact we could do it for normal entry points as well). -- Alexandre Julliard julliard(a)winehq.com

2 1

RE: Documentation fixes
by Patrik Stridvall 12 Jul '01

12 Jul '01

> > The problem is that if I say that the memory directory doesn't > > "belong" to dlls/user/user.spec winapi_{check,extract,fixup} will > > not find implementations for all functions, which will cause > > problems. > > > > For example how should winapi_extract know that I should > generate the line > > 471 pascal16 lstrcmpi(str str) lstrcmpiA > > when it generates the spec files? > > Well, it's a more general problem, namely that the spec files can > reference functions that are not implemented directly in the dll. > > You also have for instance: > > @ cdecl strcpy(ptr str) strcpy > > in MSVCRT, and strcpy is clearly not implemented there since it's in > the C library. So you cannot assume that only the functions contained > in the dll can be used in the spec files, it is legal for the spec > file to reference external functions. True. I didn't even thought of that particular problem. Functions like strcpy is currently suppressed by having it listed in tools/winapi_check/nativeapi.dat, but that is a little kludgy. [Thinking...] Well you could simply have an function documentation comment without a function implementation in some file that belongs to MSVCRT. Like: /*********************************************************************** * strcpy (MSVCRT.@) */ #if 0 /* Suppress warnings */ extern char *strcpy(char *dest, const char *src); #endif Perhaps we could do the same with atom functions and lstrcmpi? The #if 0 #endif isn't even needed for them I believe. > > I think that we need to move the solution of this problem one step > > up the "ladder" and discuss the more general problem: > > How should we store the information needed to generate > > the spec files in the source, especially concerning > > the forwards and stubs? > > You'll need a file somewhere that specifies all the entries that > cannot be determined automatically from the source. You simply cannot > build a 100% correct spec file based only on the function comments. Yes. I have some ideas, but no really good one. My currently best suggestion is having a .spec.in file that approximately looks like the .spec files but supports configure like substitutions. foo.spec.in: ---8<--- name foo type win32 init @init@ rsrc foo.res import baz.dll @debug_channels@ 101 forward Bar BAZ.Bar 102 stub BarFoo @fixed@ @ forward Foo BAZ.Foo @ stub FooBar @unfixed@ ---8<--- And simply let winapi_extract or whatever simple substitute @init@, @debug_channels@, @fixed@ and @unfixed@ with what can be extracted from the source. > And you definitely do not want to need to parse KERNEL source files > (like the ones in memory/) to build the USER spec file. Of course. The question was whether the memory directory belongs to USER or not. I have now accepted that it does not.

1 0

Re: Documentation fixes
by Alexandre Julliard 12 Jul '01

12 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > > No, USER does not use the memory directory. It links directly to > > libkernel32.so because it needs some internal functions in there, > > Like the atom functions that are implemented in memory/atom.c I guess > you mean. Actually no, the atom functions are similar to lstrcmpi, they are exported from kernel so we don't need to link to libkernel32.so to get them (and they shouldn't have USER comments either). The real problem is the internal kernel functions called by user, things like THUNK_Alloc or LOCAL_Alloc. > The problem is that if I say that the memory directory doesn't > "belong" to dlls/user/user.spec winapi_{check,extract,fixup} will > not find implementations for all functions, which will cause > problems. > > For example how should winapi_extract know that I should generate the line > 471 pascal16 lstrcmpi(str str) lstrcmpiA > when it generates the spec files? Well, it's a more general problem, namely that the spec files can reference functions that are not implemented directly in the dll. You also have for instance: @ cdecl strcpy(ptr str) strcpy in MSVCRT, and strcpy is clearly not implemented there since it's in the C library. So you cannot assume that only the functions contained in the dll can be used in the spec files, it is legal for the spec file to reference external functions. > I think that we need to move the solution of this problem one step > up the "ladder" and discuss the more general problem: > How should we store the information needed to generate > the spec files in the source, especially concerning > the forwards and stubs? You'll need a file somewhere that specifies all the entries that cannot be determined automatically from the source. You simply cannot build a 100% correct spec file based only on the function comments. And you definitely do not want to need to parse KERNEL source files (like the ones in memory/) to build the USER spec file. -- Alexandre Julliard julliard(a)winehq.com

1 0

RE: Documentation fixes
by Patrik Stridvall 12 Jul '01

12 Jul '01

> Patrik Stridvall <ps(a)leissner.se> writes: > > > PS. And yes, the added lstrcmpi (USER.471) in memory/string.c > > should really be there. Both KERNEL and USER uses the memory > > directory. > > No, USER does not use the memory directory. It links directly to > libkernel32.so because it needs some internal functions in there, Like the atom functions that are implemented in memory/atom.c I guess you mean. > but > that's a different problem. lstrcmpi is a purely KERNEL function, that > happens to be imported by USER (and by other dlls too), That might be so, but it is also _exported_ by USER: grep lstrcmpi dlls/user/user.spec 471 pascal16 lstrcmpi(str str) lstrcmpiA and lstrcmpiA is not implemented anyware else The same goes for the atom functions: grep Atom dlls/user/user.spec 268 pascal16 GlobalAddAtom(str) GlobalAddAtomA 269 pascal16 GlobalDeleteAtom(word) GlobalDeleteAtom 270 pascal16 GlobalFindAtom(str) GlobalFindAtomA 271 pascal16 GlobalGetAtomName(word ptr s_word) GlobalGetAtomNameA > so USER must > not be mentioned in the comment IMO. The problem is that if I say that the memory directory doesn't "belong" to dlls/user/user.spec winapi_{check,extract,fixup} will not find implementations for all functions, which will cause problems. For example how should winapi_extract know that I should generate the line 471 pascal16 lstrcmpi(str str) lstrcmpiA when it generates the spec files? Of course the automatic generation of spec files is not 100% complete most importantly handling of forwards and stubs is not supported. I think that we need to move the solution of this problem one step up the "ladder" and discuss the more general problem: How should we store the information needed to generate the spec files in the source, especially concerning the forwards and stubs? I will address this issue in a separate mail, but you are welcome to add comments specific to this problem in this thread, I'm not sure I feel to writing it today. I have been postponing the writing of mail for quite some time and I'm currenly beginning to get rather tired. PS. Why not as an interim solution simply add support for forward in the Win16 spec files so 471 pascal16 lstrcmpi(str str) lstrcmpiA becomes 471 forward lstrcmpi(str str) USER32.lstrcmpiA which winebuild until actual need simply interprets as 471 pascal16 lstrcmpi(str str) lstrcmpiA Hmm. Perhaps we should have forward16 and forward to separate the pascal16 and pascal cases? Anyway this gives winapi_{check,fixup} enough information to handle the situation where the memory directory doesn't "belong" to dlls/user/user.spec.

1 0

Re: New problems with the debugger
by Uwe Bonnes 12 Jul '01

12 Jul '01

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: >> WineDbg starting... file_set_error: No such process Can't attach >> process 8068d98: error 317 Alexandre> I don't see this here. Could you please run wineserver under Alexandre> gdb, put a breakpoint on the file_set_error message Alexandre> (server/file.c line 334), and send me the backtrace at this Alexandre> point? Thanks. Breakpoint 1, file_set_error () at file.c:334 334 default: perror("file_set_error"); set_error( ERROR_UNKNOWN /* FIXME */ ); break; (gdb) bt #0 file_set_error () at file.c:334 #1 0x804b1e5 in get_thread_context (thread=0x97fa210, flags=65537, context=0xbffff350) at context_i386.c:142 #2 0x804b567 in get_thread_single_step (thread=0x97fa210) at context_i386.c:481 #3 0x8051d2e in continue_thread (thread=0x97fa210) at ptrace.c:177 #4 0x8050e9f in resume_process (process=0x8068d98) at process.c:518 #5 0x804bfc6 in debugger_attach (process=0x8068d98, debugger=0x97fa778) at debugger.c:420 #6 0x804c278 in req_debug_process (req=0xbffff4d8) at debugger.c:540 #7 0x805669f in read_request (thread=0x97fa778) at request.c:168 #8 0x805922b in thread_poll_event (obj=0x97fa778, event=1) at thread.c:157 #9 0x8057642 in select_loop () at select.c:262 #10 0x804e5af in main (argc=1, argv=0xbffff6d4) at main.c:108 #11 0x40178baf in __libc_start_main () from /lib/libc.so.6 Perhaps to notice: I run 2.4.6 on a SMP machine, Suse 7.1 Hope this helps 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: Documentation fixes
by Alexandre Julliard 12 Jul '01

12 Jul '01

Patrik Stridvall <ps(a)leissner.se> writes: > PS. And yes, the added lstrcmpi (USER.471) in memory/string.c > should really be there. Both KERNEL and USER uses the memory > directory. No, USER does not use the memory directory. It links directly to libkernel32.so because it needs some internal functions in there, but that's a different problem. lstrcmpi is a purely KERNEL function, that happens to be imported by USER (and by other dlls too), so USER must not be mentioned in the comment IMO. -- Alexandre Julliard julliard(a)winehq.com

1 0

New problems with the debugger
by Uwe Bonnes 12 Jul '01

12 Jul '01

Hallo, since the update yesterday evening ( and a fresh update recently), on a crash the debugger has problems like this one: 08067330:Call kernel32.UnhandledExceptionFilter(404e4b00) ret=7800f2b8 fixme:pthread_kill_other_threads_np FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock Could not stat /home/bon/ikda/vol2 (No such file or directory), ignoring drive Y: FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock Could not stat /home/bon/ikda/sys (No such file or directory), ignoring drive Z: WineDbg starting... file_set_error: No such process Can't attach process 8068d98: error 317 Beendet Is this known? 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: The [Windows] section
by Alexandre Julliard 12 Jul '01

12 Jul '01

"Bill Medland" <medbi01(a)accpac.com> writes: > The answer, for those interested > > In Windows 95 a load of configuration information moved from win.ini (esp > the [windows] section) to the registry. Now (when the edits are added to > the cvs) information should come from the [windows] section of win.ini if > the winelook is WIN31 and from the registry in general otherwise, with the > Tweak.Layout overriding both. Actually I have hacked your patch a bit when committing it (hope you don't mind ;-), with the idea of phasing out the Tweak.Layout stuff. So now the values come from the registry for Win95, and from win.ini (plus some hard-coded values) for Win3.1. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: PATCH: internetgetconnectionstate
by Gerard Patel 12 Jul '01

12 Jul '01

At 11:37 PM 09/07/2001 +0200, you (Marcus Meissner) wrote: >Hi, > >QuickTimePlayer 5 is using InternetGetConnectedState to check whether to >download its 'homepage'. > >Just say we are connected, and on a LAN. > >Ciao, Marcus > >Changelog: > Have InternetGetConnectedState always return 'LAN connection'. Theoretically this could cause trouble when used with a computer having no connection to the Internet, as an app could think it can connect, try to do it, fail and terminate or display annoying messages. It's not really a strong objection, as most decent computers are connected to the Internet these days, but maybe a config option could be better ? Just a thought. Gerard

3 2

CreateWindow issue?
by Bill Medland 12 Jul '01

12 Jul '01

Can anyone shed any light on this? 1. If I take Petzold's POPPAD1 project and slightly modify it so that the style is WS_CHILD | WS_BORDER | WS_VISIBLE | ES_AUTOHSCROLL and then spy on the WM_NCCREATE and WM_CREATE it tells me that the style passed in is WS_OVERLAPPEDWINDOW | WS_CHILDWINDOW | WS_VISIBLE | ES_AUTOHSCROLL which is not the same thing. Does anyone know if a. The Windows Spy++ is telling fibs b. (Win95) CreateWindow patches them up in some way. 2. (Why I was even looking at 1) In the application I am working on we open Edit controls almost as above inside dialogs and they appear with a single pixel solid frame under Windows whereas under Wine they appear with a 2-pixel sunken frame. There are several changes I can make in the controls/edit.c to get the same behaviour under Wine but so far they all "mess up" normal sunken ones. (Under windows the resulting windows end up with zero extended style and 50000088 style.) Any thoughts would be appreciated. Bill

1 1

The [Windows] section
by Bill Medland 12 Jul '01

12 Jul '01

Is the [Windows] section of the config still supposed to be in use or should Tweak.Layout be used instead? (I am looking at the [Windows].BorderWidth in particular) Bill

1 1

Re: msvcrt switching from builtin to native
by Alexandre Julliard 11 Jul '01

11 Jul '01

Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes: > _ismbcdigit is unimplemented. The log looks like wine starts to think with > that call that msvcrt is a native dll. Implementing a semi stub for that > gives the same behaviour at the next unimplemented msvcrt function. This should fix it: Index: loader/pe_image.c =================================================================== RCS file: /opt/cvs-commit/wine/loader/pe_image.c,v retrieving revision 1.94 diff -u -r1.94 pe_image.c --- loader/pe_image.c 2001/05/24 18:43:16 1.94 +++ loader/pe_image.c 2001/07/11 20:50:37 @@ -655,7 +655,7 @@ return NULL; } - if (pe_export) + if (!builtin && pe_export) SNOOP_RegisterDLL( hModule, wm->modname, pe_export->Base, pe_export->NumberOfFunctions ); /* Send DLL load event */ -- Alexandre Julliard julliard(a)winehq.com

1 0

msvcrt switching from builtin to native
by Uwe Bonnes 11 Jul '01

11 Jul '01

Hallo, trying to run msdev.exe with builtin msvcrt, at some point thins strange +snoop,+relay log appears: 08066950:Call msvcrt._strdup(4040b294 "Microsoft Visual C++") ret=5f416652 08066950:Call kernel32.HeapAlloc(40390000,00000000,00000015) ret=4063d846 08066950:Ret kernel32.HeapAlloc() retval=4041c338 ret=4063d846 08066950:Ret msvcrt._strdup() retval=4041c338 ret=5f416652 08066950:Call msvcrt._mbsinc(5f49d450 "%d") ret=5f4160fb 08066950:Ret msvcrt._mbsinc() retval=5f49d451 ret=5f4160fb 08066950:Call msvcrt.atoi(5f49d451 "d") ret=5f41614d 08066950:Ret msvcrt.atoi() retval=00000000 ret=5f41614d 08066950:CALL msvcrt.292: _ismbcdigit(<unknown, check return>) ret=5f416161 ^^^^ 08066950:Call ntdll.RtlRaiseException(406064e0) ret=40631056 08066950:CALL msvcrt.74: __CxxFrameHandler(<unknown, check return>) ret=4006ac97 08066950:Call ntdll.RtlRaiseException(406061d0) ret=40631056 08066950:CALL msvcrt.74: __CxxFrameHandler(<unknown, check return>) ret=4006ac97 _ismbcdigit is unimplemented. The log looks like wine starts to think with that call that msvcrt is a native dll. Implementing a semi stub for that gives the same behaviour at the next unimplemented msvcrt function. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Early crash with msdev.exe
by Uwe Bonnes 11 Jul '01

11 Jul '01

Hallo, trying msdev.exe from Microsoft Visual C in a demonstration at Linuxtag, I was astonished how far wine proceeds. Only when trying to create a template, wine crashed. Trying to debug with snoop, however the crash happens much earlier. I tried to look hard at snoop.c, but couldn't find where this error may originate from. Has anybody some idea? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- 08066950:RET msvcrt.658: malloc() retval = 40b01f20 ret=50043066 tid=08066950 08066950:CALL msvcrt.272: _initterm() ret=50043090 08066950:CALL devshl.1603: @(00000700,00000081,00000000,40605ad4,4060576c) ret=50301f0a 08066950:RET devshl.1603: @() retval = 00000000 ret=50301f0a tid=08066950 08066950:CALL mfc42.6374: @(<unknown, check return>) ret=50301f51 08066950:CALL mfc42.5163: @(<unknown, check return>) ret=5f401aff 08066950:CALL msvcrt.67: _EH_prolog(4101007d,00000081,00000000,40605ad4,40605728,40b06da0,00000000,40605748,41010064,00000081,00000000,40605ad4,40b06da0,40b06da0,40605764,50301f1f, ...) ret=5f401b2b 08066950:RET msvcrt.67: _EH_prolog() retval = 41010096 ret=5f401b2b tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler(<unknown, check return>) ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.74: __CxxFrameHandler() ret=4006ac97 08066950:RET msvcrt.74: __CxxFrameHandler() retval = 00000001 ret=4006ac97 tid=08066950 08066950:CALL msvcrt.203: _except_handler3(<unknown, check return>) ret=4006ac97 08066950:CALL msvcrt.73: _XcptFilter(<unknown, check return>) ret=0040175d fixme:pthread_kill_other_threads_np FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock Could not stat /home/bon/ikda/vol2 (No such file or directory), ignoring drive Y: FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock Could not stat /home/bon/ikda/sys (No such file or directory), ignoring drive Z: WineDbg starting... on pid 80683b0 No debug information in 32bit DLL '<Debugged process>' (0x00400000) Loaded debug information from ELF 'wine' (0x00000000) Breakpoint 1 at 0x4000da00 (_end+0x37fc1284) Loaded debug information from ELF '/spare/bon/wine/dlls/libntdll.so' (0x40026000) Loaded debug information from ELF '/spare/bon/wine/libwine.so' (0x40127000) Loaded debug information from ELF '/spare/bon/wine/libwine_unicode.so' (0x4013d000) Loaded debug information from ELF '/lib/libncurses.so.5' (0x40205000) Loaded debug information from ELF '/lib/libm.so.6' (0x4024f000) No debug information in ELF '/lib/libutil.so.1' (0x4026d000) No debug information in ELF '/lib/libdl.so.2' (0x40270000) Loaded debug information from ELF '/lib/libc.so.6' (0x40273000) Loaded debug information from ELF '/lib/ld-linux.so.2' (0x40000000) Loaded debug information from ELF '/spare/bon/wine/dlls/libkernel32.so' (0x40617000) Loaded debug information from ELF '/spare/bon/wine/dlls/libgdi32.so' (0x406b4000) Loaded debug information from ELF '/spare/bon/wine/dlls/libadvapi32.so' (0x40723000) Loaded debug information from ELF '/spare/bon/wine/dlls/libuser32.so' (0x40762000) Loaded debug information from ELF '/spare/bon/wine/dlls/libshell32.so' (0x40882000) Loaded debug information from ELF '/spare/bon/wine/dlls/libshlwapi.so' (0x408e8000) Loaded debug information from ELF '/spare/bon/wine/dlls/libcomctl32.so' (0x40923000) Loaded debug information from ELF '/spare/bon/wine/dlls/libx11drv.so' (0x40c00000) Loaded debug information from ELF '/spare/bon/wine/libwine_tsx11.so' (0x40741000) No debug information in ELF '/usr/X11R6/lib/libSM.so.6' (0x40019000) No debug information in ELF '/usr/X11R6/lib/libICE.so.6' (0x40c4d000) No debug information in ELF '/usr/X11R6/lib/libXpm.so.4' (0x40c65000) No debug information in ELF '/usr/X11R6/lib/libXxf86dga.so.1' (0x40387000) No debug information in ELF '/usr/X11R6/lib/libXxf86vm.so.1' (0x404e5000) No debug information in ELF '/usr/X11R6/lib/libXv.so.1' (0x404ea000) No debug information in ELF '/usr/X11R6/lib/libXext.so.6' (0x40752000) No debug information in ELF '/usr/X11R6/lib/libX11.so.6' (0x40c74000) No debug information in ELF '/usr/lib/gconv/ISO8859-1.so' (0x4038d000) Loaded debug information from ELF '/spare/bon/wine/dlls/libversion.so' (0x404d3000) Loaded debug information from ELF '/spare/bon/wine/dlls/liblz32.so' (0x40695000) No debug information in 32bit DLL 'NTDLL.DLL' (0x40060000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSVCRT.DLL' (0x78000000) No debug information in 32bit DLL 'ADVAPI32.DLL' (0x40731000) No debug information in 32bit DLL 'GDI32.DLL' (0x406d0000) No debug information in 32bit DLL 'USER32.DLL' (0x40790000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MFC42.DLL' (0x5f400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x7ff20000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLEAUT32.DLL' (0x7fe80000) No debug information in 32bit DLL 'SHLWAPI.DLL' (0x408fd000) No debug information in 32bit DLL 'COMCTL32.DLL' (0x4092f000) No debug information in 32bit DLL 'SHELL32.DLL' (0x4089c000) No debug information in 32bit DLL 'K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVSHL.DLL' (0x50000000) No debug information in 32bit DLL 'X11DRV.DLL' (0x40c11000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MFC42LOC.DLL' (0x7baf0000) No debug information in 32bit DLL 'LZ32.DLL' (0x40698000) No debug information in 32bit DLL 'VERSION.DLL' (0x404d6000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x7fb90000) No debug information in 32bit DLL 'K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVEDIT.PKG' (0x50800000) No debug information in 32bit DLL 'K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG' (0x50300000) 08066950:RET msvcrt.73: _XcptFilter() retval = 00000000 ret=0040175d 08066950:RET msvcrt.203: _except_handler3() retval = 00000001 ret=4006ac97 Unhandled exception: page fault on read access to 0x0000000f in 32-bit code (0x5f401ead). In 32-bit mode. 0x5f401ead (MFC42.DLL.1145+0x10 in C:\WINDOWS\SYSTEM\MFC42.DLL): cmpl $0,0x10(%ebx) Wine-dbg>bt Backtrace: =>0 0x5f401ead (MFC42.DLL.1145+0x10 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=40605684) 1 0x5f401c94 (MFC42.DLL.5163+0x173 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=4060570c) 2 0x4101007d (_end+0x3c3255) (ebp=4060572c) 3 0x41010064 (_end+0x3c323c) (ebp=40605748) 4 0x50301f1f (DEVPRJ.PKG..text+0xf1f in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=40605764) 5 0x5f401a88 (MFC42.DLL.1109+0x74 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=406057c4) 6 0x5f401a10 (MFC42.DLL.1578+0x2a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=406057e0) 7 0x5f4019cf (MFC42.DLL.1579+0x39 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=4060580c) 8 0x40803b87 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=40605830) 9 0x40803c06 (WINPROC_CallWndProc+0x76(proc=0x5f401996, hwnd=0x700, msg=0x81, wParam=0x0, lParam=0x40605ad4) [winproc.c:171] in libuser32.so) (ebp=4060585c) 10 0x408097f8 (CallWindowProcA+0x88(func=0x40d70dbc, hwnd=0x700, msg=0x81, wParam=0x0, lParam=0x40605ad4) [winproc.c:2589] in libuser32.so) (ebp=40605884) 11 0x407ea1a3 (MSG_SendMessage+0x3b3(hwnd=0x700, msg=0x81, wParam=0x0, lParam=0x40605ad4, timeout=0xffffffff, type=0x2, pRes=0x406058ec) [message.c:1733] in libuser32.so) (ebp=406058bc) 12 0x407ea2a2 (SendMessageA+0x32(hwnd=0x700, msg=0x81, wParam=0x0, lParam=0x40605ad4) [message.c:1772] in libuser32.so) (ebp=406058f0) 13 0x40c15014 (X11DRV_CreateWindow+0x184(hwnd=0x700, cs=0x40605ad4, unicode=0x0) [window.c:871] in libx11drv.so) (ebp=40605938) 14 0x407fce51 (WIN_CreateWindowEx+0x6d1(cs=0x40605ad4, classAtom=0xc066, type=0x2) [win.c:865] in libuser32.so) (ebp=406059b0) 15 0x407fd2fb (CreateWindowExA+0x14b(exStyle=0x0, className=0x403fcebc, windowName=0x0, style=0x42000001, x=0x0, y=0x0, width=0x0, height=0x0, parent=0x2b4, menu=0x7310, instance=0x400000, data=0x40605be0) [win.c:1030] in libuser32.so) (ebp=40605b04) 16 0x5f40c211 (MFC42.DLL.2152+0x9a in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=40605b74) 17 0x5f40aaa5 (MFC42.DLL.2124+0x46 in C:\WINDOWS\SYSTEM\MFC42.DLL) (ebp=40605bb0) 18 0x4101004b (_end+0x3c3223) (ebp=40605c04) 19 0x50311b41 (DEVPRJ.PKG.InitPackage+0x4b5 in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=40605c2c) 20 0x50310336 (DEVPRJ.PKG.EntryPoint+0xb5e in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=40605c58) 21 0x50311a22 (DEVPRJ.PKG.InitPackage+0x396 in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=40605c84) 22 0x50311760 (DEVPRJ.PKG.InitPackage+0xd4 in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVPRJ.PKG) (ebp=406060c0) 23 0x50036fa3 (DEVSHL.DLL.3467+0x9a in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVSHL.DLL) (ebp=40606664) 24 0x500344be (DEVSHL.DLL.3219+0x53d in K:\USR\LOCAL\SPARE\BON\NT4SP5G\PROGRAMME\MICROSOFT VISUAL STUDIO\COMMON\MSDEV98\BIN\DEVSHL.DLL) (ebp=40606e0c) 25 0x41010019 (_end+0x3c31f1) (ebp=40606ecc) 26 0x400dbf23 (start_process+0x1a3 [process.c:391] in libntdll.so) (ebp=40606f30) 27 0x400dfaa1 (SYSDEPS_DoCallOnStack+0x21(func=0x400dbd80, arg=0x0) [sysdeps.c:173] in libntdll.so) (ebp=40606ff0) 28 0x400dfb43 (SYSDEPS_CallOnStack+0x2f in libntdll.so) (ebp=bffff5f0) 29 0x400dfbfa (SYSDEPS_SwitchToThreadStack+0x9a(func=0x400dbd80) [sysdeps.c:236] in libntdll.so) (ebp=bffff62c) 30 0x400dc2be (PROCESS_InitWine+0x1ce(argc=0x4, argv=0xbffff6c4, win16_exe_name=0x804c660, win16_exe_file=0x804c764) [process.c:519] in libntdll.so) (ebp=bffff644) 31 0x0804b20a (Letext [main.c] in wine) (ebp=bffff65c) 32 0x4028fbaf (__libc_start_main+0xcf in libc.so.6) (ebp=bffff698) 33 0x08049021 (_start+0x21 in wine) (ebp=00000000) Wine-dbg>quit WineDbg terminated on pid 80683b0

1 0

Re: PATCH: include mess up
by Francois Gouget 11 Jul '01

11 Jul '01

On Tue, 10 Jul 2001, Marcus Meissner wrote: > Hi, > > There is some bad recursion when including objbase.h in non-WINE programs. > This fixes that problem, by using winbase.h instead of windows.h. Yes but rpc.h is supposed to include 'windows.h', not 'winbase.h'. The correct fix must be elsewhere. What is the recursion that happens and which include statement (in your application) triggers it? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux: the choice of a GNU generation

2 1

Re: implement overlapped completion routines
by Alexandre Julliard 10 Jul '01

10 Jul '01

Mike McCormack <mike_mccormack(a)start.com.au> writes: > This patch implements overlapped completion routines, and fixes up a > small problem with the overlapped implementation. According to ms > docs, the transfer count should not be stored in the overlapped > structure. Shouldn't you queue an APC instead of calling the completion routine directly? -- Alexandre Julliard julliard(a)winehq.com

1 0

Joysiick under Wine
by David Hagood 10 Jul '01

10 Jul '01

I've seen a couple of messages about getting USB joysticks working under Wine, but do regular (i.e. gameport) sticks work? I've confirmed that my stick is being read by Linux, and that it is reporting events correctly. Now, how do I get Wine to pass them along? I've confirmed: 1) that I have read/write permissions to /dev/js0 2) that Wine tries to read /dev/js0 3) that Wine indeed does read from /dev/js0, but that 4) Wine shortly thereafter closes /dev/js0, never to read it again. Do I need to have the X Window system joystick driver loaded? Or do I need to add something to the system.ini or .wine/config files. This is a Windowless install, under RH6.1, with 2.4.6, and a CVS pull of Wine from a few days ago. I'm trying to get HalfLife running under Wine. I have the GL working, I have sound working, but I am one of those strange fellows that likes to move with a stick, and look with a mouse. Are there any Windows/Wine tools that I can run to try to troubleshoot this?

2 1

Re: some rasapi32 stubs
by Marcus Meissner 10 Jul '01

10 Jul '01

On Tue, Jul 10, 2001 at 10:10:17PM +1000, Mike McCormack wrote: > > ChangeLog: > * dlls/rasapi32/rasapi.c, dlls/rasapi32/rasapi32.spec > Stub some rasapi functions. If you know arguments are strings you can use 'str' instead of 'ptr' in the .spec file, and relay debugging will print strings ;) Also you can use the return value of debugstr_a(a) for string output. Ciao, Marcus

1 0

Re: wv{sn,ns}printf[AW]
by Alexandre Julliard 09 Jul '01

09 Jul '01

Peter Hunnisett <hunnise(a)yahoo.com> writes: > 2) Can wvnsprintf be moved from user32 into shlwapi? This would cause > user32 to have to import shlwapi (because wsprintfA and friends use it > in their implementation) and I don't know if that's legal because user32 > seems to only import gdi32 and kernel32. If not, what's the solution? > Reimplement everything in user32 to not use wvnsprintf and move the > implementation over or just keep the existing situation and rename > wvnsprintf to wvnsprintf and forward the shlwapi calls to user32? user32 cannot import shlwapi, since this would create a circular dependency. Since the functions are needed both in user32 and shlwapi, they have to be implemented in user32 and forwarded from shlwapi to user32 (the alternative is to have two complete wsprintf implementations, which is a bit of a pain). I guess you could also rename the user32 ones, but this is not strictly necessary (and the current name has the advantage of following the C library naming of vsnprintf). -- Alexandre Julliard julliard(a)winehq.com

1 0

wv{sn,ns}printf[AW]
by Peter Hunnisett 09 Jul '01

09 Jul '01

Hi, it appears that we have a bit of a hack in the wine code. Presently we export wvsnprintf[AW] from user32. - These two functions do not appear to be in the real user32.dll and the comments in the code seem to back it up. - Windows does have wvnsprintf[AW] (note the transposed "sn") exported from shlwapi.dll So my questions are: 1) Was the user32 a bit of a hack because those routines just weren't noticed or was it because of something from before shlwapi? 2) Can wvnsprintf be moved from user32 into shlwapi? This would cause user32 to have to import shlwapi (because wsprintfA and friends use it in their implementation) and I don't know if that's legal because user32 seems to only import gdi32 and kernel32. If not, what's the solution? Reimplement everything in user32 to not use wvnsprintf and move the implementation over or just keep the existing situation and rename wvnsprintf to wvnsprintf and forward the shlwapi calls to user32? Thanks, Peter hunnise(a)yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

Re: Are these the ordinal names?
by Alexandre Julliard 08 Jul '01

08 Jul '01

Peter Hunnisett <hunnise(a)yahoo.com> writes: > Howdy, > I have a couple of questions about the following error messages > > err:win32:fixup_imports No implementation for > SHLWAPI.dll.281(wvnsprintfA) imported from > C:\windows\system\shdocvw.dll, setting to 0xdeadbeef > err:win32:fixup_imports No implementation for > SHLWAPI.dll.282(wvnsprintfW) imported from > C:\windows\system\shdocvw.dll, setting to 0xdeadbeef > err:win32:fixup_imports No implementation for > SHLWAPI.dll.240(StrRetToStrW) imported from > C:\windows\system\shdocvw.dll, setting to 0xdeadbeef > > 1) Do these messages mean that 281 is named wvnsprintfA and so on? If > so, why does the SHLWAPI.240 name not seem to jive with the existing > implementation? If a name is specified, the ordinal is only a hint, so it's OK for it to be different. What this means is that in some version of shlwapi StrRetToStrW is at ordinal 240, but it can be at other ordinals in other versions since it is looked up by name. In our builtin version, ordinal 240 is something else (which is fine), and StrRetToStrW is not implemented at all (which is the cause of your problem). You can either implement it, or use the native shlwapi. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: sharing windows between processes
by Alexandre Julliard 08 Jul '01

08 Jul '01

"Bill Medland" <medbi01(a)accpac.com> writes: > Some time ago I raised the issue of the fact that windows handles cannot be > shared between processes on the same server and was told that it was a > known significant issue. > > Is anyone doing anything about it? Sure, that's the main reason behind all the recent window management and messaging changes. So yes, it is being worked on. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Mouse events
by Alexandre Julliard 08 Jul '01

08 Jul '01

Duane Clark <dclark(a)akamail.com> writes: > I assume some problem led to its removal. I regularly try out Myst (the > 32 bit version) as a test, running locally on a 700MHz Athlon, so this > can't be blamed on a slow ethernet connection or slow machine. When > dragging the slide controls in the "planetarium", they used to follow > the mouse just fine. With this patch, if you grab the control, move the > mouse and release it, the control does not keep up with the mouse but > just moves at a moderately slow pace until it reaches the point where > the mouse was released (a few seconds to travel from one end to the > other). At that point everything returns to normal. The new hardware event handling does not yet attempt to merge mouse motion events, so this is probably the reason for the problem. This should be fixed soon. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: printing docu
by Duane Clark 08 Jul '01

08 Jul '01

Andreas Mohr wrote: > Hi all, > > while trying to configure Wine for printing in order to be able to use > Windows Acrobat Reader instead of Linux acroread which is crashing on certain > PDF files, I remembered that the printing docu is everything but perfect. > > Updated printing docu a bit. > > ... > - <sect3> > <title>Spooling</title> > <para> > Spooling is rather primitive. The [spooler] section of > @@ -82,13 +82,14 @@ > example the following lines > </para> > <screen> > -"LPT1:" = "foo.ps" "LPT2:" = "|lpr" > +"LPT1:" = "foo.ps" > +"LPT2:" = "|lpr" > </screen> > <para> > map <systemitem>LPT1:</systemitem> to file <filename>foo.ps</filename> > and <systemitem>LPT2:</systemitem> to the <command>lpr</command> > - command. If a job is sent to an unlisted port then a file is created > - with that port's name e.g. for <systemitem>LPT3:</systemitem> a file > + command. If a job is sent to an unlisted port, then a file is created > + with that port's name; e.g. for <systemitem>LPT3:</systemitem> a file > called <systemitem>LPT3:</systemitem> would be created. > </para> > <para> While it used to work that way, for me at least, the part about - a job that is sent to an unlisted port will create a file with the port's name - stopped working a few months ago. And I just tested it a few minutes ago and it still does not work (for me). I don't know where the data goes, but it does not appear to be written to a file anywhere. Actually, I think that is probably a good thing. In most cases, the print dialog should have a "Print to file" button. And if there is no way to specify a file name, then the ~/.wine/config entry "FILE:" = "foo.ps" will control where it is written, and in this case it will in fact be correctly written to the indicated file name. Duane

1 0

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