November 2004 - Wine-Devel - list.winehq.org

Re: [shellpath.c]: minor fix to Rolf's patch

by Fabrice Ménard

> <menard.fabrice(a)wanadoo.fr> wrote: > > >The latest patch from Rolf Kalbermatter on shellpath.c was breaking the installation of wine.inf. > > > > wine rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 d:\\wine.inf > > > >was returning errors about being unable to create some dirs. In facts these errors was concerning > >already existing directories in SHGetFolderPathW. > > I believe this patch is not fully correct. I noticed these errors too after the patch was applied, > but did a little more investigation. SHCreateDirectoryEx should never be called if the directory > already exists since this is explicitedly tested before the call to the function with PathFileExistsW(). I came to the same conclusion as you. In fact, the SHCreateDirectoryEx function is never called if the "entire" path already exists (due to the first PathFileExistsW). The problem comes, as you saw it, with the intermediate components of the path. > Also inside the SHCreateDirectoryEx function I saw that the first call to CreateDirectory fails since > intermediate directories are missing and then in the recursive call to CreateDirectory every single > call returns ERROR_ALREAY_EXISTS on my system in spite of that it actually creates the last two or > three directories in there. > My investigations showed that in spite of that some of the the top level directories do not exist, the > function NtCreateFile() which is ultimately called does seem to return an according NT status when > called from SHGetFolderPath() but does create the directory nevertheless. > > Strange thing is that I can't reproduce this behaviour when calling SHCreateDirectoryEx() with many > different parameters from an extended test in tests/shfileop.c > > So I believe the root cause really seems somewhere else, namely NTCreateFile or maybe wineserver itself, > but I hadn't time to further go into details. > > >I think it is not necessary to care about that in this function so I added a check on the > >type of error returned by SHCreateDirectoryExW. > > ShCreateDirectory should fail with that error if the directory really already existed. > > Rolf Kalbermatter > I agree that SHCreateDirectory should fail, but I'm not convinced it is crucial int the specific SHGetFolderPathW function. But I may be wrong. Anyway, I'll try to see if I can find a better solution. Regards, -- Fabrice Ménard menard.fabrice(a)wanadoo.fr

Nov. 2, 2004

Re: Add time zone to TZ_Info

by Uwe Bonnes

>>>>> "Duane" == Duane Clark <dclark(a)akamail.com> writes: Duane> Roger wrote: >> I agree that PDT should say "Pacific Daylight Time" but whoever wrote >> this section refered to both ..DT and ..ST as "Standard Time" for >> some good reason.I assumed so I followed convention. It came up in >> an app I was running as a fixme since we switched to std time today >> and is used by TIME_GetTZAsStr(). If it appears beneficial, I'll be >> happy to change all the ..DT references to "Daylight Time" and >> resubmit. >> Duane> Not quite every place; MEST says daylight. It appears to me that Duane> the only place this is used is the function TIME_GetTZAsStr(), Duane> which appears to only be used in Duane> RtlQueryTimeZoneInformation(). So the question would be, what Duane> does that function return on Windows (and perhaps, does any Duane> program care). These timezione names are a mess, both under windows and wine... On windows they depend on the language version. What I have seen so long: Xilinx Webupdate depends on the string returned to be non-Null. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Nov. 2, 2004

[shellpath.c]: minor fix to Rolf's patch

by Rolf Kalbermatter

<menard.fabrice(a)wanadoo.fr> wrote: >The latest patch from Rolf Kalbermatter on shellpath.c was breaking the installation of wine.inf. > > wine rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 d:\\wine.inf > >was returning errors about being unable to create some dirs. In facts these errors was concerning >already existing directories in SHGetFolderPathW. I believe this patch is not fully correct. I noticed these errors too after the patch was applied, but did a little more investigation. SHCreateDirectoryEx should never be called if the directory already exists since this is explicitedly tested before the call to the function with PathFileExistsW(). Also inside the SHCreateDirectoryEx function I saw that the first call to CreateDirectory fails since intermediate directories are missing and then in the recursive call to CreateDirectory every single call returns ERROR_ALREAY_EXISTS on my system in spite of that it actually creates the last two or three directories in there. My investigations showed that in spite of that some of the the top level directories do not exist, the function NtCreateFile() which is ultimately called does seem to return an according NT status when called from SHGetFolderPath() but does create the directory nevertheless. Strange thing is that I can't reproduce this behaviour when calling SHCreateDirectoryEx() with many different parameters from an extended test in tests/shfileop.c So I believe the root cause really seems somewhere else, namely NTCreateFile or maybe wineserver itself, but I hadn't time to further go into details. >I think it is not necessary to care about that in this function so I added a check on the >type of error returned by SHCreateDirectoryExW. ShCreateDirectory should fail with that error if the directory really already existed. Rolf Kalbermatter

