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

Re: Create new mailing list wine-isv?

by Alexandre Julliard

Tony Lambregts <tony.lambregts(a)gmail.com> writes: > Well that is a real sore spot with me. You know that I am a strong > supporter of wine but it really concerns me that we have gone beta and > not addressed preventing regessions from getting into our releases in > any way. We currently have no freeze or notification of exactly when > the next release is going to go out. Sure we had the one big code > freeze just before 0.9 but then we went back to releasing without any > notification. At his point even if our application maintainers test > their app every day there is no way for them to prevent that > regression going into the next release. The idea is that people should test the releases. The point of the beta phase is to encourage end users to test, and for this to happen they need to be able to get binary packages, which is what the releases are about. This is why I'm making releases more frequently too, so that end users are able to test effectively without having to build from CVS. The goal is not to prevent regressions between every minor point release, it's to make releases frequently enough that regressions can be found and fixed quickly, so that they don't creep into the next major release. Now, if you think that doesn't work I'm certainly open to doing things differently. What do you suggest? -- Alexandre Julliard julliard(a)winehq.org

Dec. 16, 2005

Re: ScrollDC should not clip output if a clipping rect is not specified

by Rein Klazes

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.

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Peter Beutner

Michael Jung schrieb: > On Friday 16 December 2005 15:41, Peter Beutner wrote: >>Don't get me wrong I still think it is perfectly valid that wine is doing >>that sort of hack to get existing windows applications working but you >>really shouldn't advertise it as a solution to platform independence and >>encourage developers to go this way. > > If someone plans to do a new multi-platform project, I'm pretty sure no one in > their right mind would suggest wine to do it. But there is a whole lot of > legacy applications for which the only economically feasible way to port them > to linux might be via wine. Agreed. This sums up quite well what I wanted to say ;)

Dec. 16, 2005

Re: SHFileOperationW split

by Joris Huizer

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

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Peter Beutner

Dmitry Timoshkov schrieb: > "Peter Beutner" <p.beutner(a)gmx.net> wrote: >>> Why? Wine is effectively just a different toolkit, like QT or GTK >>> (albeit much larger) that give applications a Windows, KDE and Gnome >>> look respectively. Take Notepad for example - with some slight >>> modifications you could even modify the File Open dialog to only show >>> the Unix namespace. Is there any reason that this application can't >>> be a fully fledged part of the desktop? >> >> >> Wine is _not_ just a different toolkit. Just look at all the "nasty" >> stuff wine has to do to emulate the windows process environment. This >> is not exactly what I would prefer as an ideal environment when I had >> to develop an application. > > Since Wine is not a trivial thing written in 3 lines of code and it has > huge compatibility requirements it must to do all kinds of things to make you > (a developer) not to do that kind of things in your own code. Think about that. hm if you somehow manage to build your project in a platform independent way so that you can build a native windows executable as well as a native linux one, then you don't need the whole compatibility code at all ;) > Said that, nothing makes it a different from another toolkit, no matter > what Wine haters think about it. hmm you don't mean this for real, don't you? >>> Sure. While you're at it give them some docs about globalization >>> practices and efficient CPU usage. These are all nice to have things, >>> but you have to face it that if you're a developer at a software >>> company with a deadline then these are the first things to be >>> ignored. You also have to bear in mind that it is incredibly >>> difficult to do platform idependent GUI programming, whilst still >>> maintaining the Windows look. >> >> Nobody said it's easy or that it will happen over night. But it >> can/should be the long term goal. Besides gtk+/qt are imho quite >> mature to use as cross-plattform gui toolkits. > > I don't understand why you can't include Wine in that list. Is that an > ignorance or a result of hate to all which goes from windows world? No, it's because I think wine is not a just a gui toolkit. >>> It is the cheapest way for companies and it gives good results for >>> the users. What's wrong with that? >> >> See above. Wine does a lot of "tricks" to emulate windows behaviour. >> And the more you use some complex window api the more is the chance >> that wine just can't implement it the way it works in windows but has >> to use all sorts of workarounds to get it to work under linux. > > Sounds like a popular Wine myth. Anyone who ever seen a working MS > Office 97/2000/XP/2003 or any other not trivial application working under Wine wouldn't tell > anything like that,especially if he is a knowledgeable developer and not another member ./ > crowd. Haven't said that it doesn't work. I just said sometimes you can't easily map stuff 1:1 from the windows world to linux. Just look at the things like the memory layout, parts of the gdi stuff, the whole ntoskrnl idea, ... >>> Wine is a very good way of testing the waters with a Linux market. If >>> a significant part of the market share starts coming from Linux or >>> other Unix operating systems then the company can start offering >>> winelib extensions that integrate better with the environment in >>> which they are running. >> >> I doubt that this will happen. If the windows version works with wine >> the company will more likely continue to work on that. See your money >> argument. > > Another myth about Wine. Glad to hear that. So there are already companies shipping winelib extensions for their products?

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Tony Lambregts

