August 2004 - Wine-Devel - list.winehq.org

Re: MSTS installer - files inside setupenu.dll

by Frank Eising

I don't have them on file unfortunately. For the exact paths I have to get the msts cd (it's not here right now). For what I remember the path is something like this: abcdef/menu/background.bmp abcdef/menu/logo.bmp etc... Those files are in setupenu.dll, because you can see the paths when viewing that file. Frank ----- Original Message ----- From: Mike Hearn <m.hearn(a)signal.QinetiQ.com> Date: Mon, 23 Aug 2004 09:37:46 +0100 To: Frank Eising <puiky(a)operamail.com> Subject: Re: MSTS installer - files inside setupenu.dll > What were th efile paths it was looking for? > > Frank Eising wrote: > > I am trying to get the Train SImulator setup working. Last time I debugged it I found that the setup looks for jpeg images in a certain directory to set up the setup menu. They are not found, because those files are non-existent on the cdrom. They are inside setupenu.dll. > > Anyone knows what kind of thing needs to be implemented, in order to make files inside a dll accessable by wine? I could not find any errors in the debug messages referring to it. > > > > Frank > > -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

Aug. 23, 2004

Patch for CreateDIBitmap: Don't create monochrome bitmaps (help wanted)

by Michael Kaufmann

Hi all, I need some help in fixing a bug in CreateDIBitmap. I've attached a patch, but unfortunately it introduces new bugs. The function CreateDIBitmap creates a monochrome device-dependent bitmap if it's possible. But that's very bad, because BitBlt and StretchBlt handle monochrome bitmaps in a different way than color bitmaps (copied from MSDN): "If *StretchBlt* must convert a monochrome bitmap to a color bitmap, it sets white bits (1) to the background color and black bits (0) to the foreground color. The foreground and background colors of the device context with color are used." So SetTextColor and SetBkColor can change the colors of the (formerly device independent) bitmap, and that's not what we want. The attached patch fixes this bug (don't create monochrome bitmaps anymore), but it seems that other code in WINE depends on the old behavior. The mouse cursor is now completely garbage. Can anybody help me finding the remaining bugs? Test Program (DIB-Testcase.zip): --------------------------------- I've created a test program that shows the problem. It also shows a bug in Windows! It displays two bitmaps, both should be black and white. WINE displays them red on green (I've set these colors with SetTextColor/SetBkColor). The images differ only in a single byte. I've used the program bmpdump ( http://david.tribble.com/programs.html ) to analyze them. In the color table of the bitmaps, the rgbReserved member of a RGBQUAD structure is 0x00 for the left bitmap and 0xFF for the right bitmap. This shouldn't make a difference. But Windows creates a monochrome bitmap for the left one, and a color bitmap for the right one! Does anyone understand this behavior? Regards Michael Index: dlls/gdi/dib.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/dib.c,v retrieving revision 1.3 diff -u -r1.3 dib.c --- dlls/gdi/dib.c 12 Aug 2004 20:02:39 -0000 1.3 +++ dlls/gdi/dib.c 23 Aug 2004 14:45:03 -0000 @@ -779,7 +779,6 @@ UINT coloruse ) { HBITMAP handle; - BOOL fColor; DWORD width; int height; WORD bpp; @@ -789,79 +788,10 @@ if (DIB_GetBitmapInfo( header, &width, &height, &bpp, &compr ) == -1) return 0; if (height < 0) height = -height; - /* Check if we should create a monochrome or color bitmap. */ - /* We create a monochrome bitmap only if it has exactly 2 */ - /* colors, which are black followed by white, nothing else. */ - /* In all other cases, we create a color bitmap. */ - - if (bpp != 1) fColor = TRUE; - else if ((coloruse != DIB_RGB_COLORS) || !data) fColor = FALSE; - else - { - if (data->bmiHeader.biSize == sizeof(BITMAPINFOHEADER)) - { - RGBQUAD *rgb = data->bmiColors; - DWORD col = RGB( rgb->rgbRed, rgb->rgbGreen, rgb->rgbBlue ); - - /* Check if the first color of the colormap is black */ - if ((col == RGB(0,0,0))) - { - rgb++; - col = RGB( rgb->rgbRed, rgb->rgbGreen, rgb->rgbBlue ); - /* If the second color is white, create a monochrome bitmap */ - fColor = (col != RGB(0xff,0xff,0xff)); - } - /* Note : If the first color of the colormap is white - followed by black, we have to create a color bitmap. - If we don't the white will be displayed in black later on!*/ - else fColor = TRUE; - } - else if (data->bmiHeader.biSize == sizeof(BITMAPCOREHEADER)) - { - RGBTRIPLE *rgb = ((BITMAPCOREINFO *)data)->bmciColors; - DWORD col = RGB( rgb->rgbtRed, rgb->rgbtGreen, rgb->rgbtBlue ); - if ((col == RGB(0,0,0))) - { - rgb++; - col = RGB( rgb->rgbtRed, rgb->rgbtGreen, rgb->rgbtBlue ); - fColor = (col != RGB(0xff,0xff,0xff)); - } - else fColor = TRUE; - } - else if (data->bmiHeader.biSize == sizeof(BITMAPV4HEADER)) - { /* FIXME: correct ? */ - RGBQUAD *rgb = data->bmiColors; - DWORD col = RGB( rgb->rgbRed, rgb->rgbGreen, rgb->rgbBlue ); - - /* Check if the first color of the colormap is black */ - if ((col == RGB(0,0,0))) - { - rgb++; - col = RGB( rgb->rgbRed, rgb->rgbGreen, rgb->rgbBlue ); - /* If the second color is white, create a monochrome bitmap */ - fColor = (col != RGB(0xff,0xff,0xff)); - } - /* Note : If the first color of the colormap is white - followed by black, we have to create a color bitmap. - If we don't the white will be displayed in black later on!*/ - else fColor = TRUE; - } - else - { - ERR("(%ld): wrong/unknown size for data\n", - data->bmiHeader.biSize ); - return 0; - } - } - - /* Now create the bitmap */ - if (!(dc = DC_GetDCPtr( hdc ))) return 0; - if (fColor) - handle = CreateBitmap( width, height, GetDeviceCaps( hdc, PLANES ), + handle = CreateBitmap( width, height, GetDeviceCaps( hdc, PLANES ), GetDeviceCaps( hdc, BITSPIXEL ), NULL ); - else handle = CreateBitmap( width, height, 1, 1, NULL ); if (handle) {

Aug. 23, 2004

Re: A new regression

by Steven Edwards

Hi, --- Mike Hearn <m.hearn(a)signal.qinetiq.com> wrote: > But seriously, that patch changed a lot of very important core code > in > Wine, and the relevant math is hideously complicated (in fact nobody > does it anymore, we all just copy/paste the X server code). There > have > already been several regressions caused by that fixed, the best way > to > get more fixed is to describe exactly what you see (with screenshots, > if > possible). Or in some cases dont see. I am not 100% sure but I think this patch also causes OpenOffice to regress. It used to install and run fine but now it will run but never renders anything. Thanks Steven _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

Aug. 23, 2004

Re: CreateRemoteThread and related stuff (patch)

by Robert Shearman

Mike Hearn wrote: >> There is no need to export __wine_is_current_process from ntdll and >> use it here when standard win32 apis will suffice. > > > Oh yes, I was wondering why this was bothering me. I think you can > achieve the same effect like this: > > if ((handle == (HANDLE)0xffffffff) || > (handle == (HANDLE) NtCurrentTeb()->ClientId.UniqueProcess)) Well, not quite. You can open another handle to the process using DuplicateHandle or something else, so you need to go via the server. The simplest way to do this using Win32 is: if (GetProcessId(handle) == GetCurrentProcessId()) > > On the multiplexing - I spent a few minutes kicking around ideas for > others way to do it, but they all basically boiled down to variations > on what you've done here ... the only way to make it race free is via > the server, and that means marshalling the call into a structure and > uploading it to the server so the other process can download it when > it's been forced onto the right codepath. > > That leaves the question of how to do the forcing. > > The simplest is to have a worker thread which simply sits blocked on a > semaphore or something, and then when signalled downloads a request > from the server, dispatches it, and returns. That means spinning up a > thread at startup though, and I seem to recall that due to the dubious > history of the 'service thread' people are no longer keen on that. > > So ... another way would be to send a signal and use a signal handler > to invoke the RPC. I don't really know enough to comment on this > approach: I think the way signals work differs in kthread/pthread > systems, ie on NPTL boxes signals are sent to threads not processes > which could cause wierd races and bugs inside apps. Maybe you can > still send signals to processes in NPTL ... I don't know. > > The final way I can think of is to suspend the entire app using > ptrace, grab a thread (which?) and rewrite its register context and > stack to point at some remote_op_dispatcher function the address of > which is registered at startup with the wineserver. This downloads the > struct using the host threads wineserver connection, deals with the > request and returns. Then the stack is cleaned up, the register > context restored, and the app resumed. This seems like the best idea if it is possible. The stack doesn't need to be anything special, just a rewritable piece of memory whose location is always known. The only trouble is that creating a thread is quite complicated and involves a lot of code, so there is a chance that it may not work using this method. > Ick. That sounds really really complicated. I'd be tempted to go for > bringing back the service thread but I wasn't around when it was busy > causing pain so maybe I sound a bit blase about that :) Perhaps the old-timers can tell us a story around the camp fire about this... Rob

Aug. 23, 2004

Re: Compile on AMD Opetron

by Chuck Hall

> Hi Chuck, > > --- chall(a)bcrl.stcloudstate.edu wrote: >> If you need access to a AMD Opetron box I can setup remote access >> (via >> SSH) so you can test the code, or I can try the patches (if any) >> sent. > > I have quite a few patches for native Opertron x86-64 support on my > account at sourceforge but I doubt you want a 64bit wine as it wont let > you run any normal Windows apps. Try passing -m32 to gcc to see if it > clears up. > > Thanks > Steven > While you are right about not wanting 64bit wine, it still does not solve the problem of the interlocked function missing. I still get the same problem of the function not existing. I did try setting the build and the host variable to i686 in configure. When I get to the make part it states that the asm is not a valid 64 bit base/index expression. Would you mind adding a link to your website so I can try the patches? Have Fun! Chuck Hall

Aug. 23, 2004

Re: CreateRemoteThread and related stuff (patch)

by Mike Hearn

> There is no need to export __wine_is_current_process from ntdll and use > it here when standard win32 apis will suffice. Oh yes, I was wondering why this was bothering me. I think you can achieve the same effect like this: if ((handle == (HANDLE)0xffffffff) || (handle == (HANDLE) NtCurrentTeb()->ClientId.UniqueProcess)) seeing as -1 is a magic handle value that means the current process so I guess either input could be valid. On the multiplexing - I spent a few minutes kicking around ideas for others way to do it, but they all basically boiled down to variations on what you've done here ... the only way to make it race free is via the server, and that means marshalling the call into a structure and uploading it to the server so the other process can download it when it's been forced onto the right codepath. That leaves the question of how to do the forcing. The simplest is to have a worker thread which simply sits blocked on a semaphore or something, and then when signalled downloads a request from the server, dispatches it, and returns. That means spinning up a thread at startup though, and I seem to recall that due to the dubious history of the 'service thread' people are no longer keen on that. So ... another way would be to send a signal and use a signal handler to invoke the RPC. I don't really know enough to comment on this approach: I think the way signals work differs in kthread/pthread systems, ie on NPTL boxes signals are sent to threads not processes which could cause wierd races and bugs inside apps. Maybe you can still send signals to processes in NPTL ... I don't know. The final way I can think of is to suspend the entire app using ptrace, grab a thread (which?) and rewrite its register context and stack to point at some remote_op_dispatcher function the address of which is registered at startup with the wineserver. This downloads the struct using the host threads wineserver connection, deals with the request and returns. Then the stack is cleaned up, the register context restored, and the app resumed. Ick. That sounds really really complicated. I'd be tempted to go for bringing back the service thread but I wasn't around when it was busy causing pain so maybe I sound a bit blase about that :)

Aug. 23, 2004

Re: CreateRemoteThread and related stuff (patch)

by Robert Shearman

Alexander Yaworsky wrote: >Hello > >This is a basic framework. Not finished, not really tested -- just stable point. It does no harm for applications I'm using. I would >be glad to get some comments and suggestions. > > Looks good so far, apart from a few comments below. >@@ -168,16 +137,68 @@ > * Success: Handle to the new thread. > * Failure: NULL. Use GetLastError() to find the error cause. > * >- * BUGS >- * Unimplemented > */ > HANDLE WINAPI CreateRemoteThread( HANDLE hProcess, SECURITY_ATTRIBUTES *sa, SIZE_T stack, > LPTHREAD_START_ROUTINE start, LPVOID param, > DWORD flags, LPDWORD id ) > { >- FIXME("(): stub, Write Me.\n"); >+ extern BOOL __wine_is_current_process( HANDLE hProcess ); >+ >+ HANDLE handle; >+ CLIENT_ID client_id; >+ NTSTATUS status; >+ SIZE_T stack_reserve = 0, stack_commit = 0; >+ struct new_thread_info *info; >+ PRTL_THREAD_START_ROUTINE start_addr; >+ >+ if (!(info = VirtualAllocEx( hProcess, NULL, sizeof(*info), >+ MEM_COMMIT, PAGE_READWRITE ))) >+ return 0; >+ >+ if( __wine_is_current_process( hProcess ) ) > > There is no need to export __wine_is_current_process from ntdll and use it here when standard win32 apis will suffice. >+ { >+ info->func = start; >+ info->arg = param; >+ start_addr = (void*) THREAD_Start; >+ } >+ else >+ { >+ struct new_thread_info local_info; >+ DWORD written; >+ >+ local_info.func = start; >+ local_info.arg = param; >+ if( ! WriteProcessMemory( hProcess, &info, &local_info, > This looks wrong. &info? Don't you mean just info? > /*********************************************************************** >+ * remote_op >+ * >+ */ >+NTSTATUS remote_op( HANDLE process, int type, >+ void* params, int params_size, void* result, int* result_size ) >+{ >+ HANDLE event; >+ NTSTATUS status, remote_status; >+ >+ /* send params */ >+ SERVER_START_REQ( remote_operation ) >+ { >+ req->handle = process; >+ req->type = type; >+ if (params) wine_server_add_data( req, params, params_size ); >+ if (!(status = wine_server_call( req ))) >+ event = reply->event; >+ } >+ SERVER_END_REQ; >+ if (status) >+ return status; >+ >+ /* wait for completion */ >+ status = NtWaitForMultipleObjects( 1, &event, FALSE, FALSE, NULL ); >+ NtClose( event ); >+ if (HIWORD(status)) >+ return status; >+ >+ /* get result */ >+ remote_status = 0; /* make compiler happy */ >+ SERVER_START_REQ( remote_operation_result ) >+ { >+ wine_server_set_reply( req, result, *result_size ); >+ if (!(status = wine_server_call( req ))) >+ { >+ remote_status = reply->status; >+ if (result) >+ *result_size = wine_server_reply_size( reply ); >+ } >+ } >+ SERVER_END_REQ; >+ >+ return status? status : remote_status; >+} > > I don't really like the idea of a multiplexer like this, but I guess otherwise we would end up with duplicated code. >+ >+/* return address of internal thread start function in kernel32 */ >+DECL_HANDLER(get_kernel_thread_start) >+{ >+ struct process *process; >+ >+ /* because this is used for CreateRemoteThread, >+ required access rights must be the same >+ */ >+ if ((process = get_process_from_handle( req->handle, >+ PROCESS_CREATE_THREAD >+ | PROCESS_QUERY_INFORMATION >+ | PROCESS_VM_OPERATION >+ | PROCESS_VM_READ | PROCESS_VM_WRITE ))) > > I would argue that it is perfectly alright for the access rights to be just PROCESS_QUERY_INFORMATION here. >+ { >+ reply->address = process->kernel_thread_start; >+ release_object( process ); >+ } >+} >+ >+/* Accept parameters for remote operation and start it */ >+DECL_HANDLER(remote_operation) >+{ >+ int access; >+ struct process *process; >+ struct event *event; >+ >+ /* define required access rights */ >+ switch( req->type ) >+ { >+ case REMOTE_OP_NEW_THREAD: >+ access = PROCESS_CREATE_THREAD | PROCESS_QUERY_INFORMATION >+ | PROCESS_VM_OPERATION | PROCESS_VM_READ | PROCESS_VM_WRITE; >+ break; >+ case REMOTE_OP_VM_ALLOC: access = PROCESS_VM_OPERATION; break; >+ case REMOTE_OP_VM_FREE: access = PROCESS_VM_OPERATION; break; >+ case REMOTE_OP_VM_PROTECT: access = PROCESS_VM_OPERATION; break; >+ case REMOTE_OP_VM_QUERY: access = PROCESS_QUERY_INFORMATION; break; >+ case REMOTE_OP_VM_MAP: access = PROCESS_VM_OPERATION; break; >+ case REMOTE_OP_VM_UNMAP: access = PROCESS_VM_OPERATION; break; >+ case REMOTE_OP_VM_FLUSH: access = PROCESS_VM_OPERATION; break; /* FIXME: is access right? */ >+ default: >+ set_error( STATUS_INVALID_PARAMETER ); >+ return; >+ } >+ >+ /* get process object */ >+ if (!(process = get_process_from_handle( req->handle, access ))) return; >+ >+ /* dispose result data buffer if allocated */ >+ if (current->result_data) >+ { >+ free( current->result_data ); >+ current->result_data = NULL; >+ } >+ >+ /* create event object */ >+ reply->event = NULL; >+ if (current->result_event) >+ { >+ release_object( current->result_event ); >+ current->result_event = NULL; >+ } >+ if (!(event = create_event( NULL, 0, 1, 0 ))) >+ goto error; >+ >+ if (!(reply->event = alloc_handle( current->process, event, EVENT_ALL_ACCESS, FALSE ))) >+ goto error; >+ >+ /* FIXME: pass somehow operation type, params and originator thread id >+ for some thread in the process and force execution of operation */ >+ set_error( STATUS_NOT_IMPLEMENTED ); >+ >+ /* save event object in thread structure for future set operation; >+ we do not release it here */ >+ current->result_event = event; >+ release_object( process ); >+ return; >+ >+error: >+ if (reply->event) close_handle( current->process, reply->event, NULL ); >+ if (event) release_object( event ); >+ release_object( process ); >+} > > Is it really necessary to perform the action required for remote invocation of some operation asynchronously? It seems to add a lot of unneeded complexity. >+/* save result of remote operation and wakeup originator */ >+DECL_HANDLER(remote_operation_complete) >+{ >+ struct thread *thread = get_thread_from_id( req->originator ); >+ >+ if (!thread) return; >+ >+ /* save status */ >+ thread->remote_status = req->status; >+ >+ /* allocate buffer for result data, if required */ >+ if (thread->result_data) >+ { >+ free( thread->result_data ); >+ thread->result_data = NULL; >+ } >+ if ((thread->result_size = get_req_data_size())) >+ { >+ if ((thread->result_data = mem_alloc( thread->result_size ))) >+ memcpy( thread->result_data, get_req_data(), thread->result_size ); >+ else >+ thread->remote_status = get_error(); >+ } >+ >+ /* set event */ >+ if (thread->result_event) >+ { >+ set_event( thread->result_event ); >+ release_object( thread->result_event ); >+ thread->result_event = NULL; >+ } >+ release_object( thread ); >+} >+ >+/* return status and result data from remote opertaion */ >+DECL_HANDLER(remote_operation_result) >+{ >+ reply->status = current->remote_status; >+ >+ if (current->result_data) >+ { >+ void *result = current->result_data; >+ current->result_data = NULL; >+ set_reply_data_ptr( result, current->result_size ); > } > } > > Rob

Aug. 23, 2004

Re: {Begin,End,}UpdateResource{A,W}

by Vincent Béron

Le dim 22/08/2004 à 18:46, Vincent Béron a écrit : > Changelog: > First step for implementing the UpdateResource functions. Please don't apply, it's not ready for inclusion yet. Vincent

Aug. 23, 2004

Re: IShellLink and non-existant exe files

by Aric Stewart

You are right, I missed that second usage of exePath. I will rework my patch and resubmit it. thanks for the sharp eyes. -aric Christian Costa wrote: > Hi, > > I don't know much about this code but some line below there is: > > Stream_WriteLocationInfo( stm, exePath ); > > In our case exePath is still empty. > > Shouldn't we set exePath to the same value as This->sPath ? > > Christian > > Aric Stewart wrote: > >> It is possible under windows to create a .Lnk file to an exe file >> before it exists. Office 2000 does this, Scientific Word does this as >> do other apps as well. >> >> So a quick fix so that in IPersistFile_Save if the exe file is not >> found, trust the path we are given and allow creation of the link. >> >> ------------------------------------------------------------------------ >> >> Index: dlls/shell32/shelllink.c >> =================================================================== >> RCS file: /home/wine/wine/dlls/shell32/shelllink.c,v >> retrieving revision 1.70 >> diff -u -w -r1.70 shelllink.c >> --- dlls/shell32/shelllink.c 12 Aug 2004 23:00:53 -0000 1.70 >> +++ dlls/shell32/shelllink.c 20 Aug 2004 13:27:38 -0000 >> @@ -683,9 +683,14 @@ >> /* if there's no PIDL, generate one */ >> if( ! This->pPidl ) >> { >> + /* + * windows can create lnk files to executables >> that do not exist yet >> + * so if the executable does not exist the just trust the >> path they >> + * gave us >> + */ >> if( !*exePath ) >> - return E_FAIL; >> - >> + This->pPidl = ILCreateFromPathW(This->sPath); >> + else >> This->pPidl = ILCreateFromPathW(exePath); >> } >> >> >> > > >

Aug. 23, 2004

Re: [QUARTZDRV] Preliminary support for native OS X graphics

by Pierre d'Herbemont

Mike, Having Native Graphics Driver for Mac OS X is important for Mac User, since a X11 Apps doesn't behaves like a "normal" Mac OS X App. For instance, there is no icon for it in the Dock, which is indeed important. Moreover I am not convinced about the x11drv speed on Mac OS X. I didn't investigate much here, but the DGA extensions seems to be capital, and I don't think we'll get DGA on Mac OS X due to its windowserver architecture. Any way it is exciting to have an other driver other than x11drv and ttydrv ;) Pierre

Aug. 23, 2004