- Wine-Devel - list.winehq.org

Re: Known listview bugs (take 2)
by Jeff Smith Oct. 25, 2002

Oct. 25, 2002

Just a couple of days ago, the problem with native (W95-OSR2.1) regedit was that changing keys in the tree kept piling up new items in the listview. It was quite interesting seeing multiple (Default) values for a key :-). Now (12 hours ago anyways) it is always blank. When I click on where the values should be (highlight them), sometimes they will show up then. It seems something is not being refreshed that should be. Maybe I'll get a chance to dig in later today if nothing has been uncovered by then. -- Jeff S. >From: Greg Turner <gmturner007(a)ameritech.net> > >On Friday 25 October 2002 07:35 am, Dimitrie O. Paun wrote: > > On October 25, 2002 02:36 am, Greg Turner wrote: > > > So, I know this has been discussed before... but I can't recall: is > > > native (W98) regedit expected to work right now? For me, it doesn't. > > > > Well, I don't have that application, so you'll need to help debug > > it if you want it working :). First step is a --debugmsg +listview. > > If you think that's relevant, a screenshot too. > >ok, I'll do this tonight, and maybe even try to drill in a little deeper >if I can figure anything interesting out. FYI, I think this problem >existed before your listvew work started, so its probably not your >doing. > >BTW, thanks for your ongoing work, listviews feel much better lately! > >-- >gmt _________________________________________________________________ Unlimited Internet access -- and 2 months free! Try MSN. http://resourcecenter.msn.com/access/plans/2monthsfree.asp

2 1

interrupts in when in NT version
by Zsolt Rizsanyi Oct. 25, 2002

Oct. 25, 2002

Hi! I have Laurent Pinchart's safedisc patch applied and working for a while now. (and it works perfectly). But the recent interrupt changes tend to cause cvs conflicts and to break it. This patch is supposed to work only if winver is nt40 so very probably this applies only to NT. What the patch relies on is that the interrupt handling code (which was INSTR_EmulateInstruction before the changes), return EXCEPTION_ACCESS_VIOLATION if interrupt 0x01 is called (if I understand it correctly). This was done with the next patches: Index: dlls/ntdll/signal_i386.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/signal_i386.c,v retrieving revision 1.46 diff -u -p -r1.46 signal_i386.c --- dlls/ntdll/signal_i386.c 12 Sep 2002 22:07:03 -0000 1.46 +++ dlls/ntdll/signal_i386.c 24 Oct 2002 10:13:36 -0000 @@ -729,6 +729,7 @@ static void do_segv( CONTEXT *context, i { EXCEPTION_RECORD rec; DWORD page_fault_code = EXCEPTION_ACCESS_VIOLATION; + DWORD priv_instr_code = EXCEPTION_PRIV_INSTRUCTION; #ifdef CR2_sig /* we want the page-fault case to be fast */ @@ -758,8 +759,8 @@ static void do_segv( CONTEXT *context, i case T_SEGNPFLT: /* Segment not present exception */ case T_PROTFLT: /* General protection fault */ case T_UNKNOWN: /* Unknown fault code */ - if (INSTR_EmulateInstruction( context )) return; - rec.ExceptionCode = EXCEPTION_PRIV_INSTRUCTION; + if (INSTR_EmulateInstruction( context, &priv_instr_code )) return; + rec.ExceptionCode = priv_instr_code; break; case T_PAGEFLT: /* Page fault */ #ifdef CR2_sig Index: memory/instr.c =================================================================== RCS file: /home/wine/wine/memory/instr.c,v retrieving revision 1.19 diff -u -p -r1.19 instr.c --- memory/instr.c 23 Oct 2002 22:24:10 -0000 1.19 +++ memory/instr.c 24 Oct 2002 10:14:08 -0000 @@ -397,7 +397,7 @@ static void INSTR_outport( WORD port, in * * Emulate a privileged instruction. Returns TRUE if emulation successful. */ -BOOL INSTR_EmulateInstruction( CONTEXT86 *context ) +BOOL INSTR_EmulateInstruction( CONTEXT86 *context, DWORD *exception_code ) { int prefix, segprefix, prefixlen, len, repX, long_op, long_addr; SEGPTR gpHandler; @@ -685,6 +685,29 @@ BOOL INSTR_EmulateInstruction( CONTEXT86 break; /* Unable to emulate it */ case 0xcd: /* int <XX> */ +<<<<<<< instr.c + if (long_op) + { + ERR("int 0x%02x from 32-bit code is not supported.\n", instr[1]); + if (instr[1] == 0x01) + *exception_code = EXCEPTION_ACCESS_VIOLATION; + break; /* Unable to emulate it */ + } + else + { + FARPROC16 addr = INT_GetPMHandler( instr[1] ); + WORD *stack = get_stack( context ); + /* Push the flags and return address on the stack */ + *(--stack) = LOWORD(context->EFlags); + *(--stack) = context->SegCs; + *(--stack) = LOWORD(context->Eip) + prefixlen + 2; + add_stack(context, -3 * sizeof(WORD)); + /* Jump to the interrupt handler */ + context->SegCs = HIWORD(addr); + context->Eip = LOWORD(addr); + } + return TRUE; +======= if(!Dosvm.EmulateInterruptPM && !DPMI_LoadDosSystem()) ERR("could not initialize interrupt handling\n"); else { @@ -693,6 +716,7 @@ BOOL INSTR_EmulateInstruction( CONTEXT86 return TRUE; } break; /* Unable to emulate it */ +>>>>>>> 1.19 case 0xcf: /* iret */ if (long_op) The second one is pretty ugly since I have not resolved the cvs conflict (I'm waiting for your input :), but the important part is this: + if (long_op) + { + ERR("int 0x%02x from 32-bit code is not supported.\n", instr[1]); + if (instr[1] == 0x01) + *exception_code = EXCEPTION_ACCESS_VIOLATION; + break; /* Unable to emulate it */ + } Here is the EXCEPTION_ACCESS_VIOLATION is returned if interrupt 0x01 is called. This was good when interrupts from 32-bit code were not supported. But now we need a special case for this. I think that on NT calling 0x01 is forbidden. But I have not tested this (and will not, because I dont have windows devel tools - I just want to run my Longman Dictionary :) I would like if this could be fixed properly and that would work with the safedisk patch, if thats possible. Thanks Zsolt

