Re: Fixes to SendASPI32Command:SC_GET_DEV_TYPE
Uwe Bonnes wrote: > David Elliott writes: > ... > > Actually, that looks wrong since as I said before, no program should check it > > anyway, and the spec says it always returns SS_PENDING. > > > > Hallo David, > > obviuosly we have different specs: > MSDN Library July 1995 says in Windows 95 DDK "Get Device Type Comand" > Sorry, you are correct in this case. The Get Device Type command should definitely NOT be queued and should always return SS_COMP/SS_INVALID_SRB/etc, but never SS_PENDING. For the SRB_EXEC_SCSI_CMD case, you should always return SS_PENDING, but never anything else. > > > Table 4-5. Return Values from Get Device Type Command > > > > Value Meaning > > SS_COMP SCSI/ASPI request has completed without error. > > SS_INVALID_HA Invalid host adapter number. > > SS_NO_DEVICE SCSI device not installed. > > So my prposed fix for WNASPI32_DoPosting is probably wrong and as in > my first patch we should probably set an appropriate retun value in > SendASPI32Command:SC_GET_DEV_TYPE. > I think the correct fix would be in the SRB_GET_DEVICE_TYPE case to use the value placed into the SRB_Status field instead of checking the return value. I must have overlooked that when I modified the ExecScsiCmd function to always return SS_PENDING (which is correct for the EXEC_SCSI_CMD case which it is supposed to be implementing). > > Bye > > Uwe Bonnes[EMAIL PROTECTED] > > Free Software: If you contribute nothing, expect nothing > -- -Dave
Re: Fwd: Memory leak in WineMine
Dave Pickles wrote: > Playing WineMine in 'expert' mode for 15 minutes (I'm no expert ;-)) the > machine becomes very sluggish. 'top' reports that the winemine process has > grown from 4Mb to 36Mb, and the X process from 22Mb to 64Mb. > > This is on today's CVS, btw. This is not WineMine's fault AFAICS. There is definitely a memory leak somewhere though. It is easy to duplicate, just click on the smiley face button a billion times and WineMine's memory usage will soar. It also happens running wine on the Win95 EXE. I ran it in 95 using resource meter, but there doesn't seem to be any leakage. I would check the win32 functions that CreateBoard and DrawMine use to see if they are causing the leak. Joshua Thielen __ NetZero - Defenders of the Free World Get your FREE Internet Access and Email at http://www.netzero.net/download/index.html
Re: Button fixes
Andreas Mohr <[EMAIL PROTECTED]> writes: > this resubmitted patch does: > - add "pseudo" support for button types > MAX_BTN_TYPE > (yes, they do exist in Win 95 !) > This lets Steuertips PC 99 start up correctly Wouldn't it be cleaner to simply add entries in the btnPaintFunc array instead of forcing the style to be BS_CHECKBOX? -- Alexandre Julliard [EMAIL PROTECTED]
Re: Problem with Dialog Boxes
-Original Message- From: gerard patel <[EMAIL PROTECTED]> To: galberte <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Sunday, March 26, 2000 6:56 PM Subject: Re: Problem with Dialog Boxes >At 11:53 PM 3/25/00 -0500, you wrote: >>Current versions of Wine do not allow the Tab key to move between elements >>of a dialog (ex. ChooseFont dialog). I have traced this back to a fix >>submitted on 10/24/99. > >>I suggest the following patch, but since I am very unsure in this area, I >>would appreciate any feedback. > >I am not sure that Adrian's patch is wrong. >I have a program that use ChooseFont and the Tab key works fine here. >Unless you want to say only disabled dialogs ? In this case the problem don't >seem to be too big unless I miss something :-) >Or maybe you are using a MFC program ? There are unsavory things going on >with modal dialog boxes (ChooseFont being one) in this thing. I explained some >horrible facts in my (ignored) message order dialog box patch (around Feb 15) > >HTH > >Gerard Thanks Gerard. You are right. The only two dialogs that have problems are the Font and Object selections in Wordpad from Win98. Both dialogs are disabled. The next job will be to find out why. Guy
Re: registry access denied
At 12:14 AM 3/26/00 +0100, you wrote: >Call ADVAPI32.208: RegCreateKeyExA(8002,41746ba4 >"Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall",,,,0001,,4186fb9c,4186fb94) > ret=4174692b fs=02cf >oh, we just created a key with access == KEY_QUERY_VALUE. >trace:reg:RegCreateKeyExA (0xe0,"multiDesk >v2.1b_is1",0,(null),0,2,(nil),0x4186fb98,0x4186fb94) >create key >trace:ntdll:RtlNtStatusToDosError (c022); >Ret ADVAPI32.208: RegCreateKeyExA() retval=0005 ret=417469c9 fs=02cf > access denied >This is because we try to create a key within the key 0xe0, which has >KEY_QUERY_VALUE access only. Since Juergen is busy, I tried it myself on Nt4; it works fine. I can't say if it's a specific bug of this function or if it's a general feature of the registry (maybe the desired access does not restrict the existing access in the way a file read open restrict what you can do to a file even if you have write rights) Gerard
Re: Problem with Dialog Boxes
At 11:53 PM 3/25/00 -0500, you wrote: >Current versions of Wine do not allow the Tab key to move between elements >of a dialog (ex. ChooseFont dialog). I have traced this back to a fix >submitted on 10/24/99. >I suggest the following patch, but since I am very unsure in this area, I >would appreciate any feedback. I am not sure that Adrian's patch is wrong. I have a program that use ChooseFont and the Tab key works fine here. Unless you want to say only disabled dialogs ? In this case the problem don't seem to be too big unless I miss something :-) Or maybe you are using a MFC program ? There are unsavory things going on with modal dialog boxes (ChooseFont being one) in this thing. I explained some horrible facts in my (ignored) message order dialog box patch (around Feb 15) HTH Gerard
Re: Dlls not initialized in Winelib?
On Sun, 26 Mar 2000, Eric Pouech wrote: > > Thanks! I suspected something like this. I still don't have > > sound (strange?) but I see that winmm is being initialized and it does > > not kill the program anymore. I'll debug it more tomorrow. > try to run with -debugmsg +mmsys > (IIRC wav files are external to the executable - not in a resource, so > the player may fail because current directory is not the correct one) Congratulations! Problem solved. I ran it again in the proper directory and it worked. -- Francois Gouget[EMAIL PROTECTED]http://www.multimania.com/fgouget In a world without fences who needs Gates?
Re: Wine problem with XFree 4.0
Andrew Lewycky <[EMAIL PROTECTED]> writes: > If you want to send a signal to a specific thread, use pthread_kill. This > can only be done from another thread, so we could dedicate a thread to > dispatching signals from the wineserver to wine threads. I don't like this. It quickly becomes very problematic if the server has to synchronize with a helper thread in every process. Besides we already create too many threads (and linuxthreads is not going to help here); at the present we use 4 threads plus the server simply to run Solitaire, that's already too much. > I think it's a non issue. Originally I thought that getting a signal and > longjmping repeatedly out would eventually exhaust the kernel stack. Silly > me. linuxthreads keeps track of when we are in a signal handler, but it > seems to only use that for an optimisation. The only other catch is that > if somebody calls CreateThread while on the signal stack, the child will > inherit the signal stack and although it turns it off ASAP, we will have > trouble if a signal comes in first. This sounds like a kernel bug. A cloned child should not inherit the signal stack IMO. -- Alexandre Julliard [EMAIL PROTECTED]
Re: registry access denied
> Or maybe somebody (Juergen ?) could write a test program doing exactly > the same registry access as multiDesk and run this on NT ? I'm quite busy at the moment so it can take some time (Have to roll out a >1 seats CS app and still have a 3/4 finished filedialog rewrite and a large shell patch in my queue) juergen --- [EMAIL PROTECTED] ... from sunny Berlin
Re: Wine problem with XFree 4.0
On Sun, 26 Mar 2000, Ulrich Weigand wrote: > > In any case, I know of at least one pthread implementation under Solaris/x86 > that definitely does use %gs (because due to a kernel bug not only Wine > crashes when the %gs descriptor is overwritten by Wine, but even the > kernel panics :-/) ... > Like Patrick's stdcall thunking, we should choose whether or not we need to save %gs at compile time, then arrange for tools/build to generate the appropriate thunks. If we want to be really clever, we can compile multiple different versions in and choose one at runtime without any (additional, i.e. over the cost of the thunk) performance penalty. > > (If %gs ever comes back, maybe we can convince Drepper to put hooks into > > linuxthreads for us to use. They have a function called thread_self that > > returns a pointer to their thread data structure. We could replace that > > function and just keep their data in our TEB somewhere.) > > Unfortunately, thread_self is inlined for efficiency reasons (same as our > get_teb b.t.w.). One option might be to compile a special version of > linuxthreads for use with Wine only ... On the other hand, one benefit > of using POSIX threads would be portability :-/ [ There's a whole bunch of > other things that are really Linux-specific anyway, even if we were to use > linuxthreads; foremost the assumption (by the server) that every thread > has its own pid and can be sent signals independently. ] > If you want to send a signal to a specific thread, use pthread_kill. This can only be done from another thread, so we could dedicate a thread to dispatching signals from the wineserver to wine threads. The big assumption is that we can ptrace each thread. Otherwise, we are stuck with using pthread_join to look for threads that have exited. > Ah, right. This is something I forgot: while in a signal handler, we > are not on the correct thread stack, and thus the LinuxThreads thread_self > will fail (if the %gs method is not active). This means that we cannot > use pthread routines (and by extension, many libc routines) unless we > fix this problem (e.g. by making the per-thread signal stack part of the > address space reserved for the per-thread standard stack as passed to > pthread). > I did exactly that. The signal and regular stacks are allocated contiguously, and pthreads is told about the whole range. > As to SEH: the SEH unwind *itself* doesn't longjmp, but the app-provided > handler routine called by it will typically do so. In fact, our own > WINE_exception_handler, which is used by WineLib apps and the Wine core > itself, explicitly uses longjmp, and when running Win32 apps, the handler > provided by the MS C compilers does something equivalent (without actually > returning to Wine code IIRC). > > While we can modify the Wine handler, the app-provided handlers must work > as well, so we'd have to find a way that allows signal handlers that don't > properly return ... > I think it's a non issue. Originally I thought that getting a signal and longjmping repeatedly out would eventually exhaust the kernel stack. Silly me. linuxthreads keeps track of when we are in a signal handler, but it seems to only use that for an optimisation. The only other catch is that if somebody calls CreateThread while on the signal stack, the child will inherit the signal stack and although it turns it off ASAP, we will have trouble if a signal comes in first. Andrew Lewycky [EMAIL PROTECTED]
Re: Fixes to SendASPI32Command:SC_GET_DEV_TYPE
> ...
> > Actually, that looks wrong since as I said before, no program should check it
> > anyway, and the spec says it always returns SS_PENDING.
This is true for SC_EXEC_SCSI_COMMAND
> obviuosly we have different specs:
> MSDN Library July 1995 says in Windows 95 DDK "Get Device Type Comand"
>
> > Table 4-5. Return Values from Get Device Type Command
> >
> > Value Meaning
> > SS_COMP SCSI/ASPI request has completed without error.
> > SS_INVALID_HA Invalid host adapter number.
> > SS_NO_DEVICE SCSI device not installed.
>
> So my prposed fix for WNASPI32_DoPosting is probably wrong and as in
> my first patch we should probably set an appropriate retun value in
> SendASPI32Command:SC_GET_DEV_TYPE.
I did a revised patch, appended below:
Tested with ramdisk.exe (on my Toshiba DVD) and SoftDVD Max.
Ciao, Marcus
Changelog:
fixed return value for SC_GET_DEV_TYPE
Index: winaspi32.c
===
RCS file: /home/wine/wine/dlls/winaspi/winaspi32.c,v
retrieving revision 1.3
diff -u -r1.3 winaspi32.c
--- winaspi32.c 2000/03/24 19:45:47 1.3
+++ winaspi32.c 2000/03/26 06:51:10
@@ -474,6 +476,7 @@
lpSRB->inquiry.HA_Unique[6] = 0x02; /* Maximum Transfer Length (128K, Byte> 4-7)
*/
FIXME("ASPI: Partially implemented SC_HA_INQUIRY for adapter %d.\n",
lpSRB->inquiry.SRB_HaId);
return SS_COMP;
+
case SC_GET_DEV_TYPE: {
/* FIXME: We should return SS_NO_DEVICE if the device is not configured */
/* FIXME: We should return SS_INVALID_HA if HostAdapter!=0 */
@@ -496,13 +499,17 @@
/* FIXME: handle lun */
tmpsrb.cmd.CDBByte[4] = sizeof(inqbuf);
tmpsrb.cmd.SRB_CDBLen = 6;
+
ret = ASPI_ExecScsiCmd(&tmpsrb.cmd);
-#define X(x) lpSRB->devtype.SRB_##x = tmpsrb.cmd.SRB_##x
-X(Status);
-#undef X
+
+lpSRB->devtype.SRB_Status = tmpsrb.cmd.SRB_Status;
lpSRB->devtype.SRB_DeviceType = inqbuf[0]&0x1f;
+
TRACE("returning devicetype %d for target
%d\n",inqbuf[0]&0x1f,tmpsrb.cmd.SRB_Target);
-return ret;
+if (ret!=SS_PENDING) /* Any error is passed down directly */
+ return ret;
+/* FIXME: knows that the command is finished already, pass final Status */
+return tmpsrb.cmd.SRB_Status;
}
case SC_EXEC_SCSI_CMD:
return ASPI_ExecScsiCmd(&lpSRB->cmd);
Re: Wine problem with XFree 4.0
Alex Korobka wrote: > This topic already came up before the decision to use clone(). > Pthreads API lacks several functions necessary to implement certain > Windows thread API. True, we probably cannot just use the POSIX thread API, with only the sematics as guaranteed by the standard. We could, however, use the LinuxThreads library (implementing POSIC threads on Linux) and rely -in addition to the standard semantics- on certain implementation-specific features, like the fact that every thread does, in fact, have a pid of its own which can be used to send signals and do ptrace etc. While this unfortunately means that the Wine thread handling still isn't portable (but neither is the current implementation), it might give the advantage of proper cooperation with other pthread-using libraries like libc and OpenGL *on Linux* at least. Bye, Ulrich -- Ulrich Weigand, IMMD 1, Universitaet Erlangen-Nuernberg, Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
Re: Wine problem with XFree 4.0
Andrew Lewycky wrote: > I have been holding out on you. :( I have a patch that runs wine on > pthreads in glibc 2.1, that works for 32-bit programs at least. I didn't > bother with the LDT or %gs stuff since linuxthreads-0.8 does not use it, > due to bugs in the 2.0 kernels. (So it may come back some day.) OK, I've seen the comment /* Use the LDT implementation only if the kernel is fixed. */ //#include "../useldt.h" It would appear that they are having the same problem with an (unpatched) 2.0 kernel that we have: the LDT is not properly shared between threads. In any case, I know of at least one pthread implementation under Solaris/x86 that definitely does use %gs (because due to a kernel bug not only Wine crashes when the %gs descriptor is overwritten by Wine, but even the kernel panics :-/) ... > (If %gs ever comes back, maybe we can convince Drepper to put hooks into > linuxthreads for us to use. They have a function called thread_self that > returns a pointer to their thread data structure. We could replace that > function and just keep their data in our TEB somewhere.) Unfortunately, thread_self is inlined for efficiency reasons (same as our get_teb b.t.w.). One option might be to compile a special version of linuxthreads for use with Wine only ... On the other hand, one benefit of using POSIX threads would be portability :-/ [ There's a whole bunch of other things that are really Linux-specific anyway, even if we were to use linuxthreads; foremost the assumption (by the server) that every thread has its own pid and can be sent signals independently. ] > My current biggest concern is that the signal stack handling is > problematic. When handling a SIGSEGV, and do the SEH unwind thing, do we > ever return from the signal handler, or do we just effectively longjmp > back to the right location? Ah, right. This is something I forgot: while in a signal handler, we are not on the correct thread stack, and thus the LinuxThreads thread_self will fail (if the %gs method is not active). This means that we cannot use pthread routines (and by extension, many libc routines) unless we fix this problem (e.g. by making the per-thread signal stack part of the address space reserved for the per-thread standard stack as passed to pthread). As to SEH: the SEH unwind *itself* doesn't longjmp, but the app-provided handler routine called by it will typically do so. In fact, our own WINE_exception_handler, which is used by WineLib apps and the Wine core itself, explicitly uses longjmp, and when running Win32 apps, the handler provided by the MS C compilers does something equivalent (without actually returning to Wine code IIRC). While we can modify the Wine handler, the app-provided handlers must work as well, so we'd have to find a way that allows signal handlers that don't properly return ... Bye, Ulrich -- Ulrich Weigand, IMMD 1, Universitaet Erlangen-Nuernberg, Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-27688
Fwd: Memory leak in WineMine
Playing WineMine in 'expert' mode for 15 minutes (I'm no expert ;-)) the machine becomes very sluggish. 'top' reports that the winemine process has grown from 4Mb to 36Mb, and the X process from 22Mb to 64Mb. This is on today's CVS, btw. Dave Pickles
Re: Fixes to SendASPI32Command:SC_GET_DEV_TYPE
David Elliott writes: ... > Actually, that looks wrong since as I said before, no program should check it > anyway, and the spec says it always returns SS_PENDING. > Hallo David, obviuosly we have different specs: MSDN Library July 1995 says in Windows 95 DDK "Get Device Type Comand" > Table 4-5. Return Values from Get Device Type Command > > Value Meaning > SS_COMP SCSI/ASPI request has completed without error. > SS_INVALID_HA Invalid host adapter number. > SS_NO_DEVICE SCSI device not installed. So my prposed fix for WNASPI32_DoPosting is probably wrong and as in my first patch we should probably set an appropriate retun value in SendASPI32Command:SC_GET_DEV_TYPE. Bye Uwe Bonnes[EMAIL PROTECTED] Free Software: If you contribute nothing, expect nothing --
Re: Dlls not initialized in Winelib?
> Thanks! I suspected something like this. I still don't have > sound (strange?) but I see that winmm is being initialized and it does > not kill the program anymore. I'll debug it more tomorrow. try to run with -debugmsg +mmsys (IIRC wav files are external to the executable - not in a resource, so the player may fail because current directory is not the correct one) A+ -- --- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle
RE: Wine problem with XFree 4.0
> Patrik Stridvall writes: > > > This is not what we want. Of course this is only a problem is the > > WineLib application uses gs, which is not very likely in itself. > > However it might use a Windows binary only dll that does... > > True; I guess the question becomes: are there really dlls out there > that want to mess with %gs? Probably, but I don't know of any, but then it is rather hard to now if a dlls does without testing. > > Of course doing it in a thunking layer as proposed by Ulrich (and I) > > is not very cheap runtime wise, but it is obviously correct and much > > more maintainable and the thunking layer is needed for running x86 > > binaries on non-x86 anyway. > > Saving/restoring %gs on nearly every function call is not an option. It is only needed to be saved/restored on internal/external transitions. Of course there are a lot of those when running under the emulator... WineLib applications will be largely unaffected, unless they uses gs themselves which is probable very rare and should be fixed for portabillity reason anyway. > > In short we could do both as you and Ulrich (and I) proposed and > > have compile time options and let the user decide between speed, > > Windows API only and using things like OpenGL the needs pthreads. > > Then you distribute two versions of libwine, one that is slow as hell > and one that is downright broken, but it's OK since the user has a > choice? No thanks. I wouldn't quite put it that way, but you have a point, even though it is not a very convincing one. Anyway if you look at my stdcall-thunking patch you will see that the code doesn't touch the normal Wine source files at all and the the use of thunks could be a made _runtime_ option as well at a small runtime cost. Of course if you in runtime decide to use it the cost is of course much higher... I agree that is not the ideal approach but in order to support applications that actually uses gs it is the lest bad way I can think of. BTW I just wonder how much the thunking overhead for internal/external calls really is in average for normal applications. I might be wrong but I should guess just a few percent. IIRC Linus Torsvalds once said that in the choice between a obviously correct and maintainable but slower solution and but less obviously correct and maintainable solution he would choose the first solution. Why? Because of Moore law (CPU speed double every 18 months IIRC) it will not take many months before the overhead before the introduced overhead is "eaten up" by faster CPU:s. So even if the overhead is large it will be quickly "easten up" by Moore's law. Also note that Wine is largely run on desktop machines that has a mostly idle CPU. Does a few percent or even tens of percent overhead matter under those circumstances? It will only make the CPU more idle. So what? Beside most applications like MPEG (audio/video) player that uses a lot of CPU will probably care less about the overhead because of the expensive calculations many function calls make. In short if you don't like have a compile time option make it runtime option, or even no option at all, most user will not notice the overhead anyway. PS. Yes, I know it introducies function call latency as well but I don't think it will matter for 99.99% of all applications either.
Re: Dlls not initialized in Winelib?
On Sun, 26 Mar 2000, Eric Pouech wrote: > Francois Gouget wrote: [...] > > the program dies). So I investigated a bit and found that the winmm > > library is not initialized in Winelib mode: i.e. WINMM_LibMain is not > > called. [...] > it's simply because your program doesn't import the WINMM DLL. [...] > importWINMM.DLL Thanks! I suspected something like this. I still don't have sound (strange?) but I see that winmm is being initialized and it does not kill the program anymore. I'll debug it more tomorrow. [...] > it seems that you'd need to extend your makefile/ .spec file generator Yes. Actually, I should even be able to do it automatically by analyzing the result of dumpbin (which I normally have anyway to do API cross-referencing). -- Francois Gouget[EMAIL PROTECTED]http://www.multimania.com/fgouget Linux: It is now safe to turn on your computer.
