- Wine-Devel - list.winehq.org

Re: [OLE #45] Proxy Manager Fixes
by Bill Medland Jan. 18, 2005

Jan. 18, 2005

On January 18, 2005 02:04 pm, Robert Shearman wrote: > Hi, > > I have also fixed (kinda) the issue Bill > Medland was reporting where doing a CreateInstance for an IUnknown > interface was a bit messed up (this is bad programming anyway as it > doubles the number of RPC calls required). Maybe. (After all, Microsoft aren't perfect). However since it is in the ATL code we can expect it to occur from time to time, surely. > > Rob >

2 1

Re; cleanup shlfileop.c: why does this fail?
by Rolf Kalbermatter Jan. 18, 2005

Jan. 18, 2005

Joris Huizer wrote: >That line can be removed as >nFileOp = *(lpFileOp) >on the first line - the variable is never changed after that (yeah, if >we really like, we could get rid of it) >I hadn't removed it just like that, yet - but as it is useless, it can >be removed. I wouldn't do that! This first line does not just copy a pointer but the ENTIRE structure. And those parameters are sometimes overwritten inside the function. So this last line also does do something, namely copying the aborted state back into the main structure for reference by the caller. Rolf Kalbermatter

1 0

Re: Ukrainian support
by Juan Lang Jan. 18, 2005

Jan. 18, 2005

Hi Oleh, > --- wine-20050111/libs/unicode/cpmap.pl.orig 2004-01-21 00:39:06.000000000 +0200 > +++ wine-20050111/libs/unicode/cpmap.pl 2005-01-14 15:22:12.000000000 +0200 > @@ -82,6 +82,7 @@ > [ 10081, "VENDORS/MICSFT/MAC/TURKISH.TXT", "Mac Turkish" ], > [ 20866, "VENDORS/MISC/KOI8-R.TXT", "Russian KOI8" ], > [ 20932, "OBSOLETE/EASTASIA/JIS/JIS0208.TXT", "EUC-JP" ], > + [ 21866, "VENDORS/MISC/KOI8-R.TXT", "Ukrainian KOI8" ], > [ 28591, "ISO8859/8859-1.TXT", "ISO 8859-1 Latin 1" ], > [ 28592, "ISO8859/8859-2.TXT", "ISO 8859-2 Latin 2 (East European)" ], > [ 28593, "ISO8859/8859-3.TXT", "ISO 8859-3 Latin 3 (South European)" ], I may be missing something, but don't you mean "VENDORS/MISC/KOI8-U.TXT"? --Juan __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

1 0

Question about testing SHQueryValueExA in shlwapi/tests/shreg.c
by Paul Vriens Jan. 18, 2005

Jan. 18, 2005

Hi, I'm trying to fix the tests in shlwapi/tests/shreg.c (or Wine for that matter). One thing that puzzles me in the current code is the checks done after we receive a ERROR_MORE_DATA when we pass a size smaller than the actual data. MSDN states: If the buffer specified by pvData parameter is not large enough to hold the data, the function returns ERROR_MORE_DATA and stores the required buffer size in the variable pointed to by pcbData. In this case, the contents of the pvData buffer are undefined. If that's the case, what's the use of checking the returned buffer with something? Wine and Win98 leave the buffer intact (the contents and thus size differ however) WinXPProf and W2KProf clear (so it seems) the buffer. Cheers, Paul Vriens.

2 2

Re; cleanup shlfileop.c: why does this fail?
by Juan Lang Jan. 18, 2005

Jan. 18, 2005

Hi Joris, pFromFile and pToFile are treated oddly. Pass them as WCHAR pointers to file_operation_on_data, not as pointers to WCHAR pointers. The implementation of file_operation_on_data does not behave the same way as the code it replaced. You want something like: +static int file_operation_on_data(WIN32_FIND_DATAW *wfd,SHFILEOPSTRUCTW *nFileOp, LPWSTR pFromFile,LPWSTR pToFile) +{ + LPWSTR lpFileName = wfd->cAlternateFileName; + if (!lpFileName[0]) + lpFileName = wfd->cFileName; + if (IsDotDir(lpFileName) || + (IsAttribDir(wfd->dwFileAttributes) && (nFileOp->fFlags & FOF_FILESONLY))) + { + return 0; /* next name in pTempFrom(dir) */ + } + SHFileStrCpyCatW(&pToFile[1], lpFileName, NULL); + SHFileStrCpyCatW(&pFromFile[1], lpFileName, NULL); + return SHFileOperationW (nFileOp); +} One other difference that jumps out at me: - lpFileOp->fAnyOperationsAborted = nFileOp.fAnyOperationsAborted; + /*lpFileOp->fAnyOperationsAborted = nFileOp.fAnyOperationsAborted;*/ Why this change? --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250

2 1

Re: [LOSTWAGES] Add Alexandre's comment about the strncpy janitorial project
by Jeremy Newman Jan. 18, 2005

Jan. 18, 2005

Crap, I thought I queued up these downloads a week or so ago. Someone must have rebooted taz and killed my downloads. Argh, if it didn't take so long to dl these ISO's. Anyway, I restarted the downloads again, I hopefully should have them by the end of today. I'll move them into /home/public/iso when done. The CD keys are already in the cd keys txt file. On Tue, 2005-01-18 at 11:26 +0900, Mike McCormack wrote: > ChangeLog: > * Add Alexandre's comment about the strncpy janitorial project > plain text document attachment (janitorial-strncpy-update.diff) > Index: templates/en/janitorial.template > =================================================================== > RCS file: /home/wine/lostwages/templates/en/janitorial.template,v > retrieving revision 1.63 > diff -u -r1.63 janitorial.template > --- templates/en/janitorial.template 13 Jan 2005 19:35:16 -0000 1.63 > +++ templates/en/janitorial.template 18 Jan 2005 02:23:57 -0000 > @@ -25,6 +25,13 @@ > the <i>dst</i> buffer, and always nul terminate the buffer when we > intended to.<p> > > + Julliard > + <a href="http://www.winehq.org/hypermail/wine-devel/2005/01/0390.html">says</a>: > + "A careful review of the code to ensure that lstrcpyn semantics are really what > + we want. In several cases we know that we are copying less than the full string, > + and in that case we have to use memcpy instead, lstrcpyn won't do the right > + thing."<p> > + > <h2>Regedit fixes</h2> > > Regedit lacks a few features. We need to improve regedit to:

1 1

cleanup shlfileop.c: why does this fail?
by Joris Huizer Jan. 18, 2005

Jan. 18, 2005

Hi, As you can see in the attached patch file, I wrote a function file_operation_on_data() which uses a WIN32_FIND_DATAW to do a file operation; however, for some reason, tests start to fire when using the function: ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shellpath.c && touch shellpath.ok fixme:shell:_SHGetUserProfilePath unsupported for user other than current or default fixme:shell:_SHGetUserProfilePath unsupported for user other than current or default ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c && touch shlfileop.ok shlfileop.c:276: Test failed: Files and directories are copied to directory shlfileop.c:277: Test failed: The file is copied shlfileop.c:278: Test failed: The directory is copied shlfileop.c:279: Test failed: The file in subdirectory is copied shlfileop.c:287: Test failed: The file is copied shlfileop.c:345: Test failed: Files and directories are moved to directory shlfileop.c:346: Test failed: The file is moved shlfileop.c:347: Test failed: The directory is moved shlfileop.c:348: Test failed: The file in subdirectory is moved make[1]: *** [shlfileop.ok] Error 9 How can I find out where the problem is? Nothing *should* have changed by inserting that function I think, but I must be missing something here regards, Joris Index: dlls/shell32/shlfileop.c =================================================================== RCS file: /home/wine/wine/dlls/shell32/shlfileop.c,v retrieving revision 1.51 diff -u -r1.51 shlfileop.c --- dlls/shell32/shlfileop.c 14 Jan 2005 16:51:14 -0000 1.51 +++ dlls/shell32/shlfileop.c 18 Jan 2005 16:23:43 -0000 @@ -945,6 +945,40 @@ return 0; } +static int file_operation_invalid_handle(long FuncSwitch, LPWSTR pFromFile, DWORD ToPathAttr, LPWSTR pTempFrom) +{ + BOOL b_Mask = (NULL != StrPBrkW(&pFromFile[1], wWildcardChars)); + if ((FO_DELETE == FuncSwitch) && (b_Mask)) + { + DWORD FromPathAttr; + pFromFile[0] = '\0'; + FromPathAttr = GetFileAttributesW(pTempFrom); + pFromFile[0] = '\\'; + if (IsAttribDir(FromPathAttr)) + { + /* FO_DELETE with mask and without found is valid */ + return 0; + } + } + /* root (without mask) is also not allowed as source, tested in W98 */ + return ERROR_SHELL_INTERNAL_FILE_NOT_FOUND; +} + +static int file_operation_on_data(WIN32_FIND_DATAW *wfd,SHFILEOPSTRUCTW *nFileOp, LPWSTR *pFromFile,LPWSTR *pToFile) +{ + LPWSTR lpFileName = wfd->cAlternateFileName; + if (!lpFileName[0]) + lpFileName = wfd->cFileName; + if (IsDotDir(lpFileName) || + (IsAttribDir(wfd->dwFileAttributes) && (nFileOp->fFlags & FOF_FILESONLY))) + { + return 0; /* next name in pTempFrom(dir) */ + } + SHFileStrCpyCatW(&(*pToFile[1]), lpFileName, NULL); + SHFileStrCpyCatW(&(*pFromFile[1]), lpFileName, NULL); + return SHFileOperationW (nFileOp); +} + /************************************************************************* * SHFileOperationW [SHELL32.@] * @@ -964,7 +998,6 @@ LPWSTR pTempTo = NULL; LPWSTR pFromFile; LPWSTR pToFile = NULL; - LPWSTR lpFileName; int retCode = 0; DWORD ToAttr; DWORD ToPathAttr; @@ -986,8 +1019,6 @@ long FuncSwitch = (nFileOp.wFunc & FO_MASK); long level= nFileOp.wFunc>>4; - int ret; - /* default no error */ nFileOp.fAnyOperationsAborted = FALSE; @@ -1016,10 +1047,9 @@ * create dir 0 0 0 0 0 0 1 0 */ - ret = file_operation_checkFlags(nFileOp); - if (ret != 0) + retCode = file_operation_checkFlags(nFileOp); + if (retCode) { - retCode = ret; goto shfileop_end; } @@ -1108,20 +1138,7 @@ hFind = FindFirstFileW(pFrom, &wfd); if (INVALID_HANDLE_VALUE == hFind) { - if ((FO_DELETE == FuncSwitch) && (b_Mask)) - { - DWORD FromPathAttr; - pFromFile[0] = '\0'; - FromPathAttr = GetFileAttributesW(pTempFrom); - pFromFile[0] = '\\'; - if (IsAttribDir(FromPathAttr)) - { - /* FO_DELETE with mask and without found is valid */ - goto shfileop_end; - } - } - /* root (without mask) is also not allowed as source, tested in W98 */ - retCode = ERROR_SHELL_INTERNAL_FILE_NOT_FOUND; + retCode = file_operation_invalid_handle(FuncSwitch,pFromFile,ToPathAttr,pTempFrom); goto shfileop_end; } @@ -1130,11 +1147,10 @@ /* ??? b_Mask = (!SHFileStrICmpA(&pFromFile[1], &wfd.cFileName[0], HIGH_ADR, HIGH_ADR)); */ if (!pTo) /* FO_DELETE */ { - ret = file_operation_delete(&wfd,nFileOp,pFromFile,pTempFrom,&hFind); - /* if ret is not 0, nFileOp.fAnyOperationsAborted is TRUE */ - if (ret != 0) + retCode = file_operation_delete(&wfd,nFileOp,pFromFile,pTempFrom,&hFind); + /* if retCode is not 0, nFileOp.fAnyOperationsAborted is TRUE */ + if (retCode) { - retCode = ret; goto shfileop_end; } continue; @@ -1202,15 +1218,7 @@ nFileOp.fFlags = (nFileOp.fFlags | FOF_MULTIDESTFILES); do { - lpFileName = wfd.cAlternateFileName; - if (!lpFileName[0]) - lpFileName = wfd.cFileName; - if (IsDotDir(lpFileName) || - (IsAttribDir(wfd.dwFileAttributes) && (nFileOp.fFlags & FOF_FILESONLY))) - continue; /* next name in pTempFrom(dir) */ - SHFileStrCpyCatW(&pToFile[1], lpFileName, NULL); - SHFileStrCpyCatW(&pFromFile[1], lpFileName, NULL); - retCode = SHFileOperationW (&nFileOp); + retCode = file_operation_on_data(&wfd,&nFileOp,&pFromFile,&pToFile); } while(!nFileOp.fAnyOperationsAborted && FindNextFileW(hFind, &wfd)); } FindClose(hFind); @@ -1369,7 +1377,7 @@ nFileOp.fAnyOperationsAborted ? "TRUE":"FALSE", retCode, debugstr_w(pFrom), pTo ? "-> ":"", debugstr_w(pTo)); - lpFileOp->fAnyOperationsAborted = nFileOp.fAnyOperationsAborted; + /*lpFileOp->fAnyOperationsAborted = nFileOp.fAnyOperationsAborted;*/ return retCode; }

1 0

Re: DCE 1.2.2 released under LGPL license (strategically important for Wine)
by Luke Kenneth Casson Leighton Jan. 18, 2005

Jan. 18, 2005

> If we need to extend it later using code from FreeDCE may be > possible, but right now we : > a) Don't know of *any* pure DCE-RPC applications people want to run you _are_ aware that REGEDT32, USRMGR.EXE, SRVMGR.EXE and most of the NT 4.0 Control Panel components are actually DCE/RPC programs? see, your point is _exactly_ the problem ! there aren't any dce-rpc applications in a strict interpretation of what you say, because dce-rpc is middleware: it's a communicator, an intermediary, and it absolutely xxxx-all use on its own [imagine trying to sell ONC/RPC's portmap as a stand-alone application] and there is another less-strict and more subtle interpretation of your statement. when people run mozilla, they know it, they see it, it's in-their-face. when they run a win32 program, they know it, they see it, it "happens". that DCE-RPC is "middleware" of the highest order (and as such is completely invisible) is _exactly_ the problem: people do not even _know_ it's there! so you and everyone in the free software community can be forgiven for not being aware of any dce-rpc applications that people want to run. like i said in my advogato article 817, dce-rpc is like the Boss 13L V10 engine that Ford put in their 1994 Ford Mustang Cobra "Concept Car": it's capable of producing wheel-spin in 4th gear all the way up to 110mph (i've seen the video!!!) ... yet an engine is xxxx-all use without a car. ... would you build a car with the engine integrated into the chassis?? no, of course not, because you would have seen enough examples of cars to know that that would produce a nightmare design and maintenance headache. ... if you were _given_ a suitable engine for free, would you look at ways of finding engine-mounts and gearbox adaptors? i realise that the answer to _that_ depends on how far down the road you had got in building your kit car.... so, to recap the analogy: * FreeDCE is the engine * DCOM is the after-market supercharger or Turbocharger, exhaust, mod chip, disk brakes and alloy wheels, and the Pi Research Telemetry equipment, all of which makes it essential for you to qualify for - and win - certain kinds of races. * NTLMSSP and "Named Pipes" are the gearbox. * Win32 applications are the chassis * The Win32 GUI is the steering wheel, seat and pedals. ... unless it was electric, you wouldn't build a car without those components, would you? l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 1