5 4

Re: [linux-audio-dev] Fwd: Opinions on running VST or DirectX plugins on Linux in real time
by Kjetil S. Matheussen Oct. 25, 2002

Oct. 25, 2002

On 23 Oct 2002, Benno Senoner wrote: > I contacted the author of the VQF plugin about opinions of running > windows plugins under Linux. He is not subscribed to LAD so he told me > to forward this mail to the list. > cheers, > Benno > Interesting. But one idea I just got... Could it be possible to overcome all problems mentioned just by simply adding jack-support to the wine-server? Then someone could make a simple windows-program for chaining directx and vst plug-ins. I dont know how the wine-server works though, so please shout out if its not possible. > On Tue, 22 Oct 2002, Benno Senoner wrote: > > > We are currently discussing about the possibility to run VST or > DirectX audio > > plugins on Linux in real time. > > I remember you wrote an xmms plugin that allowed to run the windows > VQF plugin > > under Linux using wine & co. > > <snip> > > It would be cool if you could write on the linux-audio-dev list about > > experiences in that field. > > I am afraid I will have to keep this short as I'm really busy at the > moment. I also am a long way from being an audio expert or wine so I > doubt > my experiences will be of much use to you hence I didn't subscribe to > the > list . Feel free to forward this to the audio-dev list and cc me on it > if > you wish > > First, the solution I used for the VQF plugin was extremly clunky. There > was no way of letting the plugin run inside XMMS without causing > segfaults. They simply did not merge well no matter what I tried. > > I suspect but never proved that it was how WINE has to lay out it's > memory > to be able to mimic how Windows sees things like segments. The layout is > drastically different to how a Linux app normally sees things. By the > time > a VQF plugin could be loaded, the two very differnet approaches to > managing memory simply did not work well together > > In the end, the solution used was this; > > 1. At XMMS start, fork and exec an application that uses libwine to load > the windows DLL. Communicate with the parent through pipes, sockets > or > shared memory > > 2. Start up XMMS as normal > > 3. The plugin just implements stub functions for every routine a plugin > is > meant to implement and communicates the information to the child > > This had a number of issues. First, it was difficult to get information > from the plugin. It opened the sound device directly itself which meant > that visualisation data was not available. > > At one point, this was resolved by hacking wine itself to write the PCM > data to a named pipe rather than playing to a device but needless to > say, > it was too ugly to live and couldn't really be distributed easily. (I > considered it unreasonable to get users to patch and compile WINE just > to > play a piece of music, visualisations weren't that important). > > If I had a nice plugin, what I would try to do is set up two unamed > pipes > at application start to a child application using libwine. One pipe for > writing would send commands and one pipe for reading would take PCM > data. > I don't know how viable this is for you. > > > I'm not a windows / wine expert but commonsense says me it should be > > possibile to run these windows plugins under Linux in real time with > small > > buffer sizes in order to get low response times (low latency). > > I would be inclined to go the other way. With the above solution, I > would > try and buffer as much data as humanly possible to try and avoid the > overhead of calling wine constantly. For example, I would try and get 10 > seconds worth of data from the windows plugin before starting to play > anything. Once I had the PCM data, it would not matter if the plugin > could > not make real time contraints. > > > It should be possible to let wine handle the GUI stuff . (if word and > excel > > runs then it should be able to run plugin GUIs too). > > It can, but remember that if you are trying to use this plugin with a > normal application, you are likely to run into a lot of trouble. At > least > I did, but this was a few years back. Things might be different now > > I imagine you already have checked out how avifile loads it's plugins. > When I last looked at it (a few years back), it was using a stripped > down > version of WINE to just load the plugins and get the function pointers. > It > might be worth checking into. > > -- > Mel Gorman > MSc Student, University of Limerick > http://www.csn.ul.ie/~mel > > > > >

4 5

Re: Resubmitted - Prefereable GetDateFormatW fix
by Dimitrie O. Paun Oct. 25, 2002

Oct. 25, 2002

On October 25, 2002 12:39 pm, Medland, Bill wrote: > (Sorry Dimi; it has to be an attachment to stop the mailer wrapping it) No, it doesn't, as long as you set up your mail to not wrap. Or, alternatively, just add it as text/plain, so it is displayed inline. But actually inlining it is better, because people can reply to it, and easily quote the portion of interest. -- Dimi.

1 0

How can an app detect it's running under WINE?
by Alberto Massari Oct. 25, 2002

Oct. 25, 2002

Hi everybody, I am working on making our software (Stylus Studio, http://www.stylusstudio.com) run under WINE, if this is feasible. To achieve this, I have already implemented a bunch of APIs (the application is built against the UNICODE version of the Win32 APIs) and fixed some bugs I hit (I already mailed the first patch to wine-patches(a)winehq.com) However, I would feel better if I could detect I am running under WINE and gracefully disable some functionalities that are not yet fully supported; is there any way to achieve this? Is there a WIN32 API (like, say, GetVersionEx) that can return a string like "Windows 2000 (WINE)" or is WINE trying to be as stealth as possible? Thanks in advance, Alberto ------------------------------- Alberto Massari eXcelon Corp. http://www.StylusStudio.com

4 3

RE: How can an app detect it's running under WINE?
by Patrik Stridvall Oct. 25, 2002

Oct. 25, 2002

> --- Patrik Stridvall <ps(a)leissner.se> wrote: > > > So that is why there is no OFFICAL way to detect > > Wine, simple because > > if where was an offical way people could quite > > reasonable complain if > > some change to Wine broke their detection. However > > since there are no > > offical way, they can't complain can they? :-) > > Probably it's time to make an "official" way? No and IMHO there is no reason to have an offical way at all. > This problem appears with each application, ported > with Wine and isn't going to go away even when Wine > will correctly implement all Windows api ;-) If Wine implement every Windows API, why do you care whether you are running under Wine at all? Your application works as good as it does under Windows. Period. Of course you might better intergration with X Windows, printing or whatever to make your application work EVEN BETTER under Wine. :-) Then you have two choice: 1. Recompile your application using Winelib and use Unix API's 2. Under Windows, link with and use some "Wine extension" DLL that are just in many cases "return FALSE; SetLastError(ERROR_NOT_IMPLEMENTED)" on Windows but are implemented on Unix (or some Unixes). Sure (2) currently doesn't exist yet. However it wouldn't be very difficult to do it, if there is need. But no these functions are not for detecting Wine they are for tighter intergration with the underlying "OS" like X Windows, printing or whatever. However this is IMHO far beyond 1.0, so don't hold your breath. But sure if you can name some "Wine extension" API we REALLY need we might do it sooner... PS. Theoretically, the "Wine extensions" DLLs might be implementated on some future version Windows as well and it would be quite ironical if Microsoft did in the future. :-)

1 0

Re: How can an app detect it's running under WINE?
by Alberto Massari Oct. 25, 2002

Oct. 25, 2002

Hi Andreas, At 03.12 25/10/2002 -0500, you wrote: >Message: 13 >Date: Fri, 25 Oct 2002 10:10:32 +0200 >From: Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> >To: Alberto Massari <alby(a)exln.com> >Cc: wine-devel(a)winehq.com >Subject: Re: How can an app detect it's running under WINE? >Reply-To: andi(a)rhlx01.fht-esslingen.de > >On Fri, Oct 25, 2002 at 09:25:23AM +0200, Alberto Massari wrote: > > Hi everybody, > > I am working on making our software (Stylus Studio, > > http://www.stylusstudio.com) run under WINE, if this is feasible. To > > achieve this, I have already implemented a bunch of APIs (the application > > is built against the UNICODE version of the Win32 APIs) and fixed some > bugs > > I hit (I already mailed the first patch to wine-patches(a)winehq.com) > > > > However, I would feel better if I could detect I am running under WINE and > > gracefully disable some functionalities that are not yet fully supported; > > is there any way to achieve this? Is there a WIN32 API (like, say, > > GetVersionEx) that can return a string like "Windows 2000 (WINE)" or is > > WINE trying to be as stealth as possible? >http://www.winehq.org/FAQ/ would have been answering this in countless >cases already. I'm sorry I asked this here, but the only help I got from the FAQ was: ------ Q: How can I detect Wine? A: You really shouldn't want to do this. If there's a quirk in Wine you need to work around, it's *much* better to fix it in Wine (after all you're a developer, so you should be able to gather enough help and knowledge to fix it for real). If you think you really want to know how to detect it anyway (maybe in order to just have a cool "running on Wine" status text or so), then please mail me. (address-suppressed) ------ So I though I could ask it here.... Alberto ------------------------------- Alberto Massari eXcelon Corp. http://www.StylusStudio.com

4 4

RE: How can an app detect it's running under WINE?
by Patrik Stridvall Oct. 25, 2002

Oct. 25, 2002

> At 13.22 25/10/2002 +0200, Andreas Mohr wrote: > >On Fri, Oct 25, 2002 at 10:30:15AM +0200, Alberto Massari wrote: > > >[...] > > > >Like someone else said (IIRC), you could check for the existence > >of the Wine configuration registry key branch. That'd be a > 150% reliable > >method of detecting Wine presence. > > > >But again, trying to fix issues would be preferrable. > >(unless there are just too many problems to be fixed) > > Thanks for your answers: we all agree that the best thing to > do is to have > WINE support all the WIN32 API, and mimic all the Windows flavors. > But just like an application calls GetVersionEx to decide how > to behave on > a specific platform, it is perfectly valid for it to try to > detect WINE as > a variant of Windows, and react accordingly. That registry > information is > the right piece of information, as it could also be used to > instruct the > user on the changes needed to make the application work better. Oh sure, you CAN detect Wine if you want, the point is that the Wine project reserves the right to change any behavior at any time for any reason, but most often in order to try to make some application more compatible with Windows. If this breaks your Wine detection, tough. We will not change back because of you. So that is why there is no OFFICAL way to detect Wine, simple because if where was an offical way people could quite reasonable complain if some change to Wine broke their detection. However since there are no offical way, they can't complain can they? :-)

