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

RE: check box in group box regression

by Zach Gorman

Is this a general problem, or just in the hour.exe example? Is there source for hour.exe? Zach -----Original Message----- From: wine-devel-admin(a)winehq.org [mailto:wine-devel-admin(a)winehq.org] On Behalf Of Robert Reif Sent: Tuesday, August 24, 2004 8:02 AM To: Wine Develop Subject: check box in group box regression With current cvs, check boxes in group boxes are no longer displayed. See: http://www.winehq.org/hypermail/wine-bugs/2004/08/0136.html

Aug. 24, 2004

Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)

by Mike McCormack

Alexander Yaworsky wrote: > I even tried to submit a patch but it was silently ignored. Let me remind about this patch -- > http://www.winehq.org/hypermail/wine-patches/2004/06/0174.html maybe it will be useful. If you have suggestions, I promise to > rewrite it as required ;)) Hi Alexandre, Your patch is very large. It's difficult to find regressions in large patches, and it's difficult to review as so much code is changed. It may be all perfectly correct, but it's not obviously perfectly correct :) I'd suggest that you resubmit the patch and break it up into smaller chunks, so that as much as possible, each one is easy to review and makes a small understandable, atomic and necessary change. Test cases also help, if you can write them. From the looks of things your patch is well researched, and you understand what you're doing. If you submit your work in smaller chunks, I'm pretty sure it will be accepted. Mike

Aug. 24, 2004

check box in group box regression

by Robert Reif

With current cvs, check boxes in group boxes are no longer displayed. See: http://www.winehq.org/hypermail/wine-bugs/2004/08/0136.html

Aug. 24, 2004

Re: [ck] Re: Threading issues? [ck-request@vds.kolivas.org: ck Digest, Vol 3, Issue 16]

by Mike Hearn

>>Well, apparently we don't use sched_yield, so the problem must >>> lie somewhere else. Maybe Con can help us out here? Alexandre says he >>> doesn't know what the issue is either and somebody needs to investigate. I >>> guess we do need to concern ourselves over the details :) > > > Interesting. Probably the most valuable information is that it seems to > work fine if we artificially limit the threads to exactly the same > timeslice _or_ we put them at such a low priority that they are forced > to be guaranteed to round robin one task at a time. This is the way 2.4 > used to work which is why with the new 2.6 schedulers which do far more > out-of-order rescheduling some applications have a problem; particularly > under load. I suspect it's actually the latter issue. Locking between > threads should prevent that being a problem, though. You already > mentioned that you dont use sched_yield() and I couldn't even begin to > look at the wine code myself so perhaps you know something more. Hi Con, One thought that occurred to me, and this is just a random theory, is that maybe the issue is not with the Wine code but the Win32 code run on top of it. Do you know how 2.6 scheduling compares with 2.4 and Windows (NT) scheduling? Could it be that some apps are written to expect Windows-style scheduling and fail to work if they don't get it? In case you hadn't noticed, I'm afraid I only have first-year CS knowledge of scheduling :/ thanks -mike

Aug. 24, 2004

Re: A new regression

by Lionel Ulmer

On Tue, Aug 24, 2004 at 09:37:58AM +0100, Mike Hearn wrote: > For those following along, translated that means: fix that works all the > time blocks on the window management 'rewrite' which means we use X > windows only for toplevels. Last I heard this rewrite was about 2-3 > months away from completion but obviously it's not a fixed thing and > could easily take longer. Note that this will break even more all the non-fullscreen OpenGL applications pending adaptation of the GL code to support GL rendering on non-top level windows. >From what I expect, this may not be trivial at all. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 24, 2004

Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)

by Alexander Yaworsky

Hello > Dont take offence if your patch goes to the void. Just resubmit after a > a week to give it a chance to filter through Alexandre's tree. Its > possible either I merely meant that maybe something wrong with implementation. Well, I will resubmit it soon.

Aug. 24, 2004

Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)

by Shachar Shemesh

Steven Edwards wrote: >Hi Alexander, > >--- Alexander Yaworsky <yaworsky(a)migusoft.ru> wrote: > > >>I even tried to submit a patch but it was silently ignored. Let me >>remind about this patch -- >>http://www.winehq.org/hypermail/wine-patches/2004/06/0174.html maybe >>it will be useful. If you have suggestions, I promise to >>rewrite it as required ;)) >> >> > >Dont take offence if your patch goes to the void. Just resubmit after a >a week to give it a chance to filter through Alexandre's tree. Its >possible either > >1. He is going to merge it and its just taken him a while >2. He rejected it and just forgot to send a note due to the constrants >of time. >3. It went to the void in space where the lost patches go. > >Just resubmit and you should hear something back from someone. > >Thanks >Steven > > Actually, during the last wineconf, "There's nothing obviously wrong with it, but it makes Alexandre uneasy" for the usual reason patches go to void Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

Aug. 24, 2004

Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)

by Steven Edwards

Hi Alexander, --- Alexander Yaworsky <yaworsky(a)migusoft.ru> wrote: > I even tried to submit a patch but it was silently ignored. Let me > remind about this patch -- > http://www.winehq.org/hypermail/wine-patches/2004/06/0174.html maybe > it will be useful. If you have suggestions, I promise to > rewrite it as required ;)) Dont take offence if your patch goes to the void. Just resubmit after a a week to give it a chance to filter through Alexandre's tree. Its possible either 1. He is going to merge it and its just taken him a while 2. He rejected it and just forgot to send a note due to the constrants of time. 3. It went to the void in space where the lost patches go. Just resubmit and you should hear something back from someone. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

Aug. 24, 2004

Re: A new regression

by Mike Hearn

> The problem is that the app uses OpenGL for painting, and OpenGL > doesn't support the IncludeInferiors clipping mode. Fixing that > properly will require getting rid of X windows for child windows, but > in the meantime I have added a workaround that should work in most > cases. For those following along, translated that means: fix that works all the time blocks on the window management 'rewrite' which means we use X windows only for toplevels. Last I heard this rewrite was about 2-3 months away from completion but obviously it's not a fixed thing and could easily take longer. The reason it's being taken slowly is exactly so these sort of regressions can be shaken out. In the absence of branching it's the only way. thanks -mike

Aug. 24, 2004

Re: Let StartServiceCtrlDispatcher handle services started other than with StartService (with patch)

by Alexander Yaworsky

Hello In fact, the existing implementation of service subsystem in advapi32 is very poor and is sufficient only for very simple services or test programs. I tried to launch oracle 7 database under wine and that trial has been failed. The main problem was inability of parameter passing. Not only oracle -- most services require that. I did some improvements. Although I still cannot start database, because its launcher, oradim, requires CreateRemoteThread, the listener service works well (although, it cannot be fully tested because no database instance exists, but there is nothing suspicious in trace logs). I even tried to submit a patch but it was silently ignored. Let me remind about this patch -- http://www.winehq.org/hypermail/wine-patches/2004/06/0174.html maybe it will be useful. If you have suggestions, I promise to rewrite it as required ;)) Also, maybe the diagram shown below will be useful. Thanks. This simplified diagram shows interaction between three main components of win32 service subsystem. Service Control | Service Control Manager | Service Program Program | | ----------------+-----------------------------+----------------------------- | | StartService-----> LockServiceDatabase | | IF OWN_PROCES or | | (SHARE_PROCESS and Service | Program is not running)| | THEN | | | | CreateProcess===============> ... | wait for call to | initialization | StartServiceCtrlDispatcher| must not be longer | timeout=30s | than 30 seconds | | ... | if wait timed out then | ... | TerminateProcess | ... failure <---- UnlockServiceDatabase | ... | | ... | wait satisfied <============= StartServiceCtrlDispatcher | | | END IF | | | | CreateThread ***************> ServiceMain | (or CreateRemoteThread | ... | for SHARE_PROCESS; | * | if SHARE_PROCESS then | * | find entry in service | ********************** | table by service name; | * | if OWN_PROCESS then use | * | first entry) | * success <---- UnlockServiceDatabase | * | | * | accept control requests | * | | * ControlService---> request accepted ===========> ServiceControlHandler * | | ... * status <----- return status <============== SetServiceStatus * | | * | | * | | ********************** | | * | | ... | | SetServiceStatus | ExitThread <***************** (STOPPED) | if Service Program has | | now only one thread | | return control from | | StartServiceCtrlDispatcher==> ... | | ExitProcess legend: --- Service Control Program's thread === Service Program's main thread (control thread) *** Service Program's service thread OWN_PROCESS == SERVICE_WIN32_OWN_PROCESS SHARE_PROCESS == SERVICE_WIN32_SHARE_PROCESS Implementation. completely win32-based Two basic things: a) The only time the service control manager requests ownership of the lock is when it is starting a service. (C) M$DN; b) When StartService creates a new service process, it must pass arguments, or at least argv[0] - the service name - for ServiceMain across process boundary. So, use the existence of shared memory object as lock indicator and the content of object for passing service name. Also we need a wait object for monitoring process startup. The call to StartServiceCtrlDispatcher will satisfy wait condition. A dedicated shared memory object is used for each service thread. It holds other arguments, control requests and status. Also we need mutex object for serialization of control requests and two wait objects for serialization of service control program thread and service control handler thread.

Aug. 24, 2004

Re: Ignore WS_MINIMIZE and WS_MAXIMIZE in SetWindowLong

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > According to this URL a number of WS_ flags cannot be changed after > the window is created (using SetWindowLong): > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinU… > This patch uses that information and ignores just the WS_MINIMIZE and > WS_MAXIMIZE styles in SetWindowLong. That MSDN page implies that pretty much all styles can't be modified, which is definitely not true. I must say I would be surprised if WS_MAXIMIZE and WS_MINIMIZE were handled differently from the rest. Could you please provide a test case? -- Alexandre Julliard julliard(a)winehq.org

Aug. 24, 2004

Re: CreateRemoteThread and related stuff (patch)

by Alexander Yaworsky

Hello > There is no need to export __wine_is_current_process from ntdll and use > it here when standard win32 apis will suffice. > 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()) You miss. It seems we really need __wine_is_current_process. > >+ if( ! WriteProcessMemory( hProcess, &info, &local_info, > > > This looks wrong. &info? Don't you mean just info? Yes! Thanks. > >+ 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. Maybe. But with the full set of access rights CreateRemoteThread will return earlier in case of error. > 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. What shall we do with csVirtual critical section in ntdll/virtual.c?

Aug. 24, 2004

Re: A new regression

by Alexandre Julliard

"Ivan Leo Puoti" <puoti(a)inwind.it> writes: >> (with screenshots, if possible). > before the patch > http://www003.portalis.it/115/download/1.png > and after it > http://www003.portalis.it/115/download/2.png The problem is that the app uses OpenGL for painting, and OpenGL doesn't support the IncludeInferiors clipping mode. Fixing that properly will require getting rid of X windows for child windows, but in the meantime I have added a workaround that should work in most cases. -- Alexandre Julliard julliard(a)winehq.org

Aug. 24, 2004

Re: A new regression

by Ivan Leo Puoti

> (with screenshots, if possible). before the patch http://www003.portalis.it/115/download/1.png and after it http://www003.portalis.it/115/download/2.png The app is a free download. Ivan.

Aug. 23, 2004

Re: Compile on AMD Opetron

by Marcus Meissner

On Mon, Aug 23, 2004 at 09:41:55AM -0500, Chuck Hall wrote: > > 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? Use: export LD="ld -m elf_i386" CC="gcc -m32" AS="gcc -c -m32" ./configure --prefix=/usr --x-libraries=/usr/X11R6/lib make depend all to build on amd64. Ciao, Marcus

Aug. 23, 2004

Re: DbgHelp: Fix for Includes with Relative Paths

by Eric Pouech

which means that: - we create a new compilation unit (for example) on 2205 => this gives the source directory - we start the main compilation unit on 2206 => /home/dm/wine/dlls/dbghelp/elf_module.c - in this CU, we start a new include file (on xxxx), => /home/dm/wine/dlls/dbghelp/../../include/winbase.h - ... - we close the CU on 4978 Basically, as I wrote, you don't need two different beasts: currpath and srcpath. They refer to the same object, but the code is wrong. We should: - store the current directory on first SO (or the SO ended by a '/', which would be better) - on a non NULL SO, not ended by a '/' create a new compilation unit by concatening curr dir and the file name (or if file name is absolute, use the filename) - for each SOL, get the file name by concatening the curr dir with the file name (this operation is the same as above). - nuke the curr dir when getting a NULL SO current code is wrong as it creates two compilands for each compilation unit (one for each non NULL SO) A+

Aug. 23, 2004

Re: DbgHelp: Fix for Includes with Relative Paths

by Robert Shearman

Eric Pouech wrote: > Robert Shearman a écrit : > >> Hi, >> >> On startup, the debugger usually prompted me to type the path where >> "/winternl.h" can be found. This was due to the path being stored >> internally as "../../include/winternl.h", i.e. relative to the source >> directory. This patch adds the ability to store the source directory >> and then use it when encountering an include path of this type to get >> the full path, which means no more prompting. >> >> Rob >> >> Changelog: >> Store the current source directory and use it when encountering a >> relative include so that the full path to it is stored instead. >> > Robert, normally currpath is supposed to be the directory where the > file has been compiled. So, IMO currpath and srcpath duplicate the > same stuff. > > Does it mean that you only get one N_SO per compilation unit ? (the > code assumes two: the first one for the dir, the second for the path). [dm(a)rob dm]$ objdump -G /usr/local/lib/wine/dbghelp.dll.so | grep " SO " | more 0 SO 0 0 00015d9c 11 /home/dm/wine/dlls/dbghelp/ 1 SO 0 0 00015d9c 1 dbghelp.c 2204 SO 0 0 000163b9 0 2205 SO 0 0 000163bc 11 /home/dm/wine/dlls/dbghelp/ 2206 SO 0 0 000163bc 166272 elf_module.c 4978 SO 0 0 00017c24 0 4979 SO 0 0 00017c24 11 /home/dm/wine/dlls/dbghelp/ 4980 SO 0 0 00017c24 346388 image.c 6782 SO 0 0 00017cf6 0 ... The real problem is the N_SOL entries, which is what the patch fixes: [dm(a)rob dm]$ objdump -G /usr/local/lib/wine/dbghelp.dll.so | grep " SOL " | more 1917 SOL 0 0 00015ddf 35504 ../../include/winbase.h 1934 SOL 0 0 00015dec 1 dbghelp.c 1941 SOL 0 0 00015e16 35504 ../../include/winbase.h 1946 SOL 0 0 00015e56 1 dbghelp.c 2013 SOL 0 0 00015fc6 35504 ../../include/winbase.h 2016 SOL 0 0 00015fda 1 dbghelp.c 2020 SOL 0 0 00015ff1 35504 ../../include/winbase.h 2023 SOL 0 0 00016020 1 dbghelp.c ... Rob

Aug. 23, 2004

Re: DbgHelp: Fix for Includes with Relative Paths

by Eric Pouech

Robert Shearman a écrit : > Hi, > > On startup, the debugger usually prompted me to type the path where > "/winternl.h" can be found. This was due to the path being stored > internally as "../../include/winternl.h", i.e. relative to the source > directory. This patch adds the ability to store the source directory and > then use it when encountering an include path of this type to get the > full path, which means no more prompting. > > Rob > > Changelog: > Store the current source directory and use it when encountering a > relative include so that the full path to it is stored instead. > Robert, normally currpath is supposed to be the directory where the file has been compiled. So, IMO currpath and srcpath duplicate the same stuff. Does it mean that you only get one N_SO per compilation unit ? (the code assumes two: the first one for the dir, the second for the path). A+

Aug. 23, 2004

Re: Compiling Wine on Windows

by Steven Edwards

Hi Todd, --- "Todd S." <sias.programming(a)suessweb.com> wrote: > My name is Todd, and I am trying to compile the Wine DLLs within a > Windows XP DOS-Box. I am using MingW with a newer version of Make, > GCC, G++, etc. I type "make" within the directory and all that is > returned is: "make: *** No targets specified and no makefile found. > Stop.". > > Do I need a different version of "Make" or do I just need something > else? You need MSYS from the mingw project so you can run ./configure I think you may also need the MSYS-DTK for bison and flex. 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

Compiling Wine on Windows

by Todd S.

Dear wine-devel Forum, My name is Todd, and I am trying to compile the Wine DLLs within a Windows XP DOS-Box. I am using MingW with a newer version of Make, GCC, G++, etc. I type "make" within the directory and all that is returned is: "make: *** No targets specified and no makefile found. Stop.". Do I need a different version of "Make" or do I just need something else? Thanks, Todd Suess

Aug. 23, 2004

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