December 2005 - Wine-Devel - list.winehq.org

Supporting ISVs (was: Create new mailing list wine-isv?)
by Dan Kegel Dec. 17, 2005

Dec. 17, 2005

Markus Goemmel wrote: > My partner and I are developing Windows applications > (http://www.emtec.com) Seeing Wine some months ago fascinated > me a lot, so since then I'm spending one or two hours a day > trying to bring our applications to work under Wine, too... > > But it's clear that there are not enough ressources there > to help ISVs like me out of some problems. Sometimes I have > contact with one of the developers after submitting a bug, > or writing something into the wine-devel list, but without > doing a lot of clarification before (like looking into the > Wine sources, close in the problem area, and asking really > specific questions to the corresponding 5 or 10 lines of code > in the Wine sources) nobody really have time to help. Hmm. Guess you're working on zoc: http://appdb.winehq.org/appview.php?versionId=3744 And you've filed ten bugs so far: http://bugs.winehq.org/buglist.cgi?emailreporter2=1&emailtype2=substring&em… only one or two of which have been fixed. I was curious, so I tried running zoc on wine-0.9.3 (compiled myself on FC3). The first time I started it, it exited with an assertion; the log is --- EmTec Application --- 12/17/2005 6:40:02 AM --- Condition: hwndLed Location : status.cpp line 878 Last Err.: 0L () Add. Info: Every time I started it after that, it exits with a dialog "Panic: no fonts!". I'd like to see this work; got any tips? I'm glad you're sticking around even though it's hard to get your questions answered! Hopefully we can improve the ISV experience with your feedback. Are you interested in being interviewed as a case study for my ISV page, http://kegel.com/wine/isv ? Thanks, Dan

1 0

Error at end of app install: can't open builtin library for regsvr32.exe...
by Dan Kegel Dec. 17, 2005

Dec. 17, 2005

Hrm. Haven't seen this one before. At the end of installation of IBM Homepage Builder 6.0 for Windows, I get wine: cannot open builtin library for L"C:\\windows\\system32\\regsvr32.exe": /home/dank/wine/programs/regsvr32.exe.so: invalid ELF header This is with 0.9.3 built on fc3. Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 7

Partial success report: Ability Office 4.14
by Dan Kegel Dec. 16, 2005

Dec. 16, 2005

Ability Office has a Linux version done with winelib, but I wanted to go whole hog and run the Windows version using wine 0.9.3. There were a few issues along the way. I started by downloading their normal Windows setup program: wget http://www.ability.com/download4/ability4_14/setup.exe wine setup.exe This failed with fixme:urlmon:URLDownloadToCacheFileW ((nil) L"http://www.abilitydownload.com/download4/ability4_14/Ability.MSI" 0x7bc80a88 520 0 0x7b91fb00) Evidently setup.exe is just a little thing that downloads the real thing from their web site, but that doesn't work in Wine yet. So I followed their alternate download procedure: wget http://www.abilitydownload.com/download4/zip/ability4_14.zip unzip ability4_14.zip wine Ability.MSI This failed because Wine doesn't know enough to run msiexec when you do this :-( But running msiexec by hand works: msiexec Ability.MSI I could then run ability write and create documents. Visually, things looked pretty good. Performance-wise, though, it really couldn't keep up with my typing, and took waaaay too long to start up. This is on a 2GHz system with lots of RAM, so it's kind of inexcusable. Gotta go be a dad now, but thought this little bit of data would be interesting to somebody. -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: ScrollDC should not clip output if a clipping rect is not specified
by Rein Klazes Dec. 16, 2005

Dec. 16, 2005

On Fri, 16 Dec 2005 22:17:29 +0800, you wrote: >Hello, > >here is hopefully a correct version of the patch. > >Changelog: > Rein Klazes <wijn(a)wanadoo.nl> > Add another set of ScrollDC tests. > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Add a ScrollDC test with NULL clipping rect. > ScrollDC should not clip output if a clipping rect is not specified. > >diff -up cvs/hq/wine/dlls/user/tests/win.c wine/dlls/user/tests/win.c >--- cvs/hq/wine/dlls/user/tests/win.c 2005-11-30 23:19:27.000000000 +0800 >+++ wine/dlls/user/tests/win.c 2005-12-16 21:51:28.000000000 +0800 Dmitry, I do not understand: these tests pass here without your two patches. Also visually I do not see the failure that you are supposedly fixing. Rein.

1 1

msi failure
by Bill Medland Dec. 16, 2005

Dec. 16, 2005

Seeing as how I know nothing much about msi I thought I'd just point out the error and ask someone more knowledgeable to do something about it. Basically on msiexec a VBA6.msi: dialog.c - msi_dialog_oncreate includes dialog->default_font = msi_dup_property (.., "DefaultUIFont"); Later on that default font can be referenced without testing if it is non-null In my particular case it is null (because the property is not found). Presumably if msi_dup_property returns null then some other default should be used, e.g. MS Shell Dlg. Any comments? Anyone volunteering to fix it? -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

1 0

Re: SHFileOperationW split
by Joris Huizer Dec. 16, 2005

Dec. 16, 2005

Sorry, just got a message of someone (James Hawkins) telling me he's working on the function and it's best not modified before his patches get applied :-) After that, we''ll see whether any of this still finds a need :-)

