April 2004 - wine-devel

Re: abnt2 keyboard patch
by Rafael Ávila de Espíndola 16 Apr '04

16 Apr '04

> I still see problems with your patch. > > 1. You are using 'keysym == 0x2C' for comma, but what happens if NumLock > is on, and you press comma on the main keyboard, not on the keypad? > Shouldn't X11 send XK_KP_xxx event in that case (something like XK_KP_Decimal)? The file /usr/include/X11/keysymdef.h has the line #define XK_KP_Separator 0xFFAC /* separator, often comma */ This appears to be appropriate. But X11 is not sending it in debian (sid) or fedora. The output from xev when, with the numlock initially off, I press comma, kp_comma, numlock, comma and kp_comma is: KeyPress event, serial 22, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69979707, (124,72), root:(364,205), state 0x0, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69979799, (124,72), root:(364,205), state 0x0, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69980420, (124,72), root:(364,205), state 0x0, keycode 91 (keysym 0xff9f, KP_Delete), same_screen YES, XLookupString gives 0 bytes: "" KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69980521, (124,72), root:(364,205), state 0x0, keycode 91 (keysym 0xff9f, KP_Delete), same_screen YES, XLookupString gives 0 bytes: "" KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69980955, (124,72), root:(364,205), state 0x0, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES, XLookupString gives 0 bytes: "" KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69981057, (124,72), root:(364,205), state 0x10, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES, XLookupString gives 0 bytes: "" KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69981755, (124,72), root:(364,205), state 0x10, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69981850, (124,72), root:(364,205), state 0x10, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69982436, (124,72), root:(364,205), state 0x10, keycode 91 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69982535, (124,72), root:(364,205), state 0x10, keycode 91 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," > 2. Please generate unified diffs, 'using diff -u' for patches. Sorry. I am really embarrassed. An unified diff is attached. > > -- > Dmitry. Rafael

2 1

Re: dlls/kernel/console.c::SetConsoleCtrlHandler() cleanup/fixup
by Dimitrie O. Paun 16 Apr '04

16 Apr '04

On April 15, 2004 11:18 am, Peter Riocreux wrote: > * This doesn't yet matter, since these handlers are not yet called...! > + * > + * Peter Riocreux (par(a)silistix.com) 2004-04-15 > + * Added error checking and now uses SetLastError() > */ One more thing: please don't add this sort of thing, it belongs in the CVS log, not in the source code. -- Dimi.

1 0

Re: [D3D8] Add support for vertex shader (using ARB_vertex_program extension)
by Christian Costa 15 Apr '04

15 Apr '04

Maxime Bellengé wrote: >Hi Christian > >Are you looking for someone to test the patch on an NVIDIA card ? >If you tell me how to test or the game to run, I can give you a >feedback. > >a+ > >Max > > > Hi Maxime, You can try the vertexblend, vertexshader & dolphinvs demos from the DX8 SDK. You can switch between HAL to REF devices to see the difference. Thanks for testing! :-) Bye, Christian

1 0

RE: More serial access issues
by Geoffrey Hausheer 15 Apr '04

15 Apr '04

Well, after tracing the events through wineserver, I see 'serial_queue_event' gets called, serial_get_poll_events returns 'POLLOUT', async_notify gets called (but async->thread->wait is 0, so it doesn't do anything besides setting the status to STATUS_ALERTED. The secod serial_get_poll_events returns 0 (due to the status no longer being STATUS_PENDING), but this doesn't really matter as the 'register_async' call doesn't create a reply. Back in my application, __register_async does not reset u.Status (since 'ret' is 0), which means that 'finish_async' never gets called, which appears to be the only way that FILE_AsyncWriteService can be called (which actually does the write) ,and no data is written to the serial port. It all seems to operate as the code dictates, so I'm not sure what the right fix is. It would seem to me that something is not working right in __register_async. Perhaps finish_async should not be gated by 'u.Status'? Or u.Status should unconditionally be set equal to 'ret'? The second seems more likely to me, as that is the only way the WriteFile could return TRUE (in fact I see no way that WriteFile could return true in today's code, regardless of what the server does (since u.Status can only be changed from STATUS_PENDING if ret != 0 (and STATUS_SUCCESS == 0), so u.Status can never equal STATUS_SUCCESS. I am having a lot of difficulty understanding exactly what the server call is doing (I think it is checking that it is clear to write to the Serial port, though it seems to be awfully complex if that is all). Also, I don't know what the conditions are under which finish_async should be called. I changed the code to unconditionally set u.Status = ret, and WriteFile is no longer returning an error, but this didn't help (I'm never seeing FILE_AsyncWriteService get called, because call completion is disabled). So it looks like there are several points that are preventing FILE_AsyncWriteService from being called, and maybe I'm barking up the wrong tree. I can see a few possibilities: (1) some other routine is supposed to do the write, and I'm missing it, or (2) the server is supposed to do the write (perhaps via asyncy_notify?), in which case I don't see any place where the write buffer is passed to the server, or (c) the server is supposed to tell the client to do the write (again by async_notify?), in which case, I'm not seeing how that works. This code seems to run around in circles to me. .Geoff -----Original Message----- From: Geoffrey Hausheer Sent: Wednesday, April 14, 2004 2:05 PM Subject: More serial access issues Well, I broke down and pulled out the oscope and rs232 breakout box to try to figure out why my app isn't able to communicate with the device. turns out that Rein's patch is correctly deasserting DSR, however, I am not getting any data over the Tx pin. And after I checked the output of WriteFile, it is failing. GetLastError doesn't return anything useful (a value of 997 which FormatMessage() can't do anything with). But some debugging led me to determine that NtWriteFile is returning 0x103 which is STATUS_PENDING. After that I'm somewhat lost as to what is going on. Obvioulsy, 'register_new_async' is returning this status, which apparently happens when wine_server_call returns 0 or STATUS_PENDING (not sure if the second is even possible). But about here I am getting completely confused as to what we are trying to accomplish. The file is opened via: CreateFile("COM1", 0, NULL, OPEN_EXISTING, 0, NULL) so we're not in overlapped mode. SetCommTimeout is called with the COMMTIMEOUTS structure containing all 0s. All flow control is disabled using SetCommState. Before a write, we always call 'PurgeComm' and ClearCommError. In Windows, this combination results in a write always occurring when WriteFile is called, regardless of whether there is anything connected to the serial port. Wine appears to be waiting for something, and I'm not sure what. If anyone has any ideas how I might proceed, i'd be glad to hear them. Thanks, .Geoff

1 0

Compiling MFC with latest CVS checkout.
by Manjunath Sripadarao 15 Apr '04

15 Apr '04

I am trying to compile MFC with latest CVS checout, I copied the source from the windows MFC dir and also the include dir (both for MFC and the VC98 include dir). I ran winemaker --interactive . and specified the -I paths. I got a couple of makefiles. Now if I do a make I get this error. [manju@manju MSVS]$ make make[1]: Entering directory `/home/manju/MSVS/mfc/src' wineg++ -mwindows -mno-cygwin -o mfcdb.so mfcdb.res mfcdb.dbg.o -lodbc32 -lole32 -loleaut32 -lwinspool -luuid mfcdb.exe-ueIUVp.spec.c:451: error: invalid conversion from `void (*)()' to ` void*' winegcc: gcc failed. make[1]: *** [mfcdb.so] Error 2 make[1]: Leaving directory `/home/manju/MSVS/mfc/src' make: *** [mfc/src] Error 2 Any ideas/tips. Am I even following the correct procedure ? There doesn't seem to be any document detailing this process. Any tips/instructions/suggestions would be greatly appreciated. I am doing this on a fedora core 1 (with prelink fixed and stuff, wine runs well), with a 2 Ghz P4 machine. If any other info is needed please feel free. Thanks in advance, Manju

3 3

wine/tools wineinstall
by Saulius Krasuckas 15 Apr '04

15 Apr '04

> Log message: > Only create the device symlinks the first time around. <skipped /> > + # Check if dosdevices exists and create it if necessary > + if [ ! -d ~/.wine/dosdevices ] > + then > + mkdir ~/.wine/dosdevices > + ln -s /mnt/fd0 ~/.wine/dosdevices/a: > + ln -s $CROOT ~/.wine/dosdevices/c: Alexandre, what about the case when ~/.wine/dosdevices exists but is empty? PS eghm, should it be bad for wineinstall and winecfg to share common code for creating links in dosdevices/ ?

2 1

help fixing up SetConsoleCtrlHandler()
by Peter Riocreux 15 Apr '04

15 Apr '04

Having seen a lot of messages like: ----------------- fixme:console:SetConsoleCtrlHandler (0x41a8af,1) - no error checking or testing yet ----------------- lately, I thought I would actually see if I could fix it up and remove the FIXME. It is in dlls/kernel/console.c, and the MSDN reference is at <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba…>. I think it is obvious enough that even I, a Wine newbie could do it, except for a couple of things that, as a newbie, are not obvious to me. Please point me at docs if this is covered somewhere - it is hard getting into a new project .... 1) If I am using SetLastError, it is not obvious to me what error values I should be using there. I assume there is a generic couldnt-allocate-on-heap error, but other causes of error are specific to the function, and I cannot find any documentation. Should I just use a non-zero error number and put FIXMEs in for any number I had to invent? 2) Can I assume that Rtl{Enter,Leave}CriticalSection(), HeapFree(), ERR() and WARN() cannot fail (the latter two are presumably macros). 3) The docs say that it behaves eeeeeeever so slightly differently in ME/98/95 than in others. In this case it is simply that one of the arguments may not be NULL. Should I, either in general, or in this case in particular, detect which Windows version is being used and behave appropriately, or implement the more flexible approach and assume that people writing for the more restricted OS will not have used that case. If I shoudl detect, how does one go about this? Peter

3 6

Re: Who's who - Blowing my own horn.
by Kevin Koltzau 15 Apr '04

15 Apr '04

On Wednesday 14 April 2004 10:48 pm, Tony Lambregts wrote: > Blowing my own horn. ... > + <td width="300">Location: St. Albert, Alberta, Canada </td> > + <td>IRC Nick: tindalos</td></tr> Thats my IRC nick :)

1 0

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 15 Apr '04

15 Apr '04

Actually there is WM_GETMINMAXINFO which comes before WM_NCCREATE but I dont think we should put the DIALOGINFO initialization logic there. WM_NCCREATE should be the better option. Regards Santosh Siddheshwar > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry@baikal.ru] > Sent: Thursday, April 15, 2004 3:56 PM > To: Santosh Siddheshwar; Alexandre Julliard > Cc: Robert Shearman; wine-devel(a)winehq.org > Subject: Re: Handling dialog messages for non-template based dialogs > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > OK.One place where this could be done is WM_NCCREATE which comes before > > WM_CREATE. Other place (possibly better) where it might be possible to > do > > this is in CBTProc hook procedure. Not sure about the second option > though. > > Any thoughts? > > I'll add a test case for it in our message test suite. > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

1 0

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 15 Apr '04

15 Apr '04

OK.One place where this could be done is WM_NCCREATE which comes before WM_CREATE. Other place (possibly better) where it might be possible to do this is in CBTProc hook procedure. Not sure about the second option though. Any thoughts? Regards Santosh Siddheshwar > -----Original Message----- > From: Alexandre Julliard [SMTP:julliard@winehq.org] > Sent: Thursday, April 15, 2004 9:43 AM > To: Santosh Siddheshwar > Cc: Dmitry Timoshkov; Robert Shearman; wine-devel(a)winehq.org > Subject: Re: Handling dialog messages for non-template based dialogs > > Santosh Siddheshwar <santosh.s(a)sonata-software.com> writes: > > > But dont you think that the structure is not really required till the > > window has been created successfully? > > Well, I don't think so, but the only way to know for sure is to write > a test program under Windows to determine the exact behavior. > > -- > Alexandre Julliard > julliard(a)winehq.org ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

Problem with bad generation of low-level keyboard events
by Lionel Ulmer 15 Apr '04

15 Apr '04

Hi all, While debugging GeneRally (a very nice game), I got some problems with DInput receiving spurious events (basically, as if key '0' was pressed). This is traced to the following problem : In windows/input.c, the function 'queue_kbd_event' stores the KBDLLHOOKSTRUCT structure on the stack and then calls 'HOOK_CallHooks' to send it. In my case, thread 000a receives the event and sends it to thread 0009. What happens is the following (the 'Hook:' lines were added by me) : 000a:trace:hook:HOOK_CallHooks calling hook in thread 0009 WH_KEYBOARD_LL code 0 wp 101 lp 4156ad6c 000a:trace:hook:HOOK_CallHooks Hook: 0x4156ad6c - 00000026 00000048 000000c1 0000b578 00000000 000a:trace:msg:send_inter_thread_message hwnd (nil) msg 80000007 ("#7") wp 101 lp 4156ad6c 000a: send_message( id=0009, type=1, flags=1, win=(nil), msg=80000007, wparam=00000101, lparam=4156ad6c, x=0, y=0, time=0000b587, info=00000000, timeout=2000, callback=(nil), data={} ) 000a: send_message() = 0 000a: set_queue_mask( wake_mask=00008040, changed_mask=00008040, skip_wait=1 ) 000a: set_queue_mask() = 0 { wake_bits=00000000, changed_bits=00000000 } 000a: select( flags=4, cookie=0x4156a578, timeout=0, handles={0x50} ) 000a: select() = PENDING 0009: get_handle_fd( handle=0xc0, access=80000000 ) 0009: get_handle_fd() = 0 { fd=33, type=1, flags=0 } (...) 0009:trace:ddraw:Main_DirectDrawSurface_Lock locked surface returning description : - DDSD_CAPS : DDSCAPS_OFFSCREENPLAIN DDSCAPS_VIDEOMEMORY (...) 000a: *wakeup* signaled=0 cookie=0x4156a578 000a: set_queue_mask( wake_mask=00008040, changed_mask=00008040, skip_wait=1 ) 000a: set_queue_mask() = 0 { wake_bits=00008000, changed_bits=00008000 } 000a: get_message_reply( cancel=1 ) 000a: get_message_reply() = TIMEOUT { result=00000000, data={} } 000a:trace:msg:retrieve_reply hwnd (nil) msg 80000007 ("#7") wp 101 lp 4156ad6c got reply 40218182 (err=258) 000a: finish_hook_chain( id=13 ) 000a: finish_hook_chain() = 0 000a:trace:key:queue_kbd_event Hook: 1) 0x4156ad6c - 00000026 00000048 000000c1 0000b578 00000000 000a: send_message( id=000a, type=7, flags=0, win=(nil), msg=00000101, wparam=00000026, lparam=c1480001, x=691, y=584, time=0000b578, info=00000000, timeout=-1, callback=(nil), data={} ) 000a: send_message() = 0 000a:trace:key:queue_kbd_event Hook: 2) 0x4156ad6c - 00000026 00000048 000000c1 0000b578 00000000 000a:trace:event:EVENT_ProcessEvent returns. (...) 0009: select( flags=12, cookie=0x4069f890, timeout=1081894976.490610 (-0.000077), handles={0x3c} ) 0009: select() = TIMEOUT 0009: get_message( flags=1, get_win=(nil), get_first=00000000, get_last=ffffffff ) 0009: get_message() = 0 { type=1, win=(nil), msg=80000007, wparam=00000101, lparam=4156ad6c, x=0, y=0, time=0000b587, info=00000000, total=0, data={} } 0009:trace:msg:MSG_peek_message got type 1 msg 80000007 ("#7") hwnd (nil) wp 101 lp 4156ad6c 0009: start_hook_chain( id=13 ) 0009: start_hook_chain() = 0 { handle=0x10022, pid=0000, tid=0000, proc=0x40cd4c70, unicode=1, module=L"" } 0009:trace:hook:HOOK_CallHooks calling hook 0x40cd4c70 WH_KEYBOARD_LL code 0 wp 101 lp 4156ad6c module L"" 0009:trace:hook:HOOK_CallHooks Hook: 0x4156ad6c - 4156ad88 00000000 00000040 4156ad8c 4156ad88 A summary of my understanding of the problem : - in 'queue_kbd_event', the structure is put on the stack on the expectation that the 'HOOK_CallHooks' won't return with the message unsent. - as seen, because the thread which receives the message does not seem to handle any messages during quite a long time (it's actually loading the track between two races), this message sending time-outs on the sender's side. - so the function 'queue_kbd_event' ends and the stack gets corrupted. - which can be seen in my last 'Hook:' dump. If it's normal for the sending to time-out, we should replace this code and add some HeapAlloc on the sender side and some HeapFree on the receiver side each time such a structure is sent ... Which will be a bit problematic for performance, but well, I do not see any other way to correct this. Lionel -- Lionel Ulmer - http://www.bbrox.org/

2 2

exec-shield patch take 5
by Mike McCormack 15 Apr '04

15 Apr '04

Hi, Here's the latest version of a patch I've written to allow wine to run without disabling exec-shield or prelinking. Mike Changes in version 5: * reserve the shared heap area as well as the PE load area * allow multiple reserve areas in libwine Changes in version 4: * set the WINEPEEXEPATH environment variable correctly Changes in version 3: * reserve only the area required by the PE EXE if launched from CreateProcess (else just a default slab) * pass the reserved area to wine, so wine knows about it * unmap the preloader after it is no longer used Changes in verison 2: * replace the shared object loader instead of using a bootstrap exe Version 1: * create a bootstrap exe that reserves memory before loading wine-pthread or wine-kthread Index: dlls/kernel/process.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/process.c,v retrieving revision 1.52 diff -u -r1.52 process.c --- dlls/kernel/process.c 14 Apr 2004 19:40:54 -0000 1.52 +++ dlls/kernel/process.c 15 Apr 2004 07:46:25 -0000 @@ -917,8 +917,6 @@ } found: - wine_free_pe_load_area(); /* the main binary is loaded, we don't need this anymore */ - /* build command line */ set_library_wargv( __wine_main_argv ); if (!build_command_line( __wine_main_wargv )) goto error; @@ -1060,7 +1058,8 @@ * * Build the environment of a new child process. */ -static char **build_envp( const WCHAR *envW, const WCHAR *extra_envW ) +static char **build_envp( const WCHAR *envW, const WCHAR *extra_envW, + const char *workdir, const char *unixpath ) { const WCHAR *p; char **envp; @@ -1083,7 +1082,7 @@ if (!(env = malloc( length ))) return NULL; WideCharToMultiByte( CP_UNIXCP, 0, envW, p - envW, env, length, NULL, NULL ); - count += 4; + count += 6; if ((envp = malloc( count * sizeof(*envp) ))) { @@ -1098,6 +1097,11 @@ if ((p = getenv("TMP"))) *envptr++ = alloc_env_string( "TMP=", p ); if ((p = getenv("HOME"))) *envptr++ = alloc_env_string( "HOME=", p ); if ((p = getenv("WINEPREFIX"))) *envptr++ = alloc_env_string( "WINEPREFIX=", p ); + + /* record the unix working directory */ + if (workdir) *envptr++ = alloc_env_string( "WINEWORKDIR=", workdir ); + if (workdir) *envptr++ = alloc_env_string( "WINEPEEXEPATH=", unixpath ); + /* now put the Windows environment strings */ for (p = env; *p; p += strlen(p) + 1) { @@ -1106,6 +1110,8 @@ if (is_special_env_var( p )) /* prefix it with "WINE" */ *envptr++ = alloc_env_string( "WINE", p ); else if (strncmp( p, "HOME=", 5 ) && + strncmp( p, "WINEWORKDIR=", 12 ) && + strncmp( p, "WINEPEEXEPATH=", 14 ) && strncmp( p, "WINEPREFIX=", 11 )) *envptr++ = p; } *envptr = 0; @@ -1136,7 +1142,7 @@ if (!(pid = fork())) /* child */ { char **argv = build_argv( cmdline, 0 ); - char **envp = build_envp( env, NULL ); + char **envp = build_envp( env, NULL, NULL, NULL ); close( fd[0] ); /* Reset signals that we previously set to SIG_IGN */ @@ -1171,14 +1177,8 @@ RTL_USER_PROCESS_PARAMETERS *params; UNICODE_STRING image_str, cmdline_str, desktop, title; NTSTATUS status; - WCHAR buffer[MAX_PATH]; - - if(!GetLongPathNameW( filename, buffer, MAX_PATH )) - lstrcpynW( buffer, filename, MAX_PATH ); - if(!GetFullPathNameW( buffer, MAX_PATH, buffer, NULL )) - lstrcpynW( buffer, filename, MAX_PATH ); - RtlInitUnicodeString( &image_str, buffer ); + RtlInitUnicodeString( &image_str, filename ); RtlInitUnicodeString( &cmdline_str, cmdline ); if (startup->lpDesktop) RtlInitUnicodeString( &desktop, startup->lpDesktop ); if (startup->lpTitle) RtlInitUnicodeString( &title, startup->lpTitle ); @@ -1230,6 +1230,7 @@ pid_t pid; int err; char dummy = 0; + WCHAR buffer[MAX_PATH]; if (!env) { @@ -1237,7 +1238,12 @@ extra_env = DRIVE_BuildEnv(); } - if (!(params = create_user_params( filename, cmd_line, startup ))) + if(!GetLongPathNameW( filename, buffer, MAX_PATH )) + lstrcpynW( buffer, filename, MAX_PATH ); + if(!GetFullPathNameW( buffer, MAX_PATH, buffer, NULL )) + lstrcpynW( buffer, filename, MAX_PATH ); + + if (!(params = create_user_params( buffer, cmd_line, startup ))) { if (extra_env) HeapFree( GetProcessHeap(), 0, extra_env ); return FALSE; @@ -1268,7 +1274,20 @@ if (!(pid = fork())) /* child */ { char **argv = build_argv( cmd_line, 1 ); - char **envp = build_envp( env, extra_env ); + char **envp; + char *unixpath; + + unixpath = wine_get_unix_file_name( buffer ); + + /* preseve the current directory, the preloader may forget it */ + if( !unixdir ) + { + char *dir = HeapAlloc( GetProcessHeap(), 0, MAX_PATH ); + getcwd( dir, MAX_PATH ); + unixdir = dir; + } + envp = build_envp( env, extra_env, unixdir, unixpath ); + HeapFree( GetProcessHeap(), 0, unixpath ); close( startfd[1] ); close( execfd[0] ); @@ -1280,8 +1299,6 @@ /* Reset signals that we previously set to SIG_IGN */ signal( SIGPIPE, SIG_DFL ); signal( SIGCHLD, SIG_DFL ); - - if (unixdir) chdir(unixdir); if (argv && envp) { Index: libs/wine/config.c =================================================================== RCS file: /home/wine/wine/libs/wine/config.c,v retrieving revision 1.3 diff -u -r1.3 config.c --- libs/wine/config.c 11 Nov 2003 22:21:29 -0000 1.3 +++ libs/wine/config.c 15 Apr 2004 07:46:31 -0000 @@ -243,6 +243,23 @@ return user_name; } +/* run wine binary in it's own directory, so it can find it's preloader */ +int wine_cwd_execve( const char *name, char **argv, char **envp ) +{ + char *dir, *p; + + dir = strdup( name ); + p = strrchr( dir, '/' ); + if( p ) + { + *p++ = 0; + chdir( dir ); + name = p; + } + + return execve( name, argv, envp ); +} + /* exec a wine internal binary (either the wine loader or the wine server) */ /* if name is null, default to the name of the current binary */ void wine_exec_wine_binary( const char *name, char **argv, char **envp ) @@ -257,7 +274,7 @@ argv[0] = xmalloc( sizeof(BINDIR "/") + strlen(name) ); strcpy( argv[0], BINDIR "/" ); strcat( argv[0], name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); free( argv[0] ); /* now try the path of argv0 of the current binary */ @@ -266,7 +283,7 @@ argv[0] = xmalloc( strlen(argv0_path) + strlen(name) + 1 ); strcpy( argv[0], argv0_path ); strcat( argv[0], name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); free( argv[0] ); } @@ -283,7 +300,7 @@ memcpy( argv[0], pos, ptr - pos ); strcpy( argv[0] + (ptr - pos), "/" ); strcat( argv[0] + (ptr - pos), name ); - execve( argv[0], argv, envp ); + wine_cwd_execve( argv[0], argv, envp ); pos = ptr; } free( argv[0] ); Index: libs/wine/port.c =================================================================== RCS file: /home/wine/wine/libs/wine/port.c,v retrieving revision 1.8 diff -u -r1.8 port.c --- libs/wine/port.c 5 Feb 2004 02:01:35 -0000 1.8 +++ libs/wine/port.c 15 Apr 2004 07:46:31 -0000 @@ -150,36 +150,63 @@ #error You must implement wine_switch_to_stack for your platform #endif +struct reserve_area +{ + char *base; + size_t size; + struct reserve_area *next; +}; -static char *pe_area; -static size_t pe_area_size; +struct reserve_area *reserve_list; /*********************************************************************** - * wine_set_pe_load_area + * wine_reserve_area * - * Define the reserved area to use for loading the main PE binary. + * Define a reserved area (for the PE binary and system heap) + * These function are not thread safe, so we assume that + * they're called before any threads are started, and all the + * reserve areas are free'd. */ -void wine_set_pe_load_area( void *base, size_t size ) +void wine_reserve_area( void *base, size_t size ) { + struct reserve_area *area; unsigned int page_mask = getpagesize() - 1; char *end = (char *)base + size; - pe_area = (char *)(((unsigned long)base + page_mask) & ~page_mask); - pe_area_size = (end - pe_area) & ~page_mask; + area = malloc( sizeof (struct reserve_area) ); + + area->base = (char *)(((unsigned long)base + page_mask) & ~page_mask); + area->size = (end - area->base) & ~page_mask; + + area->next = reserve_list; + reserve_list = area; } /*********************************************************************** - * wine_free_pe_load_area + * wine_free_area * - * Free the reserved area to use for loading the main PE binary. + * Free a reserved area. */ -void wine_free_pe_load_area(void) +int wine_free_area( char *start, size_t size ) { + struct reserve_area *area, **p; + + for( p = &reserve_list; (area = *p); p = &area->next ) + if( start >= area->base && start + size <= area->base + area->size) + break; + + if( !area ) + return 0; + + *p = area->next; + #ifdef HAVE_MMAP - if (pe_area) munmap( pe_area, pe_area_size ); + munmap( area->base, area->size ); #endif - pe_area = NULL; + + free( area ); + return 1; } @@ -296,13 +323,8 @@ flags |= MAP_PRIVATE; #endif - if (pe_area && start && - (char *)start >= pe_area && - (char *)start + size <= pe_area + pe_area_size) - { - wine_free_pe_load_area(); + if ( start && reserve_list && wine_free_area(start, size) ) flags |= MAP_FIXED; - } if (!(flags & MAP_FIXED)) { Index: libs/wine/wine.def =================================================================== RCS file: /home/wine/wine/libs/wine/wine.def,v retrieving revision 1.10 diff -u -r1.10 wine.def --- libs/wine/wine.def 5 Feb 2004 02:01:35 -0000 1.10 +++ libs/wine/wine.def 15 Apr 2004 07:46:31 -0000 @@ -64,5 +64,5 @@ wine_pthread_init_thread wine_set_fs wine_set_gs - wine_set_pe_load_area + wine_reserve_area wine_switch_to_stack Index: libs/wine/wine.map =================================================================== RCS file: /home/wine/wine/libs/wine/wine.map,v retrieving revision 1.1 diff -u -r1.1 wine.map --- libs/wine/wine.map 12 Feb 2004 22:54:00 -0000 1.1 +++ libs/wine/wine.map 15 Apr 2004 07:46:31 -0000 @@ -64,7 +64,7 @@ wine_pthread_init_thread; wine_set_fs; wine_set_gs; - wine_set_pe_load_area; + wine_reserve_area; wine_switch_to_stack; local: *; Index: loader/Makefile.in =================================================================== RCS file: /home/wine/wine/loader/Makefile.in,v retrieving revision 1.14 diff -u -r1.14 Makefile.in --- loader/Makefile.in 22 Nov 2003 00:08:26 -0000 1.14 +++ loader/Makefile.in 15 Apr 2004 07:46:31 -0000 @@ -23,20 +23,30 @@ LIBPTHREAD = @LIBPTHREAD@ LDEXECFLAGS = @LDEXECFLAGS@ -wine-glibc: glibc.o Makefile.in +WINELDEXECFLAGS = $(LDEXECFLAGS),--dynamic-linker=$(WINELDSO) + +WINELDSO=ld-winepreload.so + +$(WINELDSO): preload.o Makefile.in + $(CC) -nostartfiles -lc -static -Wl,"-Ttext=0x7ff81000" -o $@ $< + +preload.c: preload.h main.h + +wine-glibc: glibc.o Makefile.in $(WINELDSO) $(CC) -o $@ $(LDEXECFLAGS) glibc.o $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) -wine-kthread: $(KTHREAD_OBJS) Makefile.in - $(CC) -o $@ $(LDEXECFLAGS) $(KTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(EXTRALIBS) $(LDFLAGS) +wine-kthread: $(KTHREAD_OBJS) Makefile.in $(WINELDSO) + $(CC) -o $@ $(WINELDEXECFLAGS) $(KTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(EXTRALIBS) $(LDFLAGS) -wine-pthread: $(PTHREAD_OBJS) Makefile.in - $(CC) -o $@ $(LDEXECFLAGS) $(PTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) +wine-pthread: $(PTHREAD_OBJS) Makefile.in $(WINELDSO) + $(CC) -o $@ $(WINELDEXECFLAGS) $(PTHREAD_OBJS) $(LIBWINE) $(LIBPORT) $(LIBPTHREAD) $(EXTRALIBS) $(LDFLAGS) $(MODULE): $(MAIN_BINARY) $(RM) $(MODULE) && $(LN_S) $(MAIN_BINARY) $(MODULE) install:: $(WINE_BINARIES) $(MKINSTALLDIRS) $(bindir) + $(INSTALL_PROGRAM) $(WINELDSO) $(bindir); \ for f in $(WINE_BINARIES); do \ if [ "$(MAIN_BINARY)" = "$$f" ]; \ then $(INSTALL_PROGRAM) $$f $(bindir)/$(MODULE); \ @@ -48,6 +58,6 @@ $(RM) $(WINE_BINARIES:%=$(bindir)/%) $(bindir)/$(MODULE) clean:: - $(RM) $(WINE_BINARIES) $(MODULE) + $(RM) $(WINE_BINARIES) $(MODULE) $(WINELDSO) ### Dependencies: Index: loader/glibc.c =================================================================== RCS file: /home/wine/wine/loader/glibc.c,v retrieving revision 1.3 diff -u -r1.3 glibc.c --- loader/glibc.c 20 Feb 2004 20:19:23 -0000 1.3 +++ loader/glibc.c 15 Apr 2004 07:46:31 -0000 @@ -75,6 +75,17 @@ { const char *loader = getenv( "WINELOADER" ); const char *threads = get_threading(); + char cwd[MAX_PATH], *cwd_var; + + if( !getcwd( cwd, sizeof cwd ) ) + { + fprintf( stderr, "wine: could get current directory\n" ); + exit(1); + } + cwd_var = xmalloc( sizeof("WINEWORKDIR=") + strlen(cwd) ); + strcpy( cwd_var, "WINEWORKDIR=" ); + strcat( cwd_var, cwd ); + putenv( cwd_var ); if (loader) { @@ -86,6 +97,9 @@ new_name = xmalloc( (path - loader) + strlen(threads) + 1 ); memcpy( new_name, loader, path - loader ); + new_name[ path - loader ] = 0; + if( new_name[0] ) + chdir( new_name ); strcpy( new_name + (path - loader), threads ); /* update WINELOADER with the new name */ Index: loader/main.c =================================================================== RCS file: /home/wine/wine/loader/main.c,v retrieving revision 1.90 diff -u -r1.90 main.c --- loader/main.c 20 Jan 2004 00:28:01 -0000 1.90 +++ loader/main.c 15 Apr 2004 07:46:31 -0000 @@ -20,19 +20,54 @@ #include <stdio.h> #include <stdlib.h> +#include <unistd.h> +#include <sys/mman.h> #include "wine/library.h" +#include "main.h" + +extern void wine_reserve_area( void *base, size_t size ); + +/* this variable is set by the wine-specific shared object loader */ +struct wine_preload_info *wine_preload_vars; + /********************************************************************** * main */ int main( int argc, char *argv[] ) { - char error[1024]; + char error[1024], *dir; + if( wine_preload_vars ) + { #if 0 - static char pe_load[256*1024*1024] __attribute__((aligned(4096))); - wine_set_pe_load_area( pe_load, sizeof(pe_load) ); + printf("vars(*%p) = %p -> (%p, %08x) (%p, %08x) (%p, %08x)\n", + &wine_preload_vars, wine_preload_vars, + wine_preload_vars->pe_address, + wine_preload_vars->pe_size, + wine_preload_vars->heap_address, + wine_preload_vars->heap_size, + wine_preload_vars->preload_base, + wine_preload_vars->preload_size ); #endif + + /* let wine know which area was mapped for the PE EXE */ + wine_reserve_area( wine_preload_vars->pe_address, + wine_preload_vars->pe_size); + + /* let wine know which area was mapped for the system heap */ + wine_reserve_area( wine_preload_vars->heap_address, + wine_preload_vars->heap_size); + + /* unmap the preloader itself */ + munmap( wine_preload_vars->preload_base, + wine_preload_vars->preload_size ); + wine_preload_vars = NULL; + } + + dir = getenv( "WINEWORKDIR" ); + if( dir ) + chdir( dir ); wine_init( argc, argv, error, sizeof(error) ); fprintf( stderr, "wine: failed to initialize: %s\n", error ); --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ loader/main.h 2004-04-15 17:29:17.000000000 +0900 @@ -0,0 +1,10 @@ + +struct wine_preload_info +{ + void *pe_address; + size_t pe_size; + void *heap_address; + size_t heap_size; + void *preload_base; + size_t preload_size; +}; --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ loader/preload.h 2004-04-15 17:29:17.000000000 +0900 @@ -0,0 +1,51 @@ +/* + mini loader for ld.so - x86 Linux 2.4.x+ kernels only + + Copyright 2004 Mike McCormack for Codeweavers + + Copyright (C) 1995,96,97,98,99,2000,2001,2002 Free Software Foundation, Inc. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. + */ + +#define LDSO_NAME "/lib/ld-linux.so.2" + +/* ELF definitions */ +#define ELF_PREFERRED_ADDRESS(loader, maplength, mapstartpref) (mapstartpref) +#define ELF_FIXED_ADDRESS(loader, mapstart) ((void) 0) + +#define __ELF_NATIVE_CLASS 32 +#define MAP_BASE_ADDR(l) 0 +#define MAP_COPY MAP_PRIVATE +#define ANONFD -1 + +#define ElfW(type) _ElfW (Elf, __ELF_NATIVE_CLASS, type) +#define _ElfW(e,w,t) _ElfW_1 (e, w, _##t) +#define _ElfW_1(e,w,t) e##w##t + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <unistd.h> +#include <sys/mman.h> +#include <sys/types.h> +#include <sys/stat.h> +#include <fcntl.h> + +#define GL(x) x + +extern unsigned int GL(dl_pagesize); + --- /dev/null 1994-07-18 08:46:18.000000000 +0900 +++ loader/preload.c 2004-04-15 17:29:17.000000000 +0900 @@ -0,0 +1,749 @@ +/* + mini loader for ld.so - x86 Linux 2.4.x+ kernels only + + Copyright 2004 Mike McCormack for Codeweavers + + Copyright (C) 1995,96,97,98,99,2000,2001,2002 Free Software Foundation, Inc. + + The GNU C Library is free software; you can redistribute it and/or + modify it under the terms of the GNU Lesser General Public + License as published by the Free Software Foundation; either + version 2.1 of the License, or (at your option) any later version. + + The GNU C Library is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public + License along with the GNU C Library; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA + 02111-1307 USA. + */ + +/* + * Design notes + * + * The goal of this program is to be a workaround for exec-shield, as used + * by the Linux kernel distributed with Fedora Core and other distros. + * + * To do this, we implement our own shared object loader that reserves memory + * that is important to Wine, and then loads the the standard shared object + * loader (ELF interpreter), usually ld-linux.so.2 + * + * This program will be invoked by linking it as the shared object loader + * using the link time flags --shared-loader=ld-winepreload.so . Since we + * are not using an absolute path, an executable using this shared object + * loader must be invoked from the directory that contains this loader. + * + * We will try to set up the stack an memory area so that the program that + * loads after us (eg. the wine binary) never knows we were here, except that + * areas of memory it needs are already magically reserved. + * + * The following memory areas are important to Wine: + * 0x00000000 - the DOS area + * 0x00400000 - the standard Win32 load address + * 0x65430000 - the shared heap + * + * If this program is used as the shared object loader. the only difference + * that the loaded programs should see is that this loader will be mapped + * into memory when it starts. + * + * Limitations: + * * using a non-absolution path for the shared object loader is not standard + */ + +/* + * References (things I consulted to understand how ELF loading works): + * + * glibc 2.3.2 elf/dl-load.c + * http://www.gnu.org/directory/glibc.html + * + * Linux 2.6.4 fs/binfmt_elf.c + * ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-2.6.4.tar.bz2 + * + * Userland exec, by <grugq(a)hcunix.net> + * http://cert.uni-stuttgart.de/archive/bugtraq/2004/01/msg00002.html + * + * The ELF specification: + * http://www.linuxbase.org/spec/booksets/LSB-Embedded/LSB-Embedded/book387.ht… + */ + +#include "preload.h" +#include "main.h" +#include <elf.h> + +/* the following headers are needed to get the definition for IMAGE_NT_HEADERS */ +#include <stdarg.h> +#include "windef.h" +#include "winbase.h" + +/* debugging */ +#undef DUMP_SEGMENTS +#undef DUMP_ARG +#undef DUMP_AUX_INFO +#undef DUMP_SYMS +#undef DUMP_PERESERVE + +/* older systems may not define these */ +#ifndef PT_TLS +#define PT_TLS 7 +#endif +#ifndef PT_GNU_EH_FRAME +#define PT_GNU_EH_FRAME 0x6474e550 +#endif +#ifndef PT_GNU_STACK +#define PT_GNU_STACK 0x6474e551 +#endif +#ifndef PT_GNU_RELRO +#define PT_GNU_RELRO 0x6474e552 +#endif + +unsigned int GL(dl_pagesize) = 0x0000; +extern const unsigned char _end[]; + +struct link_map { + ElfW(Addr) l_addr; + ElfW(Dyn) *l_ld; + const ElfW(Phdr) *l_phdr; + ElfW(Addr) l_entry; + ElfW(Half) l_ldnum; + ElfW(Half) l_phnum; + ElfW(Addr) l_map_start, l_map_end; +}; + +/* + * wld_printf - just the basics + * + * %x prints a hex number + * %s prints a string + */ +void wld_sprintf(char *str, char *fmt, int *args ) +{ + char *p = fmt; + + while( *p ) + { + if( *p == '%' ) + { + p++; + if( *p == 'x' ) + { + int ch, i, x = *++args; + for(i=7; i>=0; i--) + { + ch = (x>>(i*4))&0xf; + ch += '0'; + if(ch>'9') + ch+=('A'-10-'0'); + *str++ = ch; + } + } + else if( *p == 's' ) + { + char *s = (char*)*++args; + while(*s) + *str++ = *s++; + } + else if( *p == 0 ) + break; + p++; + } + *str++ = *p++; + } + *str = 0; +} + +int wld_strlen(char *str) +{ + int n = 0; + while( str[n] ) + n++; + return n; +} + +void wld_printf(char *fmt, ... ) +{ + char buffer[100]; + int n; + + buffer[0]=0; + wld_sprintf(buffer, fmt, (int*)&fmt ); + n = wld_strlen( buffer ); + write(2, buffer, n); +} + +void wld_strncpy(char *dest, char *src, int count ) +{ + while( (*dest++ = *src++) && --count ) + ; + *dest = 0; +} + +void wld_memset( unsigned char *buf, int val, size_t len ) +{ + while( len-- ) + *buf++=val; +} + +#ifdef DUMP_AUX_INFO +/* + * Dump interesting bits of the ELF auxv_t structure that is passed + * as the 4th parameter to the _start function + */ +static void wld_dump_auxilary( ElfW(auxv_t) *av ) +{ + for ( ; av->a_type != AT_NULL; av++) + switch (av->a_type) + { + case AT_PAGESZ: + wld_printf("AT_PAGESZ = %x\n",av->a_un.a_val); + break; + case AT_PHDR: + wld_printf("AT_PHDR = %x\n",av->a_un.a_ptr); + break; + case AT_PHNUM: + wld_printf("AT_PHNUM = %x\n",av->a_un.a_val); + break; + case AT_ENTRY: + wld_printf("AT_ENTRY = %x\n",av->a_un.a_val); + break; + case AT_BASE: + wld_printf("AT_BASE = %x\n",av->a_un.a_val); + break; + } +} +#endif + +/* + * wld_set_auxilary + * + * Set a field of the auxillary structure + */ +void wld_set_auxilary( ElfW(auxv_t) *av, int type, long int val ) +{ + for ( ; av->a_type != AT_NULL; av++) + if( av->a_type == type ) + av->a_un.a_val = val; +} + +/* + * wld_get_auxilary + * + * Get a field of the auxillary structure + */ +int wld_get_auxilary( ElfW(auxv_t) *av, int type, int *val ) +{ + for ( ; av->a_type != AT_NULL; av++) + if( av->a_type == type ) + { + *val = av->a_un.a_val; + return 1; + } + return 0; +} + +/* + * wld_map_so + * + * modelled after _dl_map_object_from_fd() from glibc-2.3.1/elf/dl-load.c + * + * This function maps the segments from an ELF object, and optionally + * stores information about the mapping into the auxv_t structure. + */ +void* wld_map_so( int fd, void* buf, size_t buflen, struct link_map *l) +{ + ElfW(Ehdr) *header = buf; + ElfW(Phdr) *phdr, *ph; + /* Scan the program header table, collecting its load commands. */ + struct loadcmd + { + ElfW(Addr) mapstart, mapend, dataend, allocend; + off_t mapoff; + int prot; + } loadcmds[header->e_phnum], *c; + size_t nloadcmds = 0, maplength; + + header = buf; + phdr = (void*) (((unsigned char*)buf) + header->e_phoff); + + if( header->e_ident[0] != 0x7f && + header->e_ident[0] != 'E' && + header->e_ident[0] != 'L' && + header->e_ident[0] != 'F' ) + { + wld_printf("Not an ELF binary... don't know how to load it\n"); + return NULL; + } + + if( header->e_machine != EM_386 ) + { + wld_printf("Not an i386 ELF binary... don't know how to load it\n"); + return NULL; + } + + maplength = header->e_phnum * sizeof (ElfW(Phdr)); + if (header->e_phoff + maplength > (size_t) buflen) + { + wld_printf("oops... not enough space for ELF headers\n"); + exit(1); + } + + l->l_ld = 0; + l->l_addr = 0; + l->l_phnum = header->e_phnum; + l->l_entry = header->e_entry; + + for (ph = phdr; ph < &phdr[l->l_phnum]; ++ph) + { + +#ifdef DUMP_SEGMENTS + wld_printf( "ph = %x\n", ph ); + wld_printf( " p_type = %x\n", ph->p_type ); + wld_printf( " p_flags = %x\n", ph->p_flags ); + wld_printf( " p_offset = %x\n", ph->p_offset ); + wld_printf( " p_vaddr = %x\n", ph->p_vaddr ); + wld_printf( " p_paddr = %x\n", ph->p_paddr ); + wld_printf( " p_filesz = %x\n", ph->p_filesz ); + wld_printf( " p_memsz = %x\n", ph->p_memsz ); + wld_printf( " p_align = %x\n", ph->p_align ); +#endif + + switch (ph->p_type) + { + /* These entries tell us where to find things once the file's + segments are mapped in. We record the addresses it says + verbatim, and later correct for the run-time load address. */ + case PT_DYNAMIC: + l->l_ld = (void *) ph->p_vaddr; + l->l_ldnum = ph->p_memsz / sizeof (Elf32_Dyn); + break; + + case PT_PHDR: + l->l_phdr = (void *) ph->p_vaddr; + break; + + case PT_TLS: + /* + * We don't need to set anything up because we're + * emulating the kernel, not ld-linux.so.2 + * The ELF loader will set up the TLS data itself. + */ + break; + + case PT_LOAD: + { + if ((ph->p_align & (GL(dl_pagesize) - 1)) != 0) + { + wld_printf("ELF load command alignment not page-aligned"); + return NULL; + } + if (((ph->p_vaddr - ph->p_offset) & (ph->p_align - 1)) != 0) + { + wld_printf("ELF load command address/offset not properly aligned"); + return NULL; + } + + c = &loadcmds[nloadcmds++]; + c->mapstart = ph->p_vaddr & ~(ph->p_align - 1); + c->mapend = ((ph->p_vaddr + ph->p_filesz + GL(dl_pagesize) - 1) + & ~(GL(dl_pagesize) - 1)); + c->dataend = ph->p_vaddr + ph->p_filesz; + c->allocend = ph->p_vaddr + ph->p_memsz; + c->mapoff = ph->p_offset & ~(ph->p_align - 1); + + c->prot = 0; + if (ph->p_flags & PF_R) + c->prot |= PROT_READ; + if (ph->p_flags & PF_W) + c->prot |= PROT_WRITE; + if (ph->p_flags & PF_X) + c->prot |= PROT_EXEC; + } + break; + + case PT_INTERP: + break; + + case PT_SHLIB: + case PT_NOTE: + case PT_GNU_EH_FRAME: + case 0x6474e551: /* FIXME: what is this? */ + break; + + default: + wld_printf("warning: unknown header type %x\n", ph->p_type); + break; + } + } + + /* Now process the load commands and map segments into memory. */ + c = loadcmds; + + /* Length of the sections to be loaded. */ + maplength = loadcmds[nloadcmds - 1].allocend - c->mapstart; + + if( header->e_type == ET_DYN ) + { + ElfW(Addr) mappref; + mappref = (ELF_PREFERRED_ADDRESS (loader, maplength, c->mapstart) + - MAP_BASE_ADDR (l)); + + /* Remember which part of the address space this object uses. */ + l->l_map_start = (ElfW(Addr)) mmap ((void *) mappref, maplength, + c->prot, MAP_COPY | MAP_FILE, + fd, c->mapoff); + /* wld_printf("set : offset = %x\n", c->mapoff); */ + /* wld_printf("l->l_map_start = %x\n", l->l_map_start); */ + + l->l_map_end = l->l_map_start + maplength; + l->l_addr = l->l_map_start - c->mapstart; + + mprotect ((caddr_t) (l->l_addr + c->mapend), + loadcmds[nloadcmds - 1].allocend - c->mapend, + PROT_NONE); + goto postmap; + } + else + { + ELF_FIXED_ADDRESS (loader, c->mapstart); + } + + /* Remember which part of the address space this object uses. */ + l->l_map_start = c->mapstart + l->l_addr; + l->l_map_end = l->l_map_start + maplength; + + while (c < &loadcmds[nloadcmds]) + { + if (c->mapend > c->mapstart) + /* Map the segment contents from the file. */ + mmap ((void *) (l->l_addr + c->mapstart), + c->mapend - c->mapstart, c->prot, + MAP_FIXED | MAP_COPY | MAP_FILE, fd, c->mapoff); + + postmap: + if (l->l_phdr == 0 + && (ElfW(Off)) c->mapoff <= header->e_phoff + && ((size_t) (c->mapend - c->mapstart + c->mapoff) + >= header->e_phoff + header->e_phnum * sizeof (ElfW(Phdr)))) + /* Found the program header in this segment. */ + l->l_phdr = (void *) (c->mapstart + header->e_phoff - c->mapoff); + + if (c->allocend > c->dataend) + { + /* Extra zero pages should appear at the end of this segment, + after the data mapped from the file. */ + ElfW(Addr) zero, zeroend, zeropage; + + zero = l->l_addr + c->dataend; + zeroend = l->l_addr + c->allocend; + zeropage = ((zero + GL(dl_pagesize) - 1) + & ~(GL(dl_pagesize) - 1)); + + /* + * This is different to the dl-load load... + * ld-linux.so.2 relies on the whole page being zero'ed + */ + zeroend = (zeroend +GL(dl_pagesize) - 1) & ~(GL(dl_pagesize) - 1); + + if (zeroend < zeropage) + { + /* All the extra data is in the last page of the segment. + We can just zero it. */ + zeropage = zeroend; + } + + if (zeropage > zero) + { + /* Zero the final part of the last page of the segment. */ + if ((c->prot & PROT_WRITE) == 0) + { + /* Dag nab it. */ + mprotect ((caddr_t) (zero & ~(GL(dl_pagesize) - 1)), + GL(dl_pagesize), + c->prot|PROT_WRITE); + } + memset ((void *) zero, '\0', zeropage - zero); + if ((c->prot & PROT_WRITE) == 0) + mprotect ((caddr_t) (zero & ~(GL(dl_pagesize) - 1)), + GL(dl_pagesize), c->prot); + } + + if (zeroend > zeropage) + { + /* Map the remaining zero pages in from the zero fill FD. */ + caddr_t mapat; + mapat = mmap ((caddr_t) zeropage, zeroend - zeropage, + c->prot, MAP_ANON|MAP_PRIVATE|MAP_FIXED, + ANONFD, 0); + } + } + + ++c; + } + + if (l->l_phdr == NULL) + { + wld_printf("no program header\n"); + exit(1); + } + + (ElfW(Addr)) l->l_phdr += l->l_addr; + (ElfW(Addr)) l->l_entry += l->l_addr; + + return (void*)l->l_entry; +} + +#define ROUND_SIZE(addr,size) \ + (((int)(size) + ((int)(addr) & page_mask) + page_mask) & ~page_mask) + +/* + * wld_reserve_wine_memory + * + * This is the reason we are here. + * We want to reserve address space so that the kernel doesn't + * map stuff there. We do this by getting in first before + * anything else is mapped (except this program) and reserve + * the memory we want. + */ +void wld_reserve_wine_memory( char *pe_file, void **base, size_t *size ) +{ + IMAGE_DOS_HEADER dos; + IMAGE_NT_HEADERS nt; + int unix_fd, page_mask = GL(dl_pagesize) - 1; + + if( !pe_file ) + return; + + unix_fd = open( pe_file, O_RDONLY, 0); + if( unix_fd < 0 ) + return; + + /* + * The following code is borrowed from + * get_image_params() in wine/server/mapping.c + */ + if (read( unix_fd, &dos, sizeof(dos) ) != sizeof(dos)) goto error; + if (dos.e_magic != IMAGE_DOS_SIGNATURE) goto error; + if (lseek( unix_fd, dos.e_lfanew, SEEK_SET ) == -1) goto error; + + if (read( unix_fd, &nt.Signature, sizeof(nt.Signature) ) != sizeof(nt.Signature)) goto error; + if (nt.Signature != IMAGE_NT_SIGNATURE) goto error; + if (read( unix_fd, &nt.FileHeader, sizeof(nt.FileHeader) ) != sizeof(nt.FileHeader)) goto error; + /* zero out Optional header in the case it's not present or partial */ + memset(&nt.OptionalHeader, 0, sizeof(nt.OptionalHeader)); + if (read( unix_fd, &nt.OptionalHeader, nt.FileHeader.SizeOfOptionalHeader) != nt.FileHeader.SizeOfOptionalHeader) goto error; + + *size = ROUND_SIZE( 0, nt.OptionalHeader.SizeOfImage ); + *base = (void *)nt.OptionalHeader.ImageBase; + +#ifdef DUMP_PERESERVE + wld_printf( "file %s\n", pe_file ); + wld_printf( "parsed PE image... base %x size %x\n", *base, *size ); +#endif + +error: + close( unix_fd ); +} + +/* + * Find a symbol in the symbol table of the executable loaded + */ +void *wld_find_symbol( const ElfW(Phdr) *phdr, int num, char *var ) +{ + const ElfW(Dyn) *dyn = NULL; + void *ptr = NULL; + const ElfW(Phdr) *ph; + const ElfW(Sym) *symtab = NULL; + const char *strings = NULL; + + /* check the values */ +#ifdef DUMP_SYMS + wld_printf("%x %x\n", phdr, num ); +#endif + if( ( phdr == NULL ) || ( num == 0 ) ) + { + wld_printf("could not find PT_DYNAMIC header entry\n"); + return NULL; + } + + /* parse the (already loaded) ELF executable's header */ + for (ph = phdr; ph < &phdr[num]; ++ph) + { + if( PT_DYNAMIC == ph->p_type ) + { + dyn = (void *) ph->p_vaddr; + num = ph->p_memsz / sizeof (Elf32_Dyn); + break; + } + } + if( !dyn ) + { + wld_printf("No PT_DYNAMIC section\n"); + return ptr; + } + + while( dyn->d_tag ) + { + if( dyn->d_tag == DT_STRTAB ) + strings = (const char*) dyn->d_un.d_ptr; + if( dyn->d_tag == DT_SYMTAB ) + symtab = (const ElfW(Sym) *)dyn->d_un.d_ptr; +#ifdef DUMP_SYMS + wld_printf("%x %x\n", dyn->d_tag, dyn->d_un.d_ptr ); +#endif + dyn++; + } + + if( (!symtab) || (!strings) ) + { + wld_printf("No symbol table found\n"); + return ptr; + } + + /* FIXME: this crashes if it doesn't find the symbol we want */ + do + { + if( ( ELF32_ST_BIND(symtab->st_info) == STT_OBJECT ) && + ( 0 == strcmp( strings+symtab->st_name, var ) ) ) + { + ptr = (void*)symtab->st_value; + break; + } + symtab++; + } + while( symtab->st_name ); + +#ifdef DUMP_SYMS + wld_printf("Found %s -> %x\n", strings+symtab->st_name, symtab->st_value ); +#endif + + return ptr; +} + +/* + * wld_start + * + * Repeat the actions the kernel would do when loading a dynamically linked .so + * Load the ELF interperter ld-linux.so and then binary itself. + * + * Note, we assume that the binary is a dynamically linked ELF shared object + * and that ld-linux.so is its ELF interpreter. + */ +void* wld_start( int argc ) +{ + int fd, phnum = 0; + unsigned char buf[0x800]; + void *start; + char **argv = (char**) &argc, **p, *pe_file = NULL; + struct link_map map; + ElfW(auxv_t)* av; + ElfW(Phdr) *elf_phdr = NULL; + struct wine_preload_info **wine_preload_vars; + static struct wine_preload_info vars; + + memset( &map, 0, sizeof map ); + + /* skip over the parameters */ + p = ++argv; +#ifdef DUMP_ARG + { + int i; + for( i = 0; i<argc; i++ ) + wld_printf("argv[%x] = %s\n", i, *p++); + if(*p++) + wld_printf("argv[argc] not NULL!!\n"); + } +#else + p+=(argc+1); +#endif + + /* skip over the environment, find the name of the PE file */ + while( *p ) + { + const char pefile[] = "WINEPEEXEPATH="; + if( 0 == memcmp( pefile, *p, sizeof pefile - 1 ) ) + pe_file = (*p) + sizeof pefile - 1 ; + p++; + } + + av = (ElfW(auxv_t)*) (p+1); + wld_get_auxilary( av, AT_PAGESZ, &dl_pagesize ); +#ifdef DUMP_AUX_INFO + wld_dump_auxilary( av ); +#endif + + /* reserve memory that Wine needs */ + vars.pe_size = 0x01000000; + vars.pe_address = (void*)0x00400000; + wld_reserve_wine_memory( pe_file, &vars.pe_address, &vars.pe_size ); + mmap( vars.pe_address, vars.pe_size, PROT_NONE, + MAP_FIXED|MAP_PRIVATE|MAP_ANON, -1, 0); + + /* reserve the memory that wine needs for the global heap */ + vars.heap_size = 0x400000; + vars.heap_address = (void*)0x65430000; + mmap( vars.heap_address, vars.heap_size, PROT_NONE, + MAP_FIXED|MAP_PRIVATE|MAP_ANON, -1, 0); + + /* load the original dynamic loader itself */ + fd = open( LDSO_NAME, O_RDONLY, 0); + if( fd < 0 ) + { + wld_printf( "error: fd = %x\n", fd); + exit(1); + } + read( fd, buf, sizeof buf ); + start = wld_map_so( fd, buf, sizeof buf, &map ); + if( !start ) + exit(0); + close( fd ); + + /* + * Pass information to the wine loader in a static variable + * so it doesn't get destroyed after we leave this stack frame + */ + wld_get_auxilary( av, AT_PHDR, (int*)&elf_phdr ); + wld_get_auxilary( av, AT_PHNUM, (int*)&phnum ); + wine_preload_vars = wld_find_symbol( elf_phdr, phnum, "wine_preload_vars" ); + if( wine_preload_vars ) + { + unsigned char *base = (void*)0x7ff81000; /* FIXME - define properly */ + vars.preload_base = (void*) base; + vars.preload_size = (size_t) (_end - base); + *wine_preload_vars = &vars; + } + + wld_set_auxilary( av, AT_BASE, map.l_addr ); + +#ifdef DUMP_AUX_INFO + wld_printf("New auxillary info:\n"); + wld_dump_auxilary( av ); + wld_printf("jumping to %x\n", start); +#endif + + return start; +} + +/* + * The _start function is the entry and exit point of this program + * + * It calls wld_start, passing a pointer to the args it receives + * then jumps to the address wld_start returns after removing the + * first argv[] value, and decrementing argc + */ +void _start(void); +__asm ( + ".align 4\n" + "\t.global _start\n" + "\t.type _start,@function\n" +"_start:\n" + "\tcall wld_start\n" + "\tpush %eax\n" + "\txor %eax,%eax\n" + "\txor %ebx,%ebx\n" + "\txor %ecx,%ecx\n" + "\txor %edx,%edx\n" + "\tret\n" +); +

1 0

Re: winegcc: use CC to compile the .spec.c file
by Alexandre Julliard 15 Apr '04

15 Apr '04

"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes: > ChangeLog > Dimitrie O. Paun <dpaun(a)rogers.com> > Always use CC to compile the .spec.c file. Doesn't compile_to_object() do this already? -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: Re: statvfs and cdrom problem
by Christian Costa 15 Apr '04

15 Apr '04

> Message du 15/04/04 00:35 > De : Alexandre Julliard > A : Christian Costa > Copie à : wined > Objet : Re: statvfs and cdrom problem > Christian Costa writes: > > > Yes, this works fine. Thanks. :-) > > When do you plan to rewrite GetFreeDiskSpace? > > In a few days I guess. There are still some missing features in > NtCreateFile that need to be done first. > > -- > Alexandre Julliard > julliard(a)winehq.org > Ok! Fine! :-) I have a small fix for the lpSectorsPerCluster param which should always contain 1 for CDROM. I will send a patch after your rewrite unless you fix it first. :-) Bye, Christian

1 0

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 15 Apr '04

15 Apr '04

Hi, But dont you think that the structure is not really required till the window has been created successfully? Regards Santosh Siddheshwar > -----Original Message----- > From: Alexandre Julliard [SMTP:julliard@winehq.org] > Sent: Thursday, April 15, 2004 9:00 AM > To: Dmitry Timoshkov > Cc: Santosh Siddheshwar; Robert Shearman; wine-devel(a)winehq.org > Subject: Re: Handling dialog messages for non-template based dialogs > > "Dmitry Timoshkov" <dmitry(a)baikal.ru> writes: > > > Yes, if Alexandre has no objections. Be patient, that may take some > time. > > Actually, I do have an objection... I think you should be allocating > the structure as soon as it is needed, WM_CREATE is not the first > message that the window will receive. > > -- > Alexandre Julliard > julliard(a)winehq.org ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

2 1

RE: Handling dialog messages for non-template based dialogs
by Santosh Siddheshwar 15 Apr '04

15 Apr '04

Hi, So can I expect this to be checked into cvs soon? Regards Santosh Siddheshwar > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry@baikal.ru] > Sent: Wednesday, April 14, 2004 5:22 PM > To: Santosh Siddheshwar; Robert Shearman > Cc: wine-devel(a)winehq.org > Subject: Re: Handling dialog messages for non-template based dialogs > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > Thanks for the feedback. Excellent catches! Hope my next mail to > > wine-patches gets through! > > Your new patch looks good for me. Thanks for doing this work! > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

3 2

Re: abnt2 keyboard patch
by Dmitry Timoshkov 15 Apr '04

15 Apr '04

"Rafael аvila de EspМndola" <rafael.espindola(a)ic.unicamp.br> wrote: > I have tested the patch with a abnt2 and a us-int keyboard. Both work > correctly. > > Dmitry: Do you think that the "magic numbers" are reasonably explained? What I > have done is basically to treat the comma similarilly to the decimal period. > The numbers are different from the first patch because in the first one I > haven't fixed the main_key_scan_abnt_qwerty and main_key_vkey_abnt_qwerty > tables. I still see problems with your patch. 1. You are using 'keysym == 0x2C' for comma, but what happens if NumLock is on, and you press comma on the main keyboard, not on the keypad? Shouldn't X11 send XK_KP_xxx event in that case (something like XK_KP_Decimal)? 2. Please generate unified diffs, 'using diff -u' for patches. -- Dmitry.

1 0

dbghelp: cross-compile
by Kevin Koltzau 15 Apr '04

15 Apr '04

I decided to try cross compiling all of wine using mingw..hit a couple problems in dbghelp This fixes a few of them, it still doesn't compile (primarily because of a missing regex.h at the moment) but it does get farther I'm not sure if these fixes are quite right..I don't fully understand this code Changelog Fix a few compile errors when cross compiling

1 0

Re: MAPI32 - headers
by Alexandre Julliard 15 Apr '04

15 Apr '04

Jon Griffiths <jon_p_griffiths(a)yahoo.com> writes: > -#ifndef MAPICODE_H > -#define MAPICODE_H > +#ifndef __WINE_MAPICODE_H > +#define __WINE_MAPICODE_H It's better to keep the same defines as Windows, especially since in that case they are used from other headers. > -#define MAKE_MAPI_SCODE(sev,fac,code) \ > - ( (((ULONG)(sev)<<31) | ((ULONG)(fac)<<16) | ((ULONG)(code))) ) MAKE_MAPI_SCODE and the other macros are in the Windows header so we need them, you can't remove them. > +#ifndef __FLAGS > +#define __FLAGS > +typedef unsigned long FLAGS; > +#endif There is no such #ifdef in the Windows header. If there are conflicting typedefs in the Windows headers then we want conflicts in the Wine headers too, otherwise we won't be able to build the Wine code against the Windows headers. -- Alexandre Julliard julliard(a)winehq.org

1 0

Bug 560 "Integrate" AppDB and bugzilla
by Tony Lambregts 15 Apr '04

15 Apr '04

This is an update for bug 560 http://bugs.winehq.org/show_bug.cgi?id=560 I have gone through each and every bug in Bugzilla (yes all 2174 of them) and linked the ones that I could find an AppDB entry for. That translates into 756 bugs. Some of these bugs applied to more than one program. In those cases I tried to link it to the most appropriate application. That usually translated into the most widely used app. http://bugs.winehq.org/buglist.cgi?bug_file_loc_type=allwords&bug_file_loc=… About halfway through I created a new Keyword (NoAppDBEntry) to track those bugs that I could not find an AppDB entry for. There are 249 bugs with this keyword. http://bugs.winehq.org/buglist.cgi?keywords_type=allwords&keywords=NoAppDBE… There are a fair number of apps in this list that have more than one bug entered. The one that sticks out in my mind right now is Xilinx, although there were quite a few others. What strikes me most about this, is that as I got to the newer bug reports I ran into more and more esoteric programs. I think that is a good sign. Once Jerry Has committed my bugs.php patch I will consider this bug closed. In order to improve this more requires opening up the source code for our Bugzilla. -- Tony Lambregts PS: Could I get someone to give me more rights in the AppDB. My user name is "tonylambregts" (go figure).

1 0

statvfs and cdrom problem
by Christian Costa 14 Apr '04

14 Apr '04

Hi, I'm trying to make GetFreeDiskSpace working with CDROM because a game needs it. However, I'm experiencing problem with statvfs... Indeed, statvfs always returns f_frsize = 0 and f_blocks = 0. If I cd to /mnt/cdrom or edit a file in it, this does not help however if I run a grep or launch Konqueror in that directory, statvfs magically works. I suspect supermount is responsible because statvfs needs the cdrom to be "physically" mounted. Is it a know issue? (I am on a Mandrake 9.1 base) Or the only solution is to keep a fd opened during the statvfs call so the drive stays mounted... Thanks in advance, Christian PS: I used the attached code for testing #include <sys/types.h> #include <sys/statvfs.h> #include <sys/statfs.h> int main() { struct statvfs info; struct statfs inf; if (statfs("/mnt/cdrom", &inf) < 0) { printf("cannot do statfs\n"); return 0; } printf("size = %ld - %ld\n", inf.f_bsize, inf.f_blocks); if (statvfs("/mnt/cdrom", &info ) < 0) { printf("cannot do statvfs\n"); return 0; } printf("size = %ld - %ld - %ld\n", info.f_bsize, info.f_frsize, info.f_blocks); return 1; }

2 3

Installer crash
by andrejoh＠c2i.net 14 Apr '04

14 Apr '04

When trying to install the game Zoo Tycoon, today's CVS checkout of Wine crashes with the following output: [andrej@rivendell cdrom]$ nice wine ./setup err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report err:wave:OSS_WaveOutInit /dev/mixer1: No such device err:wave:OSS_WaveInInit /dev/mixer1: No such device wine: Unhandled exception (thread 000d), starting debugger... err:dosmem:setup_dos_mem Cannot use first megabyte for DOS address space, please report WineDbg starting on pid c Can't find file for ELF 'wine-kthread' ((nil)) Loaded debug information from ELF 'wine-pthread' ((nil)) Breakpoint 1 at 0x0010df00 Loaded debug information from ELF '/home/andrej/local/wine/lib/libwine.so.1' (0x40001000) No debug information in ELF '/lib/tls/libpthread.so.0' ((nil)) No debug information in ELF '/lib/tls/libc.so.6' ((nil)) No debug information in ELF '/lib/libdl.so.2' ((nil)) No debug information in ELF '/lib/ld-linux.so.2' ((nil)) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/ntdll.dll.so' (0x4002c000) Loaded debug information from ELF '/home/andrej/local/wine/lib/libwine_unicode.so.1' (0x40098000) No debug information in ELF '/lib/tls/libm.so.6' ((nil)) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/kernel32.dll.so' (0x402a0000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/user32.dll.so' (0x406c0000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/gdi32.dll.so' (0x407ea000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/advapi32.dll.so' (0x40864000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/winmm.dll.so' (0x40893000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/comctl32.dll.so' (0x408fd000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/shell32.dll.so' (0x40995000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/ole32.dll.so' (0x40a18000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/rpcrt4.dll.so' (0x40a87000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/shlwapi.dll.so' (0x40ace000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/version.dll.so' (0x40b22000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/lz32.dll.so' (0x40b3b000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/imm32.dll.so' (0x40b51000) No debug information in ELF '/usr/lib/libfreetype.so.6' ((nil)) No debug information in ELF '/usr/lib/libz.so.1' ((nil)) No debug information in ELF '/usr/lib/libfontconfig.so.1' ((nil)) No debug information in ELF '/usr/lib/libexpat.so.0' ((nil)) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/x11drv.dll.so' (0x40d90000) No debug information in ELF '/usr/X11R6/lib/libSM.so.6' ((nil)) No debug information in ELF '/usr/X11R6/lib/libICE.so.6' ((nil)) No debug information in ELF '/usr/X11R6/lib/libXv.so.1' ((nil)) No debug information in ELF '/usr/X11R6/lib/libXext.so.6' ((nil)) No debug information in ELF '/usr/X11R6/lib/libX11.so.6' ((nil)) No debug information in ELF '/usr/X11R6/lib/libXcursor.so.1' ((nil)) No debug information in ELF '/usr/X11R6/lib/libXrender.so.1' ((nil)) No debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2' (0x40021000) No debug information in ELF '/usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2' (0x40e4c000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/wineoss.drv.so' (0x40e6a000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/msacm.drv.so' (0x40ea6000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/msacm32.dll.so' (0x40ebd000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/midimap.drv.so' (0x40ff0000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/vwin32.vxd.so' (0x41005000) Loaded debug information from ELF '/home/andrej/local/wine/lib/wine/winedos.dll.so' (0x41330000) No debug information in 32bit DLL 'D:\setup.exe' (0x400000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x40050000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x402d0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x40870000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\GDI32.DLL' (0x40800000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\USER32.DLL' (0x406e0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINMM.DLL' (0x408a0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\COMCTL32.DLL' (0x40910000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\RPCRT4.DLL' (0x40aa0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\OLE32.DLL' (0x40a30000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHLWAPI.DLL' (0x40af0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\SHELL32.DLL' (0x409b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\LZ32.DLL' (0x40b40000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\VERSION.DLL' (0x40b30000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\IMM32.DLL' (0x40b60000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\X11DRV.DLL' (0x40da0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEOSS.DRV' (0x40e80000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM32.DLL' (0x40ed0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSACM.DRV' (0x40eb0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MIDIMAP.DRV' (0x41000000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\WINEDOS.DLL' (0x41340000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\VWIN32.VXD' (0x41010000) Unhandled exception: page fault on write access to 0x000d0000 in 32-bit code (0x4134b69b). In 32-bit mode. 0x4134b69b (DOSVM_AllocCodeUMB+0x27 [himem.c:121] in WINEDOS.DLL): movw %ax,0x0(%edi) 123 if (selector) Wine-dbg>bt Backtrace: =>0 0x4134b69b (DOSVM_AllocCodeUMB+0x27(size=0x3, segment=0xd0000, selector=0x0) [himem.c:121] in WINEDOS.DLL) (ebp=406be0e4) 1 0x4134b740 (DOSVM_InitSegments+0x2c [himem.c:222] in WINEDOS.DLL) (ebp=406be108) 2 0x4134b017 (DllMain+0x43(hinstDLL=0x41340000, fdwReason=0x1, lpvReserved=0x0) [dosvm.c:725] in WINEDOS.DLL) (ebp=406be11c) 3 0x413470b4 (__wine_dll_main+0x60 [winedos.dll-Iw24bO.spec.c] in WINEDOS.DLL) (ebp=406be14c) 4 0x4009368a (call_dll_entry_point+0x12 in NTDLL.DLL) (ebp=406be164) 5 0x400660cb (MODULE_InitDLL+0xdf(wm=0x401d1370, reason=0x1, lpReserved=0x0) [loader.c:724] in NTDLL.DLL) (ebp=406be1d4) 6 0x40066225 (process_attach+0x81(wm=0x401d1370, lpReserved=0x0) [loader.c:797] in NTDLL.DLL) (ebp=406be1f8) 7 0x400662bf (process_attach+0x11b(wm=0x401d12d0, lpReserved=0x0) [loader.c:789] in NTDLL.DLL) (ebp=406be218) 8 0x400679e4 (LdrLoadDll+0x84(path_name=0x401d1b08, flags=0x0, libname=0x406be27c, hModule=0x406be25c) [loader.c:1529] in NTDLL.DLL) (ebp=406be23c) 9 0x4030dfe7 (load_library+0x4b(libname=0x406be27c, flags=0x0) [module.c:668] in KERNEL32.DLL) (ebp=406be26c) 10 0x4030e0be (LoadLibraryExW+0x2e(libnameW=0x406be32c, hfile=0x0, flags=0x0) [module.c:731] in KERNEL32.DLL) (ebp=406be28c) 11 0x4030e118 (LoadLibraryW+0x1c(libnameW=0x406be32c) [module.c:761] in KERNEL32.DLL) (ebp=406be2a4) 12 0x4033300b (VXD_Open+0x163(filenameW=0x401d1af0, access=0x0, sa=0x0) [vxd.c:192] in KERNEL32.DLL) (ebp=406be358) 13 0x402e2232 (CreateFileW+0x51a(filename=0x401d1ae8, access=0x0, sharing=0x0, sa=0x0, creation=0x3, attributes=0x4000000, template=0x0) [file.c:382] in KERNEL32.DLL) (ebp=406befc4) 14 0x402e2582 (CreateFileA+0x62(filename=0x463fa4, access=0x0, sharing=0x0, sa=0x0, creation=0x3, attributes=0x4000000, template=0x0) [file.c:473] in KERNEL32.DLL) (ebp=406beffc) 15 0x0041b8ac (setup.exe.LaunchGame+0x14bfc in setup.exe) (ebp=00000003) *** Invalid address 0x00000003 (_begin+0x3) My previous compile from CVS (can't remember the date; probably a couple of weeks old) got a lot further, but ended up hanging partway into the installation. This is on Fedora Core 1/i386, with exec-shield turned off. -- Try Anarchy Online http://www.anarchy-online.com/content/downloads/tryout/ Netiquette guidelines ftp://ftp.rfc-editor.org/in-notes/rfc1855.txt How to quote properly http://www.i-hate-computers.demon.co.uk/ Hvordan sitere riktig http://home.online.no/~vidaandr/news/OBSquoting.html

2 4

More serial access issues
by Geoffrey Hausheer 14 Apr '04

14 Apr '04

Well, I broke down and pulled out the oscope and rs232 breakout box to try to figure out why my app isn't able to communicate with the device. turns out that Rein's patch is correctly deasserting DSR, however, I am not getting any data over the Tx pin. And after I checked the output of WriteFile, it is failing. GetLastError doesn't return anything useful (a value of 997 which FormatMessage() can't do anything with). But some debugging led me to determine that NtWriteFile is returning 0x103 which is STATUS_PENDING. After that I'm somewhat lost as to what is going on. Obvioulsy, 'register_new_async' is returning this status, which apparently happens when wine_server_call returns 0 or STATUS_PENDING (not sure if the second is even possible). But about here I am getting completely confused as to what we are trying to accomplish. The file is opened via: CreateFile("COM1", 0, NULL, OPEN_EXISTING, 0, NULL) so we're not in overlapped mode. SetCommTimeout is called with the COMMTIMEOUTS structure containing all 0s. All flow control is disabled using SetCommState. Before a write, we always call 'PurgeComm' and ClearCommError. In Windows, this combination results in a write always occurring when WriteFile is called, regardless of whether there is anything connected to the serial port. Wine appears to be waiting for something, and I'm not sure what. If anyone has any ideas how I might proceed, i'd be glad to hear them. Thanks, .Geoff

1 0

AutoFS-ed drives
by Mark Draheim 14 Apr '04

14 Apr '04

Anybody using autofs and wine? Does it work? I don't follow wine development lists, so maybe autofs is no longer a problem. Once in a while I build a CVS snapshot and test whether the odd app I still have works. And wine on autofs doesn't work here. I think Guido already sent a mail about this last month. Guido patched wine way back in Feb 2003, submitted a bug http://bugs.winehq.com/show_bug.cgi?id=1283 and even set up a page to describe the problem http://freespace.sourceforge.net/guidod/wine-vol-a/ Since then he has completely rewritten the patch in order to search the /etc/auto.* files for drives. This obsoleted the additional options in wine's config with the old patch. This last patch worked perfectly until recently. However, Guido is busy right now and cannot work on the patch. And my C is pretty bad. If anybody is interested I can provide the last patch known to work. If for some reason the patch does not meet wine's standards, would it be possible that the autofs problem is recognized and put on a TODO list for later? Or even close the bug as WONTFIX? thanks Mark

2 2

Re: ISF_MyComputer_fnParseDisplayName()
by Dmitry Timoshkov 14 Apr '04

14 Apr '04

"Martin Fuchs" <martin-fuchs(a)gmx.net> wrote: > Changelog: > make drive letters in PIDLs always uppercase to enable PIDL comparison > > > Index: shfldr_mycomp.c > =================================================================== > RCS file: /CVS/ReactOS/reactos/lib/shell32/shfldr_mycomp.c,v > retrieving revision 1.10 > diff -u -p -d -r1.10 shfldr_mycomp.c > --- shfldr_mycomp.c 11 Apr 2004 13:24:29 -0000 1.10 > +++ shfldr_mycomp.c 13 Apr 2004 20:45:39 -0000 > @@ -217,6 +217,7 @@ ISF_MyComputer_fnParseDisplayName (IShel > /* do we have an absolute path name ? */ > else if (PathGetDriveNumberW (lpszDisplayName) >= 0 && lpszDisplayName[2] == (WCHAR) '\\') { > szNext = GetNextElementW (lpszDisplayName, szElement, MAX_PATH); > + szElement[0] = toupper(szElement[0]); /* make drive letter uppercase to enable PIDL comparison */ It's better to use unicode version here (toupperW) since in some linux locales uppercasing is done differently. -- Dmitry.

3 2

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 April 2004