Re: MPR: remove netspi.h
by Juan Lang Jan. 17, 2005

Jan. 17, 2005

> I think it's probably better to move this file into dlls/mpr rather than > delete it altogether. Apparently it did exist in the Windows 98 DDK. For what reason, for documentation? Several of its declarations conflict with those in npapi.h, so it's potentially problematic. If it's not part of the PSDK, winelib users shouldn't need it to compile, or should expect to have to install the DDK if they need the prototypes, yes? If you think it's a better approach I can rename all the conflicting types, and document why the typenames don't match the expected ones. Even so, I'm not convinced a separate header file is preferable to moving the declarations to nps.c (the only user of these declarations.) --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

2 1

Re: [OLE #31] Dynamically Allocate the MTA
by Vincent Béron Jan. 17, 2005

Jan. 17, 2005

Le mar 11/01/2005 à 14:03, Robert Shearman a écrit : > Changelog: > - Make MTA dynamically allocated so that proxies and other resources are > freed at the proper time. > - Changed/removed some incorrect comments regarding apartments. > ---- > This patch broke wineprefixcreate invocation for me. What happens is I get a: X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 18 (X_ChangeProperty) Resource id in failed request: 0x77e61740 Serial number of failed request: 107 Current serial number in output stream: 114 error while wineprefixcreate runs "wine rundll32.exe setupapi.dll,InstallHinfSection DefaultInstall 128 wine.inf". The error do go away if one of avifil32.dll or devenum.dll is commented out in [RegisterDllsSection] in wine.inf. My personal guess is that one (or both) of those dlls do something which they should not, and we end up with using freed or unallocated memory. Vincent

2 2