1 0

Re: msvcrt: Printf Integer Conversions
by Alexandre Julliard Dec. 16, 2005

Dec. 16, 2005

Jesse Allen <the3dfxdude(a)gmail.com> writes: > Changes: > Add support for I64 integer sizes in printf. Handle I and I32 sizes > using libc's printf. The tests fail: printf.c:45: Test succeeded inside todo block: Problem with long long printf.c:46: Test succeeded inside todo block: return count wrong printf.c:51: Test failed: I0d failed printf.c:63: Test failed: I64D failed: %D printf.c:106: Test failed: #+25.22I64u conversion for -1 failed: got ' 0018446744073709551615', should be ' 18446744073709551615' -- obscure windows msvcrt bug? printf.c:114: Test failed: Problem with "ll" interpretation printf.c:115: Test failed: return count wrong printf.c:369: Test succeeded inside todo block: Problem with long long -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: SHFileOperationW 1 : helper functions
by Mike McCormack Dec. 16, 2005

Dec. 16, 2005

Joris Huizer wrote: > When this patch is accepted I'll submit the rest (that is, the code > using these functions) I appreciate somebody is spending the time to clean up that function. Unfortunately, a patch adding functions that aren't yet used is not likely to be accepted. Secondly, even if your style is the only true one, please copy the existing style in that file so we don't end up with another mish-mash mess of coding styles. (And sorry, but 2 space indent is not the one true style ;) Mike > +static int shfileops_delete_file(WIN32_FIND_DATAW *wfd,int confirm,LPWSTR pFromFile,LPWSTR pTempFrom) > +{ > + int retCode = 0; > + LPWSTR lpFileName; > + lpFileName = wfd->cAlternateFileName; > + if (!lpFileName[0]) > + lpFileName = wfd->cFileName; >

1 0

SHFileOperationW 1 : helper functions
by Joris Huizer Dec. 16, 2005

Dec. 16, 2005

