January 2002 - Wine-Devel - list.winehq.org

Re: WinSpool Ordinal Addition

by Mark G. Adams

On January 11, 2002 12:21 am, Dmitry Timoshkov wrote: > This application will not work either under win9x or win2000 because they > have different functions assigned to ordinal 201: > win95 OSR2 PE and win98 SE: StartDocPrinterA > win2000: GetDefaultPrinterA Interesting. At any rate, I'll pass this info along to see if it can be determined WTF SourceView's trying to do here. > It should be clear even for you, since you have submitted two different > patches with ordinal 201 assigned to absolutely different functions and > presumably both variants have worked for you. Apparently just adding > 100 stub OrdinalBase > should work for you too. The fact that it worked with different functions there did surprise me. My assumption (not having a good idea on how ordinal importing works) was that, at this point, it's just checking for the presence of a function but not executing it. Very little of the application works under WINE, so I'm not able to actually test out printing currently. Given the above, I agree there's no point in assigning ordinals to those two functions. Thanks for the additional info. At a minimum, it's highlighted a possible printing problem we'll have to look in to. //Mark

Jan. 11, 2002

Re: WinSpool Ordinal Addition

by Dmitry Timoshkov

"Mark G. Adams" <mgadams(a)sympatico.ca> wrote: > Here's the message output on startup if those functions are not exported at > the expected ordinals: > > err:win32:PE_fixup_imports No implementation for WINSPOOL.DRV.201 imported > from C:\OmniMark\EnterpriseStudio6_1_1\OmniMark-Enterprise-Studio.exe, > setting to 0xdeadbeef > > Unless i'm mistaken, that's an ordinal import. This application will not work either under win9x or win2000 because they have different functions assigned to ordinal 201: win95 OSR2 PE and win98 SE: StartDocPrinterA win2000: GetDefaultPrinterA It should be clear even for you, since you have submitted two different patches with ordinal 201 assigned to absolutely different functions and presumably both variants have worked for you. Apparently just adding 100 stub OrdinalBase should work for you too. Probably the right fix would be to add new parameter to the wine .spec files: "ordinal base", because for WINSPOOL.DRV it's equal to 100 in all variants of that DLL for me. -- Dmitry.

Jan. 11, 2002

Re: async_private + ReadFile() etc. immediate completion

by Mike McCormack

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

Jan. 11, 2002

Re: WinSpool Ordinal Addition

by Mark G. Adams

On January 7, 2002 01:39 pm, Alexandre Julliard wrote: > "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. Here's the message output on startup if those functions are not exported at the expected ordinals: err:win32:PE_fixup_imports No implementation for WINSPOOL.DRV.201 imported from C:\OmniMark\EnterpriseStudio6_1_1\OmniMark-Enterprise-Studio.exe, setting to 0xdeadbeef Unless i'm mistaken, that's an ordinal import. Now it turns out that that function's presence doesn't appear to be essential; printer setup wasn't working in the first place as I didn't have wine printing properly configured. However, the SourceView ActiveX control, which OmniMark uses for editing and printing, must be checking for its presence and presumably making use of it for something if it exists. I guess the patch could be dealt with in two chunks: 1) everything except ordinals. This just adds new functionality which is present in W2K (and WinXP presumably) and doesn't break anything. 2) the specific ordinals for those functions. While I agree that this is a pretty poor way to test for a function's presence, I don't see what harm there would be in assigning the expected ordinals to those functions, and there is at least one application which makes use of that. The only possibility for concern would be if it turned out that WinXP has different ordinals for them; I'm afraid I don't have access to a WinXP machine to test that. //Mark

Jan. 11, 2002

Re: async_private + ReadFile() etc. immediate completion

by lawson_whitney＠juno.com

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---

Jan. 11, 2002

Re: Handle quotes in command lines

by Francois Gouget

On Thu, 10 Jan 2002, Uwe Bonnes wrote: > >>>>> "Francois" == Francois Gouget <fgouget(a)free.fr> writes: [...] > Show me what lpCmdLine your test program passes to CreateProsess. The lpCmdline parameter is exactly as it was printed in my email. This is why createp uses 'gets' to retrieve it: main a\"b "c\"d\\" e That's if I run it as Winelib applications but if you run it in Windows you will see: H:\tests\cmdline\Debug>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] Which you will notice is identical. > Are you > sure createp code doesn't misshandle things. Trying with my commandline > test program, it looks right: > : > wine -- cmdline.exe a\"b "c\"d\\" e > : fixme:win32:PE_CreateModule Security directory ignored > : "a"b c"d\ e" > The first and last quotes are added by my program. If I run wine -- cmdline.exe a\"b "c\"d\\" e then it works. That's because in that case Wine knows the exact command line and does not call BUILD_CommandLine. But now, modify your caller.c program to pass the above arguments (or use my createp program) and your will get: ""a\b "c\d\\"" e" In that case Wine: * added extra quotes. This is not wrong, but it is no better than always removing extraneous quotes either * it also misinterpreted the \" between a and b. This is a bug. The difference between 'wine --' and CreateProcess is that in the latter case Wine has to rebuild the command line from the argv array. > E.g. tcsh chokes on your argument arangement (but tcsh isn't _the_ > reference:-): Strange. But I don't use C shells... Bash likes it just fine. [...] > Run a.exe of the tests appended and see the > difference. Run against the DOS Shell in WinXX(/Vmware) to see what should > happen. What your test program shows is that we currently loose extraneous quotes. It is impossible to guess what the original command line is from an argv array: argv[1]=ab can come from any of the following command lines (using [] to delimit the command line): [ab] [ab ] trailing spaces can be significant ["ab"] [""ab] [""ab] [ab""] [ab"" ] [a"b] (in the above the " is not closed but it does not matter here) There are many more possibilities as soon as you have more than one argument (one or more spaces between args, quotes for one, the other or both, etc.). But I guess you get the idea. I really don't think that systematically adding quotes around arguments is going to help. In fact I suspect that many applications would not handle them correctly. The only reasonable I see to improve on the current code is to pass the command line as it was specified to CreateProcess, directly to the child. There two ways to do so: via an environment variable, or via the wineserver. Using an environment variable is not very clean, especially since either the parent or the child may not be Wine applications. To make matters even more complex the child may not be a Wine process but the grand-child may be one and then it should not use the command line that was intended for its parent. Passing the command line via the wineserver code seems like the best approach. Note, you should be able to find createp and my other tests program in the wine-dev or wine-patches archives. I cannot give you the exact URL because my internet connection is down but the following should help you find it: Date: Sun, 2 Sep 2001 19:37:43 -0700 (PDT) From: Francois Gouget <fgouget(a)free.fr> To: wine-devel(a)winehq.com Subject: ' ' & '"' handling in the command line -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

Jan. 11, 2002

Re: Changes regarding wnaspi32 layer ?

by David Elliott

On 2002.01.10 14:06 Martin Hoffmann wrote: > 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 > Speaking of which, I highly recommend you use CVS and configure with --prefix=/opt/wine-cvs (or something similar). Then add YOUR_PREFIX/bin to your path and YOUR_PREFIX/lib to your /etc/ld.so.conf. Then if you ever need to be sure you have a fresh copy of wine: rm -rf /opt/wine-cvs make install Thanks to Jeremy for this suggestion (in fact, I think the CodeWeavers RPMs do this, or at least did IIRC). It's a hell of a lot better than having wine strewn over /usr/local along with the rest of your programs compiled from source. Glad to hear that you got ASPI working. Especially because I could see no reasonable explanation for why it wouldn't work between the wine releases you gave given that no major updates have been made to ASPI since Andreas Mohr fixed some bugs with the /proc/scsi/scsi parsing in my code among other things. Hehe.. actually, had people not had broken SCSI devices with a space as their first character this would not have been an issue. -Dave

Jan. 11, 2002

Re: Lindows screenshots AND THE WINE LICENSE

by David Elliott

