wine-devel

wine-devel@winehq.org

3 participants
84400 discussions

Re: async_private + ReadFile() etc. immediate completion
by Mike McCormack 11 Jan '02

11 Jan '02

Hi Martin, I haven't tried the patch yet, but from Lawson's trace it looks like the completion routine for ReadFileEx is not being called. Some notes: * the 16bit Comm code expects ReadFileEx to be unconditionally overlapped, and always call the completion function when the operation completes. * the completion function starts another ReadFileEx, and sends a WM_COMMNOTIFY message to the 16bit app. i had a look at you patch, but i haven't applied it yet, so it's difficult for me to see any problems... i'll have a go later today. Mike Original message from: lawson_whitney(a)juno.com > >On Thu, 10 Jan 2002, Martin Wilck wrote: .. >> I cannot test the serial comm code and must kindly ask somebody else >> to try that. >> >> Martin >> >> >It doesn't bother my 32 bit app, but the 16 bit app is unable to >initialize the modem. +comm,+file trace attached. > >Lawson ------------------------------------------ mailto:Mike_McCormack@start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

2 1

RE: ADPCM and Wine
by Patrik Stridvall 11 Jan '02

11 Jan '02

> On Fri, Jan 11, 2002 at 07:16:30AM -0600, David D. Hagood wrote: > > I have an app that I use (Delorme's AAA MapNGo 4.0) that > uses ADPCM wave > > files to contain spoken information on attractions. I know > that Wine can > > access my sound system to play normal PCM wave files, as > MN4 also has > > speech synthesis that does work. However, any attempt to > play a ADPCM > > file results in the program pausing for a length of time, then > > continuing. I infer that this is because the lower levels > of Wine don't > > know how to handle ADPCM. [snip] > Try --debugmsg > +driver,+mmsys,+mci,+mmio,+mmtime,+mciwave,+msacm,+wave,+midi,+ > mmaux,+relay (they're all inside dlls/winmm/*). > > That should help a lot in finding what's missing. Well, the ADPCM codec is not implemented in MSACM32 so it really can't work, can it? Anyway seeing the debug output can't hurt either.

1 0

RE: ADPCM and Wine
by Patrik Stridvall 11 Jan '02

11 Jan '02

> Is anybody working on support for playing ADPCM wave files > under Wine? Not that I know of. > If not, I'd like to take a crack at it. By all means. > I have an app that I use (Delorme's AAA MapNGo 4.0) that uses > ADPCM wave > files to contain spoken information on attractions. I know > that Wine can > access my sound system to play normal PCM wave files, as MN4 also has > speech synthesis that does work. However, any attempt to play a ADPCM > file results in the program pausing for a length of time, then > continuing. I infer that this is because the lower levels of > Wine don't > know how to handle ADPCM. That most likely correct. > ADPCM isn't rocket science - several programs, including sox, > understand > the protocol. OK. > So, is anybody working on this (outside of TG and Lindows)? Any > (non-null) pointers to useful information on how Wine has put > together > the sound subsystem? I'm not a Windows programmer, I'm an embedded > systems and DSP person, but if I can find a block of code to > hook into I > can make this happen. I suggest you talk to Eric Pouech <eric.pouech(a)wanadoo.fr>. He was active on the patch list yesterday so I suppose he will see this and reply. In the mean time I can tell you that the PCM support is in wine/dlls/mcacm and ADPCM support should be there as well. There is a file pcmconverter.c that implements PCM support so I suppose that there should be a adpcmconverter.c file to plug in the ADPCM support. There will probably need to be a few changes in other files as well. Anyway Eric understands this better than I do. Let's wait and see what he has to say.

1 0

Re: async_private + ReadFile() etc. immediate completion
by lawson_whitney＠juno.com 11 Jan '02

11 Jan '02

On Thu, 10 Jan 2002, Martin Wilck wrote: > > Hi, > > The patch below is a reworked version of the one posted yesterday > to wine-devel. > > I received only one rather positive comment from Mike, so I assume > everybody is d'accord :-) > > The patch is still long but actually adds only 50 lines. I find it very > hard to split it into seperate smaller ones. > > There were a few bugs, but now the patch runs fine with my regular file > IO test code. The code tests ReadFileEx() (always asynchronous) > ReadFile() (synchronous if possible, i.e. always synchronous on regular > files), and CancelIo(). > > In particular, the GetOverlappedResult() call in ReadFile() seems to work > as expected. > > I cannot test the serial comm code and must kindly ask somebody else > to try that. > > Martin > > It doesn't bother my 32 bit app, but the 16 bit app is unable to initialize the modem. +comm,+file trace attached. Lawson ---oof---

1 0

Re: Handle quotes in command lines
by Francois Gouget 11 Jan '02

11 Jan '02

On Thu, 10 Jan 2002, Uwe Bonnes wrote: > Hallo, > > some application builds a commandline with arguments enclosed by quotes '"', > starts a daughter process with this commandline and relies on the quotes > being intact in the daughter process. Wine happily removed the quotes and so > the daughter process failed. > Appended patch keeps quotes intact, tested via CreateProcess and calling a > programm from the shell. When invoking wine from the shell, quotes need to > be escaped, like any other special characters. No. Your patch mishandles quotes. Normal behavior: $ ./createp Type the command to execute: main a\"b "c\"d\\" e CreateProcess returned: 1 error=0 GetCommandLine=[main a\"b c\"d\ e] main -> argc=4 0 [main] 1 [a"b] 2 [c"d\] 3 [e] With your patch: main a\"b "c\"d\\" e CreateProcess returned: 1 error=0 GetCommandLine=[main "a\b "c\d\\"" e] main -> argc=3 0 [main] 1 [a\b "c\d\"] 2 [e] main -> __argc=3 0 [main] 1 [a\b "c\d\"] 2 [e] With your patch we: * change the command line from what was specified, just as before * add quotes where there are none * misinterpret quotes * don't split arguments properly anymore The existing quote handling is perfect! I tested and retested it. The problem you are having is that we cannot garantee that the child process will get the exact same commandline because of the cmdline -> argv -> cmdline conversion. The fix for your problem is to pass the command line to the child process via a wineserver call or something. Guess which is the first test I am going to write with the new testing framework!!! (and I would much prefer to print the contents of argv to file than to try and hard-code all the checks in the child, plus how am I going to know which was the command line that was given to me anyway!) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

3 3

Re: Changes regarding wnaspi32 layer ?
by ma.hoff＠t-online.de 11 Jan '02

11 Jan '02

Mhhh, must have been an issue with a not properly installed Wine on my machine ! As you told me i ran some tests: First with the working 20010731 build ! Then i decided to switch to cvs from 20011226 and did ./tools/wineinstall ! Guess what, it was not reproducable :-/ With the fresh compiled cvs from 20011226 it works, too ... So, i can only imagine that last time i installed a newer version i must have mixed up anything (or had a bad rpm - this time i compiled my own !) Thank you anyway ! For me it's solved... (being happy) Martin Am Montag, 7. Januar 2002 09:28 schrieben Sie: > >>>>> "Martin" == Martin Hoffmann <ma.hoff(a)t-online.de> writes: > > Martin> Hi, i have some problems with the winaspi implementation (scsi > ... > > Martin> Guess what: --winver nt40 / win31 didn't change anything :-) > > Martin> So it seems that its not implemented, but with older versions > it Martin> worked ! > > Run a test with --debugmsg +relay,+snoop,+aspi and look what happens before > the message about the VXD happens. Quote what you feel important ( and a > little more) to the list if you don't find anything. > > Bye

2 1

Lindows screenshots
by Hetz Ben Hamo 11 Jan '02

11 Jan '02

Hi, I just got this - Lindows released 2 screenshots of their Lindows: www.lindows.com/screenshots Now, IF they did use wine (and thats a big if - from the screenshots they're running either Office 2K or office XP, Internet Explorer, the fonts looks like MS TTF fonts, and I think those screenshots are modified a bit - look at the 2nd screenshots, behind the start menu - look at the "file/edit/view" menu - it should be alligned to the left) and they'll contribute some parts of their wine to the standard wine - then wine will be in much better shape then what is it today. Hetz

9 11

How about sponsoring from IBM?
by Roland 10 Jan '02

10 Jan '02

Hello, it seems that IBM is becoming a major Linux advocate. What would be the possibilities of having it sponsor the WINE project? I mean 1 Million dollars is not much for IBM, but it certainly would mean a lot to the development of WINE. IBM would also profit of this. Since Linux runs on their supercomputers, it would be nice if you could run all Windows programs there(you need another Pentium emulator then, but that would not be a big problem, would it?). Just thinking about this... Roland

3 2

RE: Debugger set breakpoint with full filename
by Medland, Bill 10 Jan '02

10 Jan '02

> -----Original Message----- > From: eric [mailto:eric.pouech@wanadoo.fr] > Sent: Thursday, January 10, 2002 12:49 PM > To: Medland, Bill > Cc: Wine devel (E-mail) > Subject: Re: Debugger set breakpoint with full filename > > > > Unfortunately not. > it should (under the name EntryPoint) > try MyDLL.EntryPoint, it should work Ah! Thanks p.s. you DO need the .DLL (at least I do) (break MyDll.DLL.EntryPoint) Bill

2 1

RE: Debugger set breakpoint with full filename
by Medland, Bill 10 Jan '02

10 Jan '02

> -----Original Message----- > From: eric [mailto:eric.pouech@wanadoo.fr] > Sent: Thursday, January 10, 2002 11:45 AM > To: Bill Medland > Cc: wine-devel(a)winehq.com > Subject: Re: Debugger set breakpoint with full filename > > > Bill Medland a écrit : > > > > I've spent time looking for the answer and trying the (to > me) obvious > > options and now I give in. > > > > How, in the debugger, do I specify "Set a break point at DllMain of > > E:\BIN.50A\..MYDLL.DLL" > > without the debugger complaining about syntax etc.? > hmmm debugger isn't ready to handle DLL names which contain '.' Woops. I meant an ellipsis. > > another solution is to ask the debugger to break on each DLL loading. > set $BreakOnDllLoad = 1 > then, you would be able to add a breakpoint on DllMain > (which, I assume > would be exported from the DLL, meaning its symbol will be > known to the > debugger) Unfortunately not. Thanks for the help anyway. Bill

2 1

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