This patch adds a simple structure to contain commonly-requested file properties (named `struct fileops_file_data`, wondering whether that name should that change?) Functions added: -void printFileData(): debugging function, printing contents of a `struct fileops_file_data` thing; -int shfileops_delete_file() function to delete given file -- making sure to call the right functions for either a regular file or a directory -int shfileop_unmasked_setup() the extracted code common for move and copy calls -int shfileop_move_unmasked the specific code on moving unmasked -- this one does a lot of recursion on SHFileOperationW -int shfileop_copy_unmasked the specific code on copying unmasked -- this one does some recursion too Further more, I seperated code of deleting, renaming, moving, and copying, and the overall result is that code becomes simpler - though a small amount of code is duplicated (mostly in move/copy operations, that's why I split the largest part of common code in a separate function) When this patch is accepted I'll submit the rest (that is, the code using these functions) Index: shlfileop.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shlfileop.c,v retrieving revision 1.56 diff -u -p -r1.56 shlfileop.c --- shlfileop.c 10 Nov 2005 11:15:22 -0000 1.56 +++ shlfileop.c 16 Dec 2005 15:21:05 -0000 @@ -866,9 +866,69 @@ static const char * debug_shfileops_acti return wine_dbg_sprintf("%s", cFO_Name[ op ]); } +struct fileops_file_data +{ + LPCWSTR next; + LPCWSTR name; + LPWSTR temp; + LPWSTR file; + DWORD attr; + DWORD pathAttr; + BOOL multi; + BOOL invalidTail; + BOOL valid; + BOOL tailSlash; +}; + +void printFileData(struct fileops_file_data *field) +{ + + TRACE("data on %p:\n" + "next: %s\n" + "name: %s\n" + "temp: %s\n" + "file: %s\n" + "attr: %lx\n" + "pathAttr: %lx\n" + "multi: %d\n" + "invalidTail: %d\n" + "valid: %d\n" + "tailSlash: %d\n", + field, + debugstr_w(field->next), + debugstr_w(field->name), + debugstr_w(field->temp), + debugstr_w(field->file), + field->attr, + field->pathAttr, + field->multi, + field->invalidTail, + field->valid, + field->tailSlash + ); +} + #define ERROR_SHELL_INTERNAL_FILE_NOT_FOUND 1026 #define HIGH_ADR (LPWSTR)0xffffffff +static int shfileops_delete_file(WIN32_FIND_DATAW *wfd,int confirm,LPWSTR pFromFile,LPWSTR pTempFrom) +{ + int retCode = 0; + LPWSTR lpFileName; + lpFileName = wfd->cAlternateFileName; + if (!lpFileName[0]) + lpFileName = wfd->cFileName; + SHFileStrCpyCatW(&pFromFile[1], lpFileName, NULL); + if (IsAttribFile(wfd->dwFileAttributes)) + { + if(SHNotifyDeleteFileW(pTempFrom) != ERROR_SUCCESS) + retCode = 0x78; /* value unknown */ + } + else if(!SHELL_DeleteDirectoryW(pTempFrom,confirm)) + retCode = 0x79; /* value unknown */ + return retCode; +} + /* handle the complete deletion of `pTempFrom` */ static int shfileops_delete(WIN32_FIND_DATAW *wfd,SHFILEOPSTRUCTW nFileOp, LPWSTR pFromFile,LPWSTR pTempFrom,HANDLE *hFind) @@ -884,20 +944,12 @@ static int shfileops_delete(WIN32_FIND_D if (IsDotDir(lpFileName) || ((b_Mask) && IsAttribDir(wfd->dwFileAttributes) && (nFileOp.fFlags & FOF_FILESONLY))) continue; - SHFileStrCpyCatW(&pFromFile[1], lpFileName, NULL); - /* TODO: Check the SHELL_DeleteFileOrDirectoryW() function in shell32.dll */ - if (IsAttribFile(wfd->dwFileAttributes)) - { - if(SHNotifyDeleteFileW(pTempFrom) != ERROR_SUCCESS) - { - nFileOp.fAnyOperationsAborted = TRUE; - retCode = 0x78; /* value unknown */ - } - } - else if(!SHELL_DeleteDirectoryW(pTempFrom, (!(nFileOp.fFlags & FOF_NOCONFIRMATION)))) + + retCode = shfileops_delete_file(wfd,(nFileOp.fFlags & FOF_NOCONFIRMATION) == 0,pFromFile,pTempFrom); + if (retCode) { - nFileOp.fAnyOperationsAborted = TRUE; - retCode = 0x79; /* value unknown */ + nFileOp.fAnyOperationsAborted = TRUE; + break; } } while (!nFileOp.fAnyOperationsAborted && FindNextFileW(*hFind,wfd)); @@ -1001,6 +1053,210 @@ static DWORD shfileops_get_parent_attr(L return PathAttr; } +static int shfileop_unmasked_setup(WIN32_FIND_DATAW wfd, struct fileops_file_data *to,struct fileops_file_data *from,BOOL b_Multi,long FuncSwitch) +{ + int retCode = 0; + + TRACE("b_Multi: %d\n",b_Multi); + TRACE("to:\n"); + printFileData(to); + TRACE("from:\n"); + printFileData(from); + + if (IsAttribDir(wfd.dwFileAttributes) && (to->attr == INVALID_FILE_ATTRIBUTES)) + { + if (to->file) + { + to->pathAttr = shfileops_get_parent_attr2(to->file,to->temp,to->valid,&retCode); + if (retCode) + return retCode; + if (to->invalidTail) + { + retCode = 0x10003; + return retCode; + } + } + } + + /* trailing BackSlash is ever removed and to->file points to BackSlash before */ + if (!to->multi && (from->multi || (!(b_Multi) && IsAttribDir(to->attr)))) + { + if ((FO_MOVE == FuncSwitch) && IsAttribDir(to->attr) && IsAttribDir(wfd.dwFileAttributes)) + { + if (b_Multi) + { + retCode = 0x73; /* !b_Multi = 0x8 ?? */ + return retCode; + } + } + to->file = SHFileStrCpyCatW(to->temp, NULL, wfd.cFileName); + to->attr = GetFileAttributesW(to->temp); + } + + if (IsAttribDir(to->attr)) + { + if (IsAttribFile(wfd.dwFileAttributes)) + { + retCode = (FO_COPY == FuncSwitch) ? 0x75 : 0xb7; + return retCode; + } + } + else + { + to->pathAttr = shfileops_get_parent_attr(to->file,to->temp); + if (IsAttribFile(to->pathAttr)) + { + /* error, is this tested ? */ + retCode = 0x777402; + return retCode; + } + } + + /* singlesource + no mask */ + if (INVALID_FILE_ATTRIBUTES == (to->attr & to->pathAttr)) + { + /* Target-dir does not exist, and cannot be created */ + retCode=0x75; + return retCode; + } + + return retCode; +} + +static int shfileop_move_unmasked( SHFILEOPSTRUCTW nFileOp,WIN32_FIND_DATAW wfd, struct fileops_file_data to, struct fileops_file_data from) +{ + int retCode = 0; + int level = nFileOp.wFunc >> 4; + + BOOL b_SameRoot = (toupperW(from.temp[0]) == toupperW(to.temp[0])); + + to.file = NULL; + if ((to.attr == INVALID_FILE_ATTRIBUTES) && SHFileStrICmpW(from.temp, to.temp, from.file, NULL)) + { + nFileOp.wFunc = ((level+1)<<4) + FO_RENAME; + } + else + { + if (b_SameRoot && IsAttribDir(to.attr) && IsAttribDir(wfd.dwFileAttributes)) + { + /* FIXME: moving directory contents into the other one: + * - path\\ -> path\\* + * MOVE + * - loop over files in path\\*, eg path\\file + * MOVE + * - COPY, DELETE + * + * is this really necessary? why not a dedicated recursive + * (light-weight) function? + */ + /* we need to.file for FO_DELETE after FO_MOVE contence */ + to.file = SHFileStrCpyCatW(from.temp, NULL, wWildcardFile); + } + else + { + nFileOp.wFunc = ((level+1)<<4) + FO_COPY; + } + } + + switch(nFileOp.wFunc & FO_MASK) + { + case FO_MOVE: + retCode = SHFileOperationW(&nFileOp); + break; + case FO_RENAME: + /* + retCode = SHFileOperationW(&nFileOp); + */ + if (SHNotifyMoveFileW(from.temp, to.temp) != ERROR_SUCCESS) + { + /* we need still the value for the returncode, we use the mostly assumed */ + retCode = 0xb7; + nFileOp.fAnyOperationsAborted = TRUE; + } + break; + case FO_COPY: + retCode = SHFileOperationW(&nFileOp); + break; + default: + retCode = SHFileOperationW(&nFileOp); + break; + } + + if (to.file) + ((DWORD*)to.file)[0] = '\0'; + if (!nFileOp.fAnyOperationsAborted && (FO_RENAME != (nFileOp.wFunc & 0xf))) + { + /* + TRACE("preparing for delete\n"); + nFileOp.wFunc = ((level+1)<<4) + FO_DELETE; + TRACE("delete: going to execute: %s: flags (0x%04x) : %s\n", + debug_shfileops_action(nFileOp.wFunc & FO_MASK), nFileOp.fFlags, + debug_shfileops_flags(nFileOp.fFlags) ); + + retCode = SHFileOperationW(&nFileOp); + TRACE("returned: %d\n",retCode); + */ + retCode = shfileops_delete_file(&wfd,(nFileOp.fFlags & FOF_NOCONFIRMATION) == 0,from.file,from.temp); + } + + return retCode; +} + +static int shfileop_copy_unmasked(SHFILEOPSTRUCTW nFileOp,WIN32_FIND_DATAW wfd,struct fileops_file_data to,struct fileops_file_data from) +{ + int retCode = 0; + BOOL not_overwrite = (!(nFileOp.fFlags & FOF_NOCONFIRMATION) || (nFileOp.fFlags & FOF_RENAMEONCOLLISION)); + BOOL ask_overwrite = (!(nFileOp.fFlags & FOF_NOCONFIRMATION) && !(nFileOp.fFlags & FOF_RENAMEONCOLLISION)); + + if (SHFileStrICmpW(from.temp, to.temp, NULL, NULL)) + { /* target is the same as source ? */ + /* we still need the value for the returncode, we assume 0x71 */ + retCode = 0x71; + return retCode; + } + if (IsAttribDir((to.attr & wfd.dwFileAttributes))) + { + if (IsAttribDir(to.attr) || !SHNotifyCreateDirectoryW(to.temp, NULL)) + { + /* FIXME: copying directory contents into the other one: + * - path\\ -> path\\* + * COPY + * - loop over files in path\\*, eg path\\file + * COPY + * + * is this really necessary? why not a dedicated recursive + * (light-weight) function? + */ + + /* ??? nFileOp.fFlags = (nFileOp.fFlags | FOF_MULTIDESTFILES); */ + SHFileStrCpyCatW(from.temp, NULL, wWildcardFile); + TRACE("recursive copy\n"); + retCode = SHFileOperationW(&nFileOp); + } + else + { + retCode = 0x750;/* value unknown */ + return retCode; + } + } + else + { + if (!(ask_overwrite && SHELL_ConfirmDialogW(ASK_OVERWRITE_FILE, to.temp)) + && (not_overwrite)) + { + /* we still need the value for the returncode, we use the mostly assumed */ + retCode = 0x73; + return retCode; + } + if (SHNotifyCopyFileW(from.temp, to.temp, TRUE) != ERROR_SUCCESS) + { + retCode = 0x77; /* value unknown */ + return retCode; + } + } + return retCode; +} + /************************************************************************* * SHFileOperationW [SHELL32.@] *

1 0

Re: OLE without TLS libraries
by Cihan Altinay Dec. 16, 2005

Dec. 16, 2005

Quoting Marcus Meissner <marcus(a)jet.franken.de>: > On Thu, Dec 08, 2005 at 12:35:32PM +1000, Cihan Altinay wrote: > > Hi, > > > > having a Xen system my Linux tls library path is not > > in place (renamed to /lib/tls.disabled). > > When I run a program that uses OLE/DCOM (with native > > ole libraries) it crashes immediately. Using > > LD_LIBRARY_PATH=/lib/tls.disabled wine program > > makes it work again. > > I am not sure if this is true for all OLE apps. > > > > Is this known/expected behaviour or a bug? > > Do you have a backtrace of the crash or similar? Just wanted to create one with the latest CVS but it seems it was fixed some days ago. I investigated a bit and to my surprise the problem was in x11drv which was patched 2005-12-06. We had that problem since weeks and were "happy" with the library path solution until I thought I might ask here. So it was quite a surprise that it was fixed just now :-) Thanks anyway, Cihan

4 8