On 2002.01.10 12:25 Roland wrote: [snip] > But there are more dangers for the WINE license. It would be possible > for a company like Lindows hire away all WINE developers, effectively > hijacking the project. Alternatively if Lindows becomes a success it > will be able to hire more programmers and keep improving their own > version of WINE, so that it would always be much better than the free > WINE. I wonder why this didn't happen to FreeBSD. > First of all, licensing has been discussed to death and will remain as MIT for the forseable future. Although I note you are not arguing this.. just throwing this out. Personally I would not want to work for a company that took free software, fixed or hacked around some major bugs, and sold it for $100 a copy. While I couldn't speak for the other Wine developers I feel that many of them would not be willing to do this. Look at CodeWeavers and TransGaming. CW sells the service of porting an application from Windows to winelib. For their business to function properly they need a Wine which works well. It is true that since they contribute most of their modifications back (with some very minor exceptions) someone /could/ compete with them. However, if you were a company who was going to contract out the porting of your windows application, who would you trust? Some newcomer to the field with no reputation or a company who employs top Wine developers? And in the event that someone does enter the market successfully... well, more power to them. Jeremy has stated several times that contributing CW modifications back to Wine is actually in his best business interest as it means he does not have to deal with a totally overmodified tree and instead reaps all of the benefits of free software including people who build on his work and contribute that to the Wine project. According to Jeremey, moving to a GPL license could potentially help CodeWeavers (see previous mails in the list archives). TransGaming sells the service of enhancing Wine to run popular games. Contributing all of their modifications back to Wine would mean no one would want to buy their product when they can get Wine for free. Contrast this with CW who have already been paid for the work (or at least have a contract to be paid). However, TransGaming does still release their source under a non-free license which at least gives the user some freedom. For TG, moving to the GPL would be very disastrous to their business model, well, there was some debate on how disastrous it would be, but it would harm them in some ways. Now look at Lindows. Basically they want to take the work that many people have spent a lot of time creating and essentially steal it for their own benefit. I am gonna laugh though when Wine is actually good enough that their modifications have no value over Wine. Plus, it's not exactly as if Lindows is a new idea. MANY people have proposed this exact same idea (including myself I think). Let's look at what exactly Lindows has done: 1. They added the Windows programs menu into the KDE menu. Big deal, trivial. 2. They made KDE look as much like Windows as possible. Again... big deal. 3. They fixed some bugs with Wine. Or at least hacked around them (more likely) to make popular applications work. Trust me.. getting MS Office 2000 working is no big shit. Neither is IE. Both of these programs almost work with a few crashes and a few native DLLs. Assuming they are using wine dlls then one thing I assume they did was fix the common controls stuff to look right. This part is not trivial, but not unreachable either. Is $100 really worth it? I thought that was a joke when I saw it. They've been developing this for what.. a few months, half a year maybe? It still crashes, and I'll bet if this goes on the market and office crashes a lot of people are going to bitch about the stability of Linux, when really it's because they are using alpha software (Wine). Sorry about the rant, just had a few things I wanted to say. -Dave

Jan. 11, 2002

Re: Handle quotes in command lines

by Uwe Bonnes

>>>>> "Francois" == Francois Gouget <fgouget(a)free.fr> writes: Francois> 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. Francois> No. Your patch mishandles quotes. Francois> Normal behavior: $ ./createp Type the command to execute: main Francois> a\"b "c\"d\\" e CreateProcess returned: 1 error=0 Francois> GetCommandLine=[main a\"b c\"d\ e] main -> argc=4 0 [main] 1 Francois> [a"b] 2 [c"d\] 3 [e] Show me what lpCmdLine your test program passes to CreateProsess. Are you sure createp code doesn't misshandle things. Trying with my commandline test program, it looks right: : > wine -- cmdline.exe a\"b "c\"d\\" e : fixme:win32:PE_CreateModule Security directory ignored : "a"b c"d\ e" The first and last quotes are added by my program. E.g. tcsh chokes on your argument arangement (but tcsh isn't _the_ reference:-): : > wine -- cmdline.exe a\"b "c\"d\\" e : Überflüssiges ". "Überflüssiges" == Surplus Francois> With your patch: main a\"b "c\"d\\" e CreateProcess returned: Francois> 1 error=0 GetCommandLine=[main "a\b "c\d\\"" e] main -> argc=3 Francois> 0 [main] 1 [a\b "c\d\"] 2 [e] main -> __argc=3 0 [main] 1 [a\b Francois> "c\d\"] 2 [e] Francois> With your patch we: * change the command line from what was Francois> specified, just as before * add quotes where there are none * Francois> misinterpret quotes * don't split arguments properly anymore Francois> The existing quote handling is perfect! Run a.exe of the tests appended and see the difference. Run against the DOS Shell in WinXX(/Vmware) to see what should happen. Francois> I tested and Francois> retested it. The problem you are having is that we cannot Francois> garantee that the child process will get the exact same Francois> commandline because of the cmdline -> argv -> cmdline Francois> conversion. The fix for your problem is to pass the command Francois> line to the child process via a wineserver call or something. Francois> Guess which is the first test I am going to write with the Francois> new testing framework!!! (and I would much prefer to print Francois> the contents of argv to file than to try and hard-code all the Francois> checks in the child, plus how am I going to know which was the Francois> command line that was given to me anyway! Contend of my tests: caller.c: Programm that calls cmdline via CreateProcess cmdline.c: Print the arguments ucmdline.c: prints the arguments( Unix-File) -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 10, 2002

Re: How about sponsoring from IBM?

by Ian Pilcher

Francois Gouget wrote: > > Yeah, sure! > SMOP! > (a small matter of programming) > Let's write a pentium emulator with just in time compilation over the > week-end. > http://bochs.sourceforge.net -- ======================================================================== Ian Pilcher pilchman(a)attbi.com ========================================================================

Jan. 10, 2002

Re: Debugger set breakpoint with full filename

by Eric Pouech

> p.s. you DO need the .DLL (at least I do) > > (break MyDll.DLL.EntryPoint) yes for this one, you need the .DLL in the name (yes, I know, the naming of symbols is not consistent in the debugger...) but, almost no one noticed (until now ;-) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Jan. 10, 2002

RE: Debugger set breakpoint with full filename

by Medland, Bill

> -----Original Message----- > From: eric [mailto:eric.pouech(a)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

Jan. 10, 2002

Re: Debugger set breakpoint with full filename

by eric

> Unfortunately not. it should (under the name EntryPoint) try MyDLL.EntryPoint, it should work A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Jan. 10, 2002

Re: Babystep: Testing framework

by Andriy Palamarchuk

--- Francois Gouget <fgouget(a)free.fr> wrote: > > 2) using TODO tests. The problem becomes even > worse if > > more than one Win32 implementation project (e.g. > ODIN) > > starts to use the test, because list of TODOs is > > project-specific > > .ref.diff files. If the diff between the .out and > the relevant .ref > file matches that diff file, then all is good. like: .win95.wine .nt4.wine .win95.odin .nt4.odin ? > > Now, imagin combinations of these :-) > > WONTFIX will not be very practical. But are they > really needed? I > would say that TODOs should be enough. WONTFIX is not TODO, it is DONE :-) I don't want to use TODO for this, because it will show up as unfinished work. > > Explicit check, on other hand, nicely comments all > > these conditions in one place - in code. > > Except that in some cases they will make the > checks pretty complex. Arguable. IMO to retrieve the same information from diffs - you need to visit: test1.c test1.win95 test1.win98 test1.nt4 test1.w2k test1.wine test1.win95.wine - TODOs test1.win98.wine - TODOs test1.nt4.wine - TODOs test1.w2k.wine - TODOs In many of these files you need to filter hundreds of lines of code to correspond the check and its output. This holds true even for checks which work in the same way on different Windows platforms, have no TODO and WONTFIX attributes, e.g. for 99.9% checks. How much lines the explicit check with all these attributes will take? 2 additional lines in the worst case, nothing - in 99.9% of cases. Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/

Jan. 10, 2002

RE: Debugger set breakpoint with full filename

by Medland, Bill

> -----Original Message----- > From: eric [mailto:eric.pouech(a)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

Jan. 10, 2002

Re: Babystep: Testing framework

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > .ref.diff files. If the diff between the .out and the relevant .ref > file matches that diff file, then all is good. So for a test that has both version differences and TODO tests (quite frequent IMO), you need: .ref .ref.diff .win95 .win95.diff .win98 .win98.diff etc... That's clearly not practical, especially since you need to update all these files everytime you change something to the test. -- Alexandre Julliard julliard(a)winehq.com

Jan. 10, 2002

Re: Debugger set breakpoint with full filename

by eric

> break MYDLL.DLL.foo you can eventually omit the .DLL too (except for DLL which don't have the DLL extension, like drv, acm...) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Jan. 10, 2002

Re: Handle quotes in command lines

by Ove Kaaven

On Thu, 10 Jan 2002, Francois Gouget wrote: > 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. Hmm. If so, here's some stuff from the WineX tree (because SafeDisc needs the quotes to be preserved in the child process's command line), at least what's left of it after the last WineHQ merge. If it still works, is it better than Uwe's patch? Gavriel State <gav(a)transgaming.com> Preserve exact command line - including quotes - used when creating a process. Certain copy-protection software expects this... diff -u wine/scheduler/process.c:1.1.1.23 wine/scheduler/process.c:1.11 --- wine/scheduler/process.c:1.1.1.23 Mon Dec 31 02:52:36 2001 +++ wine/scheduler/process.c Mon Dec 31 08:07:18 2001 @@ -476,14 +476,34 @@ if (!main_exe_name[0]) { + char *argv_noquotes; + DWORD argv_len; + if (!app_argv[0]) OPTIONS_Usage(); - /* open the exe file */ - if (!SearchPathA( NULL, app_argv[0], ".exe", sizeof(main_exe_name), main_exe_name, NULL) && - !SearchPathA( NULL, app_argv[0], NULL, sizeof(main_exe_name), main_exe_name, NULL)) + /* Remove any quotes around the file name, without modifying argv[0] */ + argv_len = strlen(app_argv[0]); + if ((argv_noquotes = HeapAlloc( GetProcessHeap(), 0, argv_len+1 ))) { - MESSAGE( "%s: cannot find '%s'\n", argv0, app_argv[0] ); - goto error; + char *p = app_argv[0]; + char *q; + /* If there are quotes around the *full* argument only, remove them */ + if ((*p == '\"') && (q = strchr( p + 1, '\"' )) && (q == (p+argv_len-1))) + { + strncpy(argv_noquotes, p+1, argv_len-2); + argv_noquotes[argv_len-2] = 0; + } + else + strcpy(argv_noquotes, p); + + /* open the exe file */ + if (!SearchPathA( NULL, argv_noquotes, ".exe", sizeof(main_exe_name), main_exe_name, NULL ) && + !SearchPathA( NULL, argv_noquotes, NULL, sizeof(main_exe_name), main_exe_name, NULL )) + { + MESSAGE( "%s: cannot find '%s'\n", argv0, argv[0] ); + goto error; + } + HeapFree( GetProcessHeap(), 0, argv_noquotes); } }

Jan. 10, 2002

Re: Debugger set breakpoint with full filename

by eric

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 '.' 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) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Jan. 10, 2002

Re: How about sponsoring from IBM?

by Roland

Just to add a fact to my statements: http://news.cnet.com/news/0-1003-201-4656230-0.html quote:" IBM CEO Lou Gerstner announced IBM's $1 billion Linux commitment last month." (this was january 2001)

Jan. 10, 2002

Re: Debugger set breakpoint with full filename

by Bill Medland

"Bill Medland" <medbi01_1(a)accpac.com> wrote in message news:7f1b.3c3dbd2f.43c63(a)wine2.winehq.com... > 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.? > > If someone answers then I am prepared to add the info to debugger.sgml > > Bill OK. To break at function foo of dll E:\somepath\MyDll.DLL break MYDLL.DLL.foo I'll update the file. NOW the real question. I am chasing a bug which makes no sense. I want to single-step through the DLL's DllMain but since it isn't exported the debugger can't get its address (I presume) so I can't set it as a break point. Is there a way to figure out what it's address is? Bill

Jan. 10, 2002

Re: Changes regarding wnaspi32 layer ?

by ma.hoff＠t-online.de

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

Jan. 10, 2002

Re: Babystep: Testing framework

by Francois Gouget

On Thu, 10 Jan 2002, Andriy Palamarchuk wrote: > > --- Jeremy White <jwhite(a)codeweavers.com> wrote: > > However, having the diff feature allows us to more > > rapdily adapt existing programs to become tests. > > Since it's done (and it's trivial code), I don't see > > the harm in leaving in the feature. We can hide > > it/discourage in in the (as yet unwritten) doco if > you like. > > Some disadvantages of the diff approach was discussed > before. I just realized the problem which will make > using this approach practically impossible. The > problem - variations of output as result of: > 1) using different Windows versions. .ref -> deneric reference .win95 -> win95 reference .win98 -> win98 reference etc. Okay, if the difference is between nt and win 95/98/me then it may get a bit hairy. > 2) using TODO tests. The problem becomes even worse if > more than one Win32 implementation project (e.g. ODIN) > starts to use the test, because list of TODOs is > project-specific .ref.diff files. If the diff between the .out and the relevant .ref file matches that diff file, then all is good. [...] > Now, imagin combinations of these :-) WONTFIX will not be very practical. But are they really needed? I would say that TODOs should be enough. > Explicit check, on other hand, nicely comments all > these conditions in one place - in code. Except that in some cases they will make the checks pretty complex. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In theory, theory and practice are the same, but in practice they're different.

Jan. 10, 2002

Re: How about sponsoring from IBM?

by Francois Gouget

On Thu, 10 Jan 2002, Roland wrote: [...] > 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?). Yeah, sure! SMOP! (a small matter of programming) Let's write a pentium emulator with just in time compilation over the week-end. (sorry, the way you present things I just couldn't resist) -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.

Jan. 10, 2002

Re: Handle quotes in command lines

by Francois Gouget

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?

Jan. 10, 2002