Jeremy White wrote: >>Not that I mean to sound like a pessimist, but I'm really just calling >>it as I see it. No offense to anyone intended. :) > > > This, in a nutshell, is Wine's greatest challenge > (stepping even outside ISV boundaries for a minute). > > I believe, either because I'm insane (the likely > explanation), or because it's true, that Wine has > progressed remarkably in the past 5 years, and can > no longer be correctly dismissed as unstable or unusable. > > I think the shift from Alpha to Beta status was a > more dramatic signal that anyone really realizes; > I think it marks the point where Wine can reliably > be used for a broad range of purposes. > > But, bluntly, we have to prove it. We have to start > by continuing the drive to a solid 1.0; we have to > continue helping a small number of ISVs really succeed. > > And then of course comes the fun part; we have to hold > that line and not let any regressions in :-/. <Rant> Well that is a real sore spot with me. You know that I am a strong supporter of wine but it really concerns me that we have gone beta and not addressed preventing regessions from getting into our releases in any way. We currently have no freeze or notification of exactly when the next release is going to go out. Sure we had the one big code freeze just before 0.9 but then we went back to releasing without any notification. At his point even if our application maintainers test their app every day there is no way for them to prevent that regression going into the next release. We had at least one known regression creep into 0.9.3. and maybe more that could have been corrected if we had some warning. I think that going to beta without any real attempt to provide even the most basic freeze release cycle is not a good thing. At the very minimum I would think that we should know when the releases are going to happen but we do not even know that. </Rant> > > But I think we can do it; it's why I'm still here. > Ditto. -- Tony Lambregts

Dec. 16, 2005

Re: msvcrt: Printf Integer Conversions

by Jesse Allen

On 12/16/05, Alexandre Julliard <julliard(a)winehq.org> wrote: > 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: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 long long I didn't fix, but I will next patch. > printf.c:51: Test failed: I0d failed > printf.c:63: Test failed: I64D failed: %D This one I avoided because I didn't want to cause regressions else where. I found another way now that I like so it will be fixed next patch. > printf.c:106: Test failed: #+25.22I64u conversion for -1 failed: got ' 0018446744073709551615', should be ' 18446744073709551615' -- obscure windows msvcrt bug? Sorry, this test is wrong, it does behave as expected on windows. Fixed. New patch coming very soon.

Dec. 16, 2005

Re: SHFileOperationW 1 : helper functions

by Mike McCormack

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

Dec. 16, 2005

Re: Create new mailing list wine-isv?

by Michael Jung

On Friday 16 December 2005 15:41, Peter Beutner wrote: > The point is that it won't be integrated in neither kernel or glibc. Integration in the loader is just one possibility. Wine needs to load code at fixed positions. Thus, there has to be a possibility to do it. Currently we do it in a way that some people consider a hack. If this is a problem (and I'm not saying that it actually is), we would have to fix it. This means we would have to illustrate our problem to the guys doing the randomization stuff. Wine is important to many people, so I think they would give us an open ear and we could fix the issues together. > Don't get me wrong I still think it is perfectly valid that wine is doing > that sort of hack to get existing windows applications working but you > really shouldn't advertise it as a solution to platform independence and > encourage developers to go this way. If someone plans to do a new multi-platform project, I'm pretty sure no one in their right mind would suggest wine to do it. But there is a whole lot of legacy applications for which the only economically feasible way to port them to linux might be via wine. Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Dec. 16, 2005

SHFileOperationW 1 : helper functions

by Joris Huizer

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.@] *

Dec. 16, 2005