wine-devel

wine-devel@winehq.org

8 participants
84486 discussions

Re: shlfileoperation
by Uwe Bonnes 26 Oct '02

26 Oct '02

>>>>> "Dietrich" == Dietrich Teickner <Dietrich_Teickner(a)t-online.de> writes: Dietrich> Hi, I am a Odin programmer (wine for os/2). I have in Dietrich> shlfileop 3 FO_ operations full imlemented. It's tested in Dietrich> Odin. Can anyone implement and test this patch in wine ? I Dietrich> have also one test programm, if nessesary. Please send the test program. And please state how to handle your patch with regard to wine-gpl and wine-x11 license. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Loading program icon
by Peter Andersson 26 Oct '02

26 Oct '02

Hi, How do you read the icon of a windows application? Please tell me how to do it inside wine/windows-environment, and possibly independent of wine/win (the raw way). Can someone give me a hint? //Peter

1 0

Re: Listview Z0 (roll-up patch)
by David D. Hagood 26 Oct '02

26 Oct '02

Well, a cvs up -C and rebuild, and things are find here at home. I'll have to see what is up with my machine at work Monday...

1 0

Re: Listview Z0 (roll-up patch)
by David D. Hagood 25 Oct '02

25 Oct '02

Dimitrie O. Paun wrote: > > The algorithm has been: start a new series when Alexandre has committed > the previous one. So, for example, because I've started the Z-series > last night, that means that Alexandre already committed the X-series. > So the only outstanding patch not committed to CVS is Z0. I don't see a > need for a roll-up patch ;) > > That helps, but also leaves me with a conundrum - when I do a CVS update on my machine at work, and rebuild wine (make clean, make depend, make, su, wipe wine directories in /usr/local, make install, exit, run Mng4) I get the listview crash on "Along the way". I haven't been updating my machine at home, which had the patches applied, so I thought the patches were not in CVS. I will do a cvs up -C and rebuild here at home, and see what I get.

1 0

Status Report: -DSTRICT
by Michael Stefaniuc 25 Oct '02

25 Oct '02

Hello, status reports seems to be pretty popular this day so here is mine regarding compiling wine with -DSTRICT. Below is the amount of warnings we get when removing -DWINE_NO_STRICT: dll real total ------------------------------ commdlg 21 63 gdi 128 273 ntdll 148 178 ole32 16 38 shell32 120 155 user 450 839 winmm/wavemap 7 40 winmm 104 145 winsock 14 42 x11drv 60 79 ------------------------------ total 1068 1852 "real" is the number of warning for which real work is need to be done, the rest up to "total" are warnings of the type "int format, HANDLE arg". And to fix this beasts just grab http://people.redhat.com/mstefani/wine/fixpointerarg.pl and do: cd wine/dlls/$dll_in_work make clean make 2>&1 | fixpointerarg.pl and you should be done. Happy hacking bye michael P.S.: a request from Eric: please let him finish the 32bit - 16bit separation of winmm. After that is yours. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: DSTRICT: LZexpand
by Michael Stefaniuc 25 Oct '02

25 Oct '02

It seems to look good and i'm very happy about it: i almost can't see that stuff anymore. bye michael On Sat, Oct 26, 2002 at 12:05:16AM +0100, Matthew Davison wrote: > This is my first patch to wine so if it is wrong please dont chew me up > anyway, here goes. > > ChangeLog: > Made LZexpand compile with DSTRICT defined. > -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: Listview Z0 (roll-up patch)
by David D. Hagood 25 Oct '02

25 Oct '02

For those of us who are a little behind on the patches, would it be possible to get a roll-up patch of all diffs from the CVS MAIN branch? Also, what is the status of CVS vs. the patches - what patches have been applied?

4 5

Re: Known listview bugs (take 2)
by Jeff Smith 25 Oct '02

25 Oct '02

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 25 Oct '02

25 Oct '02

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 25 Oct '02

25 Oct '02

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel