April 2007 - Wine-devel - list.winehq.org

[try2] kernel32: Add partial stub for NeedCurrentDirectoryForExePath
by Kirill K. Smirnov 18 Apr '07

18 Apr '07

>If FILE_name_AtoW fails, the function fails, so the return value should be FALSE, shouldn't it ? TRUE means that current directory '.' should be added to PATH. FALSE is returned if a special environment variable NoDefaultCurrentDirectoryInExePath is set. Of course, default sane value should be TRUE. Details at http://msdn2.microsoft.com/en-us/library/ms684269.aspx. -- Kirill

1 0

Re: [try2] kernel32: Add partial stub for NeedCurrentDirectoryForExePath
by Laurent Vromman 18 Apr '07

18 Apr '07

+/*********************************************************************** + * NeedCurrentDirectoryForExePathA (KERNEL32.@) + */ +BOOL WINAPI NeedCurrentDirectoryForExePathA( LPCSTR name ) +{ + WCHAR *nameW; + + if (!(nameW = FILE_name_AtoW( name, FALSE ))) return TRUE; If FILE_name_AtoW fails, the function fails, so the return value should be FALSE, shouldn't it ? Laurent On Wed, 18 Apr 2007 15:54:42 +0400, "Kirill K. Smirnov" <lich(a)math.spbu.ru> wrote: > Please, ignore my previous attempt. > >

1 0

kernel32: Add partial stub for NeedCurrentDirectoryForExePath
by Kirill K. Smirnov 18 Apr '07

18 Apr '07

>+ if (strchrW(name, '\\')) >+ return TRUE; >What is the point of this? You're returning TRUE no matter what anyway. >+ FIXME("(%s): stub!\n", debugstr_w(name)); >+ return TRUE; ancient patch in attach, sorry.

1 0

Re: kernel32: Add partial stub for NeedCurrentDirectoryForExePath
by James Hawkins 18 Apr '07

18 Apr '07

On 4/18/07, Kirill K. Smirnov <lich(a)math.spbu.ru> wrote: > Add partial stub for NeedCurrentDirectoryForExePath. It is needed by win2003 > cmd.exe > + if (strchrW(name, '\\')) + return TRUE; What is the point of this? You're returning TRUE no matter what anyway. + FIXME("(%s): stub!\n", debugstr_w(name)); + return TRUE; -- James Hawkins

1 0

Re: Bug 5163
by EA Durbin 18 Apr '07

18 Apr '07

It appears to me according to this log section that the bug is actually in kernel32.CompareStringA, though I could be wrong. It starts out comparing the strings of files it is looking for in the cabinet file with kernel32.CompareString and unsuccesfully matching, then it appears to be matching the first couple of letters in the string and then continuing on before it actually finds the file it is looking for. SC2R.SAM is matching scanost.exe EXCHCSP.DLL_0001 is matching exchng.hlp after it finds these false matches the installer continues on without actually matching the string it is looking for >From: "James Hawkins" <truiken(a)gmail.com> >To: "EA Durbin" <ead1234(a)hotmail.com> >Subject: Re: Bug 5163 >This is a pretty crazy bug, and I don't think it's a problem in >msi. The custom action searches through the entire contents of the >cdrom (including all the files in the cabinet) looking >for...something. I don't know what it's looking for though. -- >James Hawkins _________________________________________________________________ Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/

2 1

Question using appdb
by Laurent Vromman 18 Apr '07

18 Apr '07

Hi, When a distribution is absent from the list, we are supposed to add it, as the following message explain : Distribution If yours is not on the list, please add it using the form below The fact is, there is no form below. Is the message wrong or is the form missing ? Note : The distribution I want to add is the new Debian Lenny Laurent Vromman

3 4

Re: Implementation of mathematical functions for D3DRM
by Tom Wickline 17 Apr '07

17 Apr '07

On 4/15/07, David.Adam(a)math.cnrs.fr <David.Adam(a)math.cnrs.fr> wrote: > Here is the complete implementation of the mathematical functions of > D3DRM with tests. > Tests work under Windows XP and wine. > > This work was done in colloboration with Vijay Kamuju. > > Comments are welcome . Can you please resubmit these patches? with only one patch per email Tom > > David ADAM > > > > > -- Tom Wickline Respectable computing - Linux/FOSS

1 0

Re: D3D9: Rework the converted vertex declaration management (try 3)
by Vitaly Budovski 17 Apr '07

17 Apr '07

Stefan � wrote: >> Another patch which grows by 0.5 * existing size >> You could as well just grow it to twice the existing size. It would be easier.

1 0

Old versions of Acrobat Pro tryout?
by Dan Kegel 17 Apr '07

17 Apr '07

Hey Tom, thanks for the help finding old Photoshops. I'm now looking for old Acrobat Pro trials. Best source I've found so far is for the foreign language versions, http://www.winsoft.eu/support/adobe-download.php but I don't speak any of those languages. FIleplanet doesn't seem to have any, and Tucows only points to adobe.com. Can you have a look for Acrobat Pro 7 or earlier trial versions (in english, french, german, or spanish)? Thanks! - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 3

FW: locales, unicode and ansi with msvcrt (bug 8022)
by Ann & Jason Edmeades 17 Apr '07

17 Apr '07

(Meant to copy wine-devel as well, in case anyone else had any comments) Subject: RE: locales, unicode and ansi with msvcrt (bug 8022) >> My current plan, unless you have strong objections, is to make the wprintf >> msvcrt routines use WideCharToMultiByte on the string into the GetACP >> codepage before being written out, and add file tests for this into the >> msvcrt testsuite >You shouldn't really guess, you need to investigate how the things are supposed >to work in Windows. IMO you are going wrong route by looking how msvcrt works >instead of looking how cmd.exe does. Did you try to run native cmd.exe in WIne >and see how it handles cp conversions, or under logger.exe in Windows? Firstly, leave cmd.exe out of the equation. This has nothing to do with it at all. Just to emphasize, I am looking at the part of the bug where xcopy was writing out characters padded with gaps (nulls) which is caused by it simply calling msvcrt's wprintf. I can recreate the problem with a simple, one line console application run through wine (not cmd.exe nor wineconsole): void main() { wprintf(L"test with wprintf"); } [program was compiled VC6 : cl /MD test.c ] wine test >a.a od -x a.a 0000000 0074 0065 0073 0074 0020 0077 0069 0074 0000020 0068 0020 0077 0070 0072 0069 006e 0074 0000040 0066 export WINEDLLOVERRIDES=msvcrt=n wine test >a.a od -x a.a 0000000 6574 7473 7720 7469 2068 7077 6972 746e 0000020 0066 Shows wine internal msvcrt differs from windows msvcrt and incorrectly outputs Unicode >> I'm also guessing relay and snoop cant see internal dll calls, so that might >> explain the lack of calls. Perhaps something like wcstombs would be the key >> to this >Even if internal dll calls are not logged, wcstombs does an external call to do >its job. What makes you say that? It potentially doesn't need to, given the internal caching it does in process_attach, it could do it all in memory. However... WINEDEBUG=+all,+relay,+snoop wine test 2>a.a a.a (removing Set/GetLastError and Tls call) shows: 0009:CALL msvcrt.wprintf(00403010) ret=0040100d 0009:Call ntdll.RtlAllocateHeap(00410000,00000000,00001000) ret=77c2c3c9 0009:trace:heap:RtlAllocateHeap (0x410000,00000002,00001000): returning 0x412168 0009:Ret ntdll.RtlAllocateHeap() retval=00412168 ret=77c2c3c9 0009:Call kernel32.WriteFile(00000008,0033f9c8,00000011,0033f9ac,00000000) ret=77c30218 0009:trace:file:WriteFile 0x8 0x33f9c8 17 0x33f9ac (nil) 0009:trace:ntdll:NtWriteFile (0x8,(nil),(nil),(nil),0x33f8b8,0x33f9c8,0x00000011,(nil),(nil))! 0009: get_handle_fd( handle=0x8, access=00000002, cached=1 ) 0009: get_handle_fd() = 0 { type=1, flags=0 } 0009:Ret kernel32.WriteFile() retval=00000001 ret=77c30218 0009:RET msvcrt.wprintf() retval=00000011 ret=0040100d Note the writefile call - it passed 0x11 bytes (number of bytes in the narrow string) Logger shows no calls from msvcrt during that time, but I don't trust it. Running test program under windbg and trying to follow it through it does appear wctomb is called (it does NOT result in WideCharToMultiByte, possibly due to the characters or locale I am using?) but it does it on a character by character basis (I believe during the formatting). This would be the equivalent on wine to calling pf_vsnprintf with out.unicode set to false. (I don't know why it doesn't come up on snoop - maybe it's a near call (no fixups?). So its back to a necessity to ensure for text streams we only output multibyte (not wide). I can see 2 ways of doing it: 1. Change MSVCRT_vfwprintf and add a conversion widechartomultibyte for a text stream (if (MSVCRT_fdesc[fd].wxflag & WX_TEXT) ...) Advantages: Changes self contained, easy Disadvantages: Formatting into Unicode buffer, then need to allocate space for answer, convert, print, free 2. Change MSVCRT_vfwprintf to use a new internal function which is identical to MSVCRT_vsnwprintf but sets out->Unicode = FALSE and out.buf.A as destination string. Advantages: Fastest way (conversion is WC->MB as the formatting is processed) Disadvantage: Needs new internal function My preference is (2), and I have coded and tested it to confirm it does solve both the file i/o tests (included in patch) and the console output tests (performed by hand) Comments? Jason

3 3