- Wine-Devel - list.winehq.org

Re: The most likely way to get IBM to sponsor WINE development
by dschwarz＠bellatlantic.net Jan. 12, 2002

Jan. 12, 2002

I've been following this discussion with some interest. I am a former Iris/Lotus/IBM employee, and I now run the Winecentric pages www.winecentric.com, basically a faq on how to run Lotus Notes and other programs under WINE. I have had unofficial conversations with Lotus product development managers; they have reacted to customer requests for the Lotus Notes client on Linux by doing their own testing, and they even publish an official page outlining how to run Lotus Notes with WINE. They don't offer customer support (that would cost millions). The best way to get IBM to sponsor WINE development is to persuade them to port their flagship applications to Linux. IBM/Lotus have a long history of using API translators to port products across platforms, including Lotus Notes and SmartSuite. If they were persuaded to port, say, VisualAge for Java and SmartSuite, using Winelib, we'd gain some new applications plus (hopefully) IBM would contribute any Winelib enhancements back. Just my 2 cents... Dan Schwarz help(a)winecentric.com

2 1

Bad File Creation
by Guy L. Albertelli Jan. 11, 2002

Jan. 11, 2002

In attempting to play with Outlook Express 5 under Wine, I find that the files created by OE are bad/damaged. The attachments are as follows: hoho.gif - view under Linux shows Folders.dbx as 75,204 hoho-win.gif - view under Windows shows Folders.dbx as 74K (pretty good). scandisk.gif - error message from scandisk under windows. hoho-win-after.gif - view under Windows shows Folders.dbx as 60K after repair. hoho.txt - selected pieces of the trace from Wine during the creation of Folders.dbx. Revisiting it under Linux shows the size is now 61,440. The Linux is RH 6.1 and the kernel is 2.2.12-20. This is the only file that this problem occurs on (not true, it also occurs on Inbox.dbx in the same folder). No other file that I create under Linux is damaged. I suspect that this may be due to Wine implementation of the call sequence of: GetFileSize(..) SetFilePointer(..) SetEndOfFile(..) Any comments or suggestions? Guy Albertelli <<galberte(a)neo.lrun.com>> Bathed in his currents of liquid helium, self-contained, immobile, vastly well informed by every mechanical sense: Shalmaneser. Every now and again there passes through his circuts a pulse which carries the cybernetic equivalent of the phrase, "Christ, what an imagination I've got. " - Stand on Zanzibar by John Brunner

1 0

Re: How about sponsoring from IBM?
by David.Goodenough＠DGA.co.uk Jan. 11, 2002

Jan. 11, 2002

I would suggest that one of the things that would help would be for IBM development labs which are developing Windows code, such as the Lotus labs, to test their code under WINE as well as Windows, and if it does not work to report any problems they find with APIs to the WINE community, perhaps even with fixes as they can see what WINE is doing with their requests. Without the source code and the understanding of what they expect to happen it is difficult for WINE developers to work out why any app does not work (although the tracing gives many clues). This way WINE users get apps that work and the developers get good feedback. Roland <roland(a)netquant. To: Paul Clarke <pacman(a)us.ibm.com>, wine-devel(a)winehq.com com.br> cc: Sent by: Subject: Re: How about sponsoring from IBM? wine-devel-admin@ winehq.com 01/11/02 05:47 PM At 08:35 AM 1/11/02 -0600, Paul Clarke wrote: >My attempt to convince you otherwise: > >http://oss.software.ibm.com/developer/opensource/linux >http://www.ibm.com/linux > >Paul Clarke, IBM Good, so it really seems that IBM is commited to Linux. Now my question is, would it be too much to ask IBM to spend 1% of that 1 billion for Linux on WINE? Of course we are assuming that a full-featured WINE would DRASTICALLY increase the success of Linux. This would be in accordance with: "...with a shared vision of making Linux succeed." quote from http://www-124.ibm.com/developer/opensource/linux/ If the assumption is true I think those 10 Million would be the best spent part of that 1 Billion. Paul, do you know the people in charge of the Linux sponsoring? How about talking to them about this idea? It would be interesting to hear what they say. Maybe they even don't know about the WINE project... Just my 0.000 000 001$ Roland

2 1

Re: WinSpool Ordinal Addition
by Alexandre Julliard Jan. 11, 2002

Jan. 11, 2002

"Mark G. Adams" <mgadams(a)sympatico.ca> writes: > In Windows 2000 (and I presume later), winspool.drv has some new functions. > The one this application is looking for turns out to be GetDefaultPrinter() > (ASCII version is ordinal 201, Unicode is 203). I've added the ASCII and > Unicode implementations of that function to winspool in the attached patch. > The ASCII version has been tested; I'd appreciate it if you could take a > glance at the Unicode version and see if I got the conversions correct. > > The application will now open the 'printer setup' dialog, instead of > returning an error. Exactly what error did you get before? And are you sure this is really an ordinal import? This seems the kind of things that Win95 does, but not so much Win2000. -- Alexandre Julliard julliard(a)winehq.com

3 6

ADPCM and Wine
by David D. Hagood Jan. 11, 2002

Jan. 11, 2002

Is anybody working on support for playing ADPCM wave files under Wine? If not, I'd like to take a crack at it. 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. ADPCM isn't rocket science - several programs, including sox, understand the protocol. 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.

3 2

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

Jan. 11, 2002

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(a)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 Jan. 11, 2002

Jan. 11, 2002

> 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 Jan. 11, 2002

Jan. 11, 2002

> 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 Jan. 10, 2002

Jan. 10, 2002

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 Jan. 10, 2002

Jan. 10, 2002

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