2 1

Whats done? not?
by Christensen Tom Oct. 25, 2002

Oct. 25, 2002

Obviously wine is still being actively developed, and I know its not close to "done" however, I want to get involved, I know C/C++ and have a pretty good grasp of windows apis, I'm just wondering is there a place (kinda like in the Mono project they have a tree laid out with all of the classes/functions that are in the .NET runtime, and they have them marked done, being worked on, not started...) So I'm wondering if wine has anything similar? or should i just pick a function, and see if its done already by searching through the source? At any rate, wine should have a nice concise place to look and see if wine has certain functions implimented.. Tom _________________________________________________________________ Broadband? Dial-up? Get reliable MSN Internet Access. http://resourcecenter.msn.com/access/plans/default.asp

4 3

Re: How can an app detect it's running under WINE?
by Greg Turner Oct. 25, 2002

Oct. 25, 2002

On Friday 25 October 2002 03:55 am, Uwe Bonnes wrote: > >>>>> "Greg" == Greg Turner <gmturner007(a)ameritech.net> writes: > Greg> I don't like this solution. Those entries are likely to be > Greg> present in certain shared wine / native windows configurations. > > The "Software\\Wine\\Wine\\Config" tree is read from ~/.wine/config on each > startup and is not written to a .reg file. So if it ret mixed, things are > broken. > > Bye I didn't think of those. you are right, that seems pretty safe. -- gmt "Oh, and of course, the fastest way to dig a tunnel is to dig at both sides." -- The Linux Advanced Routing HOWTO

1 0