Nov. 2, 2004

Re: compiling wine with msvc

by James Hawkins

I have installed the latest platform SDk and directx SDK, and set up msvc per http://www.winehq.org/site/docs/wine-devel/testing-windows, but I get this error when compiling dsound_test: Linking... uuid.lib(unknwn_i.obj) : fatal error LNK1103: debugging information corrupt; recompile module Error executing link.exe. wineruntests.exe - 1 error(s), 11 warning(s) Any ideas? On Mon, 1 Nov 2004 22:39:39 -0500, Dimitrie O. Paun <dpaun(a)rogers.com> wrote: > On Tue, Nov 02, 2004 at 01:10:41AM +0100, Francois Gouget wrote: > > As of a few days ago, I was able to compile all of the Wine conformance > > tests (not the Wine dlls themselves) using: the MSVC targets, MSVC 6.0, > > a recent Platform SDK and a recent Direct X SDK. > > It would be really cool if we: > 1. Had documentation on how to do the above (building the tests with > MSVC) from within Linux via Wine. > 2. Could actually build the dlls themselves with MSVC. Any efforts > in that direction? Did anyone try this? If so, we could track the > progress on the Fun Projects page. > > -- > Dimi > -- James Hawkins

Nov. 2, 2004

Re: compiling wine with msvc

by Dimitrie O. Paun

On Tue, Nov 02, 2004 at 01:10:41AM +0100, Francois Gouget wrote: > As of a few days ago, I was able to compile all of the Wine conformance > tests (not the Wine dlls themselves) using: the MSVC targets, MSVC 6.0, > a recent Platform SDK and a recent Direct X SDK. It would be really cool if we: 1. Had documentation on how to do the above (building the tests with MSVC) from within Linux via Wine. 2. Could actually build the dlls themselves with MSVC. Any efforts in that direction? Did anyone try this? If so, we could track the progress on the Fun Projects page. -- Dimi

Nov. 2, 2004

Re: Countering arguments against Wine

by Holly Bostick

Ryan Underwood wrote: > On Sat, Oct 30, 2004 at 04:32:02PM +0200, Holly Bostick wrote: > > >>find that it doesn't necessarily "feel strange" or at least as strange >>as I might have imagined. What mostly feels strange is the complications >>of getting the program started in the first place (having to cd to the >>application folder to run wine <program_name> from a terminal, or having >>to write a little start script in order to make a panel shortcut to it). > > > You might look into the kernel's miscellaneous binary format support. > On my Debian system, with binfmt-support package installed, I can > directly execute a PE executable (WINE is invoked automatically by the > kernel). > Yes, I've just installed that for the first time during my recent kernel upgrade. Haven't really tested it out, though. However, I think that the presence of this ability is not necessarily a strong counter-argument since 1) it requires the user to either be quite familiar with their system, or know such a person, in order to set it up in the first place, and 2) is not necessarily useful if you have more than one Wine variant (or version) on the system (haven't checked this out either, but I expect problems). It is not necessarily unreasonable for a home, multi-user computer to "need", let us say, Crossover Office (or regular Wine) for Dad's work, and Cedega (or regular Wine, possibly a different version) for the kids' games. What binary is going to be invoked when the user double-clicks, if different applications need to be run with different versions/types of Wine? OK, I'll grant you that if a user knows how to install multiple versions of Wine on a system without conflict, they probably won't care about this double-clicking business in the first place, and I'll also grant that Wine is not CX is not Cedega-- but... we're talking about often inexperienced people who are likely relying on Windows programs as a crutch to avoid the "confusingness" of Linux in the first place (the issue in question is easing migration woes, after all). Such a user, when informed that CX is good for apps, and Cedega is good for games, might well install both, which is possible to do without problems, afaik (as they install in different places, and the wine or cx binaries and the cedega binaries do not have the same name). So what's going to happen with the file associations on which the double-click strategy relies? Games are not distinguished from MSOffice in terms of being some other mime-type than "DOS/Windows executable". Is CX going to try to open FarCry? Or is Cedega going to try to open Photoshop? I really don't know (not having tried this), but I wonder, and suspect that it would bite me in the butt if I did try. So while I do appreciate this functionality, I'm not sure it's flexible enough to cover the vast range of strange things that former Windows users might do (given that they're under the general impression that they can just click once and accomplish anything, no matter how complex or technically difficult-- through no fault of their own, I might add; they've just been sold a bill of goods, no pun intended). Holly

Nov. 2, 2004

Re: Countering arguments against Wine

by Ryan Underwood

On Sat, Oct 30, 2004 at 04:32:02PM +0200, Holly Bostick wrote: > find that it doesn't necessarily "feel strange" or at least as strange > as I might have imagined. What mostly feels strange is the complications > of getting the program started in the first place (having to cd to the > application folder to run wine <program_name> from a terminal, or having > to write a little start script in order to make a panel shortcut to it). You might look into the kernel's miscellaneous binary format support. On my Debian system, with binfmt-support package installed, I can directly execute a PE executable (WINE is invoked automatically by the kernel). -- Ryan Underwood, <nemesis(a)icequake.net>

Nov. 2, 2004

Re: Ok, trying again

by Markus Amsler

Hi, This patch doesn't aplly smoothly, because you did the cvs diff not from the wine-root directory. do: at ~/src/wine$ cvs diff -u dlls/msvrt/tests/file.c You can test if your patch apllies with $ patch -p0 < file.diff from the wine root. If there are no error messages the format is fine. To remove the patch do $ patch -p0 -R <file.diff I hope this helps Markus Jakob Eriksson wrote: > *src/wine/dlls/msvcrt/tests > > > * > jakov(a)toto:~/src/wine/dlls/msvcrt/tests$ cvs diff -u file.c > Index: file.c > =================================================================== > RCS file: /home/wine/wine/dlls/msvcrt/tests/file.c,v > retrieving revision 1.10 > diff -u -r1.10 file.c > --- file.c 3 Sep 2004 01:05:30 -0000 1.10 > +++ file.c 1 Nov 2004 16:24:06 -0000 > @@ -306,7 +306,25 @@ > ok(res[strlen(res)-1] != '.', "second call - last character is a > dot\n"); > } > > +static void test_access( void ) > +{ > + FILE *fp; > + > + const char filename[] = "tmpfile.tst"; > + ok(-1 == _access(filename, 0), "This file should not exist yet.\n"); > + ok(ENOENT == errno, "and errno should be ENOENT but it is %d.\n", > errno); > + > + fp = fopen(filename, "w"); > + if (NULL == fp) return; > + fclose(fp); > > + ok(0 == _access(filename, 0), "Now the file should exist.\n"); > + ok(0 == _access(filename, 2), "We should have write permission, > after all I created it. errno=%d\n", errno); > + ok(0 == _access(filename, 4), "We should have read permission. > errno=%d\n", errno); > + ok(0 == _access(filename, 6), "We should also be able to check > for read and write permission. errno=%d\n", errno); > + > + _unlink(filename); > +} > > START_TEST(file) > { > @@ -321,6 +339,7 @@ > return; > } > > + test_access(); > test_fdopen(); > test_fileops(); > test_fgetwc(); > > >

Nov. 2, 2004

Re: compiling wine with msvc

by James Hawkins

> * You say that you use MSVC 6.0. Did you also install a recent Platform > SDK? If not the tests won't compile as stated in the above > documentation. I have not done that yet. I will install the platform sdk and then see if it works. On Tue, 2 Nov 2004 01:10:41 +0100 (CET), Francois Gouget <fgouget(a)free.fr> wrote: > On Mon, 1 Nov 2004, James Hawkins wrote: > [...] > > I'm pretty sure the problem is that the the msvc's rpc.h and rpcnsi.h > > files are being included when they shouldn't. Is that about right? > > If so, what could be a possible solution? > > > > BTW I'm compiling with MSVC++ 6.0. wine cvs from 11-01-2004. > > Two questions: > > * Have you checked the following section of the Wine Developer's > Guide? > > Building and running the tests on Windows > http://www.winehq.org/site/docs/wine-devel/testing-windows > > * You say that you use MSVC 6.0. Did you also install a recent Platform > SDK? If not the tests won't compile as stated in the above > documentation. > > As of a few days ago, I was able to compile all of the Wine conformance > tests (not the Wine dlls themselves) using: the MSVC targets, MSVC 6.0, > a recent Platform SDK and a recent Direct X SDK. > > -- > Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ > In a world without fences who needs Gates? > -- James Hawkins

Nov. 2, 2004

Re: compiling wine with msvc

by Francois Gouget

On Mon, 1 Nov 2004, James Hawkins wrote: [...] > I'm pretty sure the problem is that the the msvc's rpc.h and rpcnsi.h > files are being included when they shouldn't. Is that about right? > If so, what could be a possible solution? > > BTW I'm compiling with MSVC++ 6.0. wine cvs from 11-01-2004. Two questions: * Have you checked the following section of the Wine Developer's Guide? Building and running the tests on Windows http://www.winehq.org/site/docs/wine-devel/testing-windows * You say that you use MSVC 6.0. Did you also install a recent Platform SDK? If not the tests won't compile as stated in the above documentation. As of a few days ago, I was able to compile all of the Wine conformance tests (not the Wine dlls themselves) using: the MSVC targets, MSVC 6.0, a recent Platform SDK and a recent Direct X SDK. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ In a world without fences who needs Gates?

Nov. 2, 2004