Re: annoyance running mingw
Dan Kegel wrote: Tony Lambregts wrote: Well... AFAICT this situation could only happen in a "Wine with windows" install. I'm doubt that's the case. As far as I can see, this can easily happen on any Wine installation. All it takes is a Windows app that uses Linux-like paths that happen to clash with real Linux paths. Then again, I could be all wet. I suppose I should write a little test case. Maybe even submit it as a regression test. That would make things clearer. Sounds like the best idea. -- Tony Lambregts
Re: annoyance running mingw
Tony Lambregts wrote: Well... AFAICT this situation could only happen in a "Wine with windows" install. I'm doubt that's the case. As far as I can see, this can easily happen on any Wine installation. All it takes is a Windows app that uses Linux-like paths that happen to clash with real Linux paths. Then again, I could be all wet. I suppose I should write a little test case. Maybe even submit it as a regression test. That would make things clearer. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: annoyance running mingw
Dan Kegel wrote:
Tony Lambregts wrote:
What about reversing the order: first try the DOS
path, if that fails, try the Unix one...
It is not possible to easily reverse the order in wine searches
DOSFS_GetPathDrive. If it sees a "/" then it tries to use the path as
a (absolute) unix one otherwise it just returns the current drive.
Changing this behavior is not simple and however annoying the message
is it is correct.
The message is correct, but Wine's behavior is not. I'm pretty
sure you understand the issue, but for anyone still wondering:
The problem is strictly theoretical at this point, but we should be aware
of it in case somebody runs into it in the future. Here's the
scenario:
* user installs MinGW or some other app that's been ported
to Win32 but uses Unix-style path separators for win32
directories
* a path used by the program happens to exist both in
the Windows filespace on drive C: (presumably this would be something
installed by the app) and in the Unix filespace.
For instance, the path /etc/blort/config might be a configuration
file for a library used both on Linux and installed independently
onto drive C: by the application.
* The app tries to open the file on drive C:, and gets the
file in Linux instead. Bang! The program crashes, or gives
bad results.
Well... AFAICT this situation could only happen in a "Wine with
windows" install. In a wine only installation this situation should not
occure since wine will always choose the unix path. Perhaps it would be
better to change the behavior so that Wine tries the path as a DOS path
first but it isn't a quick and easy thing to do.
The reason I am interested in this is that there are a number of other
bug/features in Wine's emulation of the DOS file system that I am
looking at (1). Anyways at this point I am not as familiar/comforable
with this section of the code to attempt to change it.
[snip]
Or something like that, yeah. We want to display a hint that
there might be a misinterpretation of a DOS path as a Unix path.
so you really would want something more like this :
{
if ((drive = DRIVE_FindDriveRootW( name )) == -1)
{
-MESSAGE("Warning: %s not accessible from a configured DOS drive\n",
debugstr_w(*name) );
+WARN("failed to find %s as an absolute unix path mapped to configured DOS
drive \n",
+ debugstr_w(*name) );
+WARN("assuming it was a really a DOS name")
/* Assume it really was a DOS name */
drive = DRIVE_GetCurrentDrive();
}
+ else
+ {
+ WARN("Using %s as a absolute unix path\n" debugstr_w(*name) );
+ }
}
else drive = DRIVE_GetCurrentDrive();
Sort of dambed if we dambed if we don't. At least WARN's arn't automaticly spit out.
--
Tony Lambregts
Re: annoyance running mingw
It seems to be true, ported mingwmicq-0.4.10.1-mingw.exe wrote .micqrc
into
my linux $HOME.
> The message is correct, but Wine's behavior is not. I'm pretty
> sure you understand the issue, but for anyone still wondering:
> The problem is strictly theoretical at this point, but we should be
> aware
> of it in case somebody runs into it in the future. Here's the
> scenario:
> * user installs MinGW or some other app that's been ported
> to Win32 but uses Unix-style path separators for win32
> directories
> * a path used by the program happens to exist both in
> the Windows filespace on drive C: (presumably this would be
> something
> installed by the app) and in the Unix filespace.
> For instance, the path /etc/blort/config might be a configuration
> file for a library used both on Linux and installed independently
> onto drive C: by the application.
>* The app tries to open the file on drive C:, and gets the
> file in Linux instead. Bang! The program crashes, or gives
> bad results.
>
> > ... In order to change this behavior we would have to
> > make changes to GetShortPathNameW so that it tries the path with
> the
> > current drive first and then calls this (modified) function. After
> > looking at the code for the last couple of hours I'm sure it could
> be
> > done but I don't know if it is worth it.
>
> Thanks for looking at it.
>
> > At present I think that it would be better to change the message
> >
> >{
> >
> >if ((drive = DRIVE_FindDriveRootW( name )) == -1)
> >
> >{
> >
> > -MESSAGE("Warning: %s not accessible from a configured
> DOS
> > drive\n", debugstr_w(*name) );
> >
> > +WARN("failed to find %s as an absolute unix path
> mapped to
> > configured DOS drive \n",
> > + debugstr_w(*name) );
> > +WARN("assuming it was a really a DOS name")
> >/* Assume it really was a DOS name */
> >
> >drive = DRIVE_GetCurrentDrive();
> >
> >}
> >
> > Or something like that.
>
> Or something like that, yeah. We want to display a hint that
> there might be a misinterpretation of a DOS path as a Unix path.
> - Dan
>
> --
> Dan Kegel
> http://www.kegel.com
> http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
>
>
=
Sylvain Petreolle
[EMAIL PROTECTED]
Fight against Spam ! http://www.euro.cauce.org/en/index.html
ICQ #170597259
"Don't think you are. Know you are." Morpheus, in "Matrix".
___
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
Re: annoyance running mingw
Tony Lambregts wrote:
What about reversing the order: first try the DOS
path, if that fails, try the Unix one...
It is not possible to easily reverse the order in wine searches
DOSFS_GetPathDrive. If it sees a "/" then it tries to use the path as a
(absolute) unix one otherwise it just returns the current drive.
Changing this behavior is not simple and however annoying the message is
it is correct.
The message is correct, but Wine's behavior is not. I'm pretty
sure you understand the issue, but for anyone still wondering:
The problem is strictly theoretical at this point, but we should be aware
of it in case somebody runs into it in the future. Here's the
scenario:
* user installs MinGW or some other app that's been ported
to Win32 but uses Unix-style path separators for win32
directories
* a path used by the program happens to exist both in
the Windows filespace on drive C: (presumably this would be something
installed by the app) and in the Unix filespace.
For instance, the path /etc/blort/config might be a configuration
file for a library used both on Linux and installed independently
onto drive C: by the application.
* The app tries to open the file on drive C:, and gets the
file in Linux instead. Bang! The program crashes, or gives
bad results.
... In order to change this behavior we would have to
make changes to GetShortPathNameW so that it tries the path with the
current drive first and then calls this (modified) function. After
looking at the code for the last couple of hours I'm sure it could be
done but I don't know if it is worth it.
Thanks for looking at it.
At present I think that it would be better to change the message
{
if ((drive = DRIVE_FindDriveRootW( name )) == -1)
{
-MESSAGE("Warning: %s not accessible from a configured DOS
drive\n", debugstr_w(*name) );
+WARN("failed to find %s as an absolute unix path mapped to
configured DOS drive \n",
+ debugstr_w(*name) );
+WARN("assuming it was a really a DOS name")
/* Assume it really was a DOS name */
drive = DRIVE_GetCurrentDrive();
}
Or something like that.
Or something like that, yeah. We want to display a hint that
there might be a misinterpretation of a DOS path as a Unix path.
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: annoyance running mingw
Dimitrie O. Paun wrote:
On February 24, 2003 12:46 am, Dan Kegel wrote:
So I wonder if Wine shouldn't be mean, and not try
so hard to understand Unix paths.
What about reversing the order: first try the DOS
path, if that fails, try the Unix one...
It is not possible to easily reverse the order in wine searches
DOSFS_GetPathDrive. If it sees a "/" then it tries to use the path as a
(absolute) unix one otherwise it just returns the current drive.
Changing this behavior is not simple and however annoying the message is
it is correct.
AFAICT this function is internal only and only called by
GetShortPathNameW. In order to change this behavior we would have to
make changes to GetShortPathNameW so that it tries the path with the
current drive first and then calls this (modified) function. After
looking at the code for the last couple of hours I'm sure it could be
done but I don't know if it is worth it.
At present I think that it would be better to change the message
{
if ((drive = DRIVE_FindDriveRootW( name )) == -1)
{
-MESSAGE("Warning: %s not accessible from a configured DOS drive\n", debugstr_w(*name) );
+WARN("failed to find %s as an absolute unix path mapped to configured DOS
drive \n",
+ debugstr_w(*name) );
+WARN("assuming it was a really a DOS name")
/* Assume it really was a DOS name */
drive = DRIVE_GetCurrentDrive();
}
Or something like that.
--
Tony Lambregts
Dsound test fails with E_NOTIMPL error
make[3]: Entre dans le répertoire `/home/wine/dlls/dsound/tests' ../../../tools/runtest -q -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c && touch dsound.ok fixme:dsound:IDirectSoundImpl_SetCooperativeLevel 0x4026c758,00010020,2):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4026c758,00010020,2):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4026c758,00010020,1):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4026c758,00010020,1):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4026c758,00010020,2):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4026c758,00010020,2):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4026c758,00010020,1):stub fixme:dsound:IDirectSoundImpl_SetCooperativeLevel (0x4026c758,00010020,1):stub fixme:wave:IDsCaptureDriverImpl_GetDriverDesc (0x4026c528,0x4026c778): stub! fixme:wave:IDsCaptureDriverImpl_Open (0x4026c528): stub! dsound.c:643: Test failed: DirectSoundCaptureCreate failed: 0x80004001 fixme:wave:IDsCaptureDriverImpl_Close (0x4026c528): stub! make[3]: *** [dsound.ok] Erreur 1 make[3]: Quitte le répertoire `/home/wine/dlls/dsound/tests' make[2]: *** [tests/__test__] Erreur 2 make[2]: Quitte le répertoire `/home/wine/dlls/dsound' make[1]: *** [dsound/__test__] Erreur 2 make[1]: Quitte le répertoire `/home/wine/dlls' make: *** [dlls/__test__] Erreur 2 = Sylvain Petreolle [EMAIL PROTECTED] Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: [OT] Re: Gentoo -> Re: gcc 3.2.2?
ALSA package are already available to add ALSA support to RedHat kernels... check http://psyche.freshrpms.net > heh, typical. Red Hat's kernel won't compile ALSA, so no RedHat > kernel for > me. too bad... This won't stop me from testing the bleeding-edge > one from > Rawhide, however, not that I expect to learn anything that isn't > already > known from this, but I'd like to see it for myself. = Sylvain Petreolle [EMAIL PROTECTED] Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: Is there some test app that reliable crashes?
On 25 Feb 2003 21:54:24 +, Mike Hearn <[EMAIL PROTECTED]> wrote: >Just run an app in winedbg, then press ctrl-c to halt it. Then do "bt" >to get a backtrace. You'll be able to move up and down the stack frames, I noticed that. :) Convinient because it is similar to gdb, but I couldn't get gdb compatibillity to work. On the website it says to add -gdb to winedbg but it complains about that. I think I can get used to it anyway. :) >inspect local variables and see the source (inside wine code). You can >also do disassembly inside closed source stuff, but I'm not elite enough >to show you how to do that. No problem with that. I was doing asm more than ten years because it is a hobby of mine. :) >Mostly wine debugging is simply a matter of looking at the logs and >doing some logical deduction. I once considered making a wine developers >beginners guide that goes through some known bugs in a release with some >free apps etc but never got around to it. If this would be a tutorial for winedbg this would be really helpfull, but I think I can get started now once that I managed to fire it and get some information out of it. :) The only thing I'm not used to is the Unix syntax for disassembling. I'm more used to the intel syntax like it is used in Windows debuggers. I once wrote a disassmebling class for myself. Would there be some interest in including that in winedbg in order to be able to switch between Intel and Unix style disasm? >may be ridiculously hard, like the current ones I'm chasing in RhymBox >which does all kinds of funky things with embeddeding IE. I can imagine that. My first goal is to get agen stable and then I think I will focus more on games. This is the area that I really miss from Windows and is the only thing that requires me to have a windows partition to keep around. Currently I don't have that much time, though, because I'm moving so it will still take some weeks until I can dig really more into wine. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)
Re: Is there some test app that reliable crashes?
> "Gerhard" == Gerhard W Gruber <[EMAIL PROTECTED]> writes: Gerhard> On Tue, 25 Feb 2003 13:45:30 -0800, Dan Kegel <[EMAIL PROTECTED]> Gerhard> wrote: >> but in practice, only the bad pointer access does. For some reason, >> raise(), assert(0), and abort() fail to trigger the debugger. >> >> You can compile this easily with mingw or msvc running under wine. >> (I did it with msvc.) Gerhard> Thanks. I have neither installed, so it would be faster for me Gerhard> to reboot. :) Anyway I just managed to fire the debugger. As I Gerhard> understood the winehq instruction I thought that winedbg will Gerhard> be fired as soon as an exception occurs, just like in windows Gerhard> when Visual Studio is installed (or any other debugger for that Gerhard> matter). But this doesn't work for me, or I missunderstood Gerhard> it. Now I tried running agent directly from within winedbg and Gerhard> this works so far. I still have to get accustomed to these Gerhard> tools, though. :) (This time with a little review before hitting the send buttom :-( ) Why not write Dan's example as a ../dll/kernel/test/xx file? No windows compiler needed. But don't make run by default :-) Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Is there some test app that reliable crashes?
> "Gerhard" == Gerhard W Gruber <[EMAIL PROTECTED]> writes: Gerhard> On Tue, 25 Feb 2003 13:45:30 -0800, Dan Kegel <[EMAIL PROTECTED]> Gerhard> wrote: >> but in practice, only the bad pointer access does. For some reason, >> raise(), assert(0), and abort() fail to trigger the debugger. >> >> You can compile this easily with mingw or msvc running under wine. >> (I did it with msvc.) Gerhard> Thanks. I have neither installed, so it would be faster for me Gerhard> to reboot. :) Anyway I just managed to fire the debugger. As I Gerhard> understood the winehq instruction I thought that winedbg will Gerhard> be fired as soon as an exception occurs, just like in windows Gerhard> when Visual Studio is installed (or any other debugger for that Gerhard> matter). But this doesn't work for me, or I missunderstood Gerhard> it. Now I tried running agent directly from within winedbg and Gerhard> this works so far. I still have to get accustomed to these Gerhard> tools, though. :) Why nor write Dan's example a ../dll/kernel/test/xx file? No windows compiler needed. But don't make run by default :-) Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: Is there some test app that reliable crashes?
Well, there are easier ways :) Just run an app in winedbg, then press ctrl-c to halt it. Then do "bt" to get a backtrace. You'll be able to move up and down the stack frames, inspect local variables and see the source (inside wine code). You can also do disassembly inside closed source stuff, but I'm not elite enough to show you how to do that. Mostly wine debugging is simply a matter of looking at the logs and doing some logical deduction. I once considered making a wine developers beginners guide that goes through some known bugs in a release with some free apps etc but never got around to it. Having said that you may hit lucky like I did and find the first bug you try and fix is relatively easy (a dud message param in my case) or it may be ridiculously hard, like the current ones I'm chasing in RhymBox which does all kinds of funky things with embeddeding IE. Just keep plugging away at it, you'll be fine :) On Tue, 2003-02-25 at 21:41, Gerhard W. Gruber wrote: > On Tue, 25 Feb 2003 13:45:30 -0800, Dan Kegel <[EMAIL PROTECTED]> wrote: > > >but in practice, only the bad pointer access does. For some reason, > >raise(), assert(0), and abort() fail to trigger the debugger. > > > >You can compile this easily with mingw or msvc running under wine. > >(I did it with msvc.) > > Thanks. I have neither installed, so it would be faster for me to reboot. :) > Anyway I just managed to fire the debugger. As I understood the winehq > instruction I thought that winedbg will be fired as soon as an exception > occurs, just like in windows when Visual Studio is installed (or any other > debugger for that matter). But this doesn't work for me, or I missunderstood > it. Now I tried running agent directly from within winedbg and this works so > far. I still have to get accustomed to these tools, though. :)
Re: Is there some test app that reliable crashes?
Gerhard W. Gruber wrote:
I need some app that will produce a crash in order to test winedbg and get
used to it. Does anybody have such an application or can tell me a quick way
how to create one?
As a naive usr, I would think each of the lines
in main of the following should do it:
#include
#include
#include
#include
int main(int argc, char **argv)
{
int *p = 0; *p = 7;
abort();
raise(SIGILL);
assert(0);
}
but in practice, only the bad pointer access does. For some reason,
raise(), assert(0), and abort() fail to trigger the debugger.
You can compile this easily with mingw or msvc running under wine.
(I did it with msvc.)
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: Is there some test app that reliable crashes?
On Tue, 25 Feb 2003 13:45:30 -0800, Dan Kegel <[EMAIL PROTECTED]> wrote: >but in practice, only the bad pointer access does. For some reason, >raise(), assert(0), and abort() fail to trigger the debugger. > >You can compile this easily with mingw or msvc running under wine. >(I did it with msvc.) Thanks. I have neither installed, so it would be faster for me to reboot. :) Anyway I just managed to fire the debugger. As I understood the winehq instruction I thought that winedbg will be fired as soon as an exception occurs, just like in windows when Visual Studio is installed (or any other debugger for that matter). But this doesn't work for me, or I missunderstood it. Now I tried running agent directly from within winedbg and this works so far. I still have to get accustomed to these tools, though. :) -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)
Is there some test app that reliable crashes?
I need some app that will produce a crash in order to test winedbg and get used to it. Does anybody have such an application or can tell me a quick way how to create one? Except booting to Windows and writing a NULL pointer access or some such. :) I installed winedbg according to the winehq instructions but when Agent crashes and I say Yes to debug it the wineserver and agent is stuck and I have to kill -9 it. Maybe this is because the output goes to the console window? I think I read something about console but I have no console as a normal user so I can't check this. -- Gerhard Gruber Für jedes menschliche Problem gibt es immer eine einfache Lösung: Klar, einleuchtend und falsch. (Henry Louis Mencken)
Middleware regression test suites, e.g. ACE
The idea of using middleware test suites to test Wine has come up before, I'm sure, but while looking for real world uses of overlapped I/O to named pipes for my named pipe conformance test, I noticed a good candidate. ACE is a set of object-oriented wrappers around operating system primitives, See http://www.cs.wustl.edu/~schmidt/ACE.html I think it's cruft (hey, it's c++ :-), but in spite of that, it is the basis of a whole lot of software, some very, very good. Ace has a largish set of regression tests which, being tests of a fairly thin OS abstraction layer, would be an almost perfect match for Wine's needs. See http://cvs.doc.wustl.edu/ace-cvs.cgi/ACE_wrappers/tests/README?rev=4.25 for more info about their regression tests. Can someone with a beefy machine and time on their hands give this a shot under Wine? Presumably you'd build everything with msvc, then run the tests under Wine. Warning: ACE is huge, and will hurt your head if you're not prepared. Wear sunglasses or something :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Re: thread safe?
Dan Kegel wrote: And a related question: is Wine SMP-safe? Will it work properly on SMP systems? - Dan I've had no known problems on my dual cpu box, so I'd assume that wine is at least supposed to be SMP-safe. since windows is threadsafe, I'd assume wine would have to be. -Dante
Re: thread safe?
Lonnie Cumberland wrote: I was wondering if someone could please tell me if Wine is thread safe? That is, I am wondering if is possible to be running multiple Windows applications under wine at the same time without much degradation of the performance of the system? And a related question: is Wine SMP-safe? Will it work properly on SMP systems? - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
thread safe?
Hello All, I was wondering if someone could please tell me if Wine is thread safe? That is, I am wondering if is possible to be running multiple Windows applications under wine at the same time without much degradation of the performance of the system? Thanks in advance, Lonnie __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/
Re: [OT] Wine 0.9 config applets?
Jaco Greeff wrote: On Saturday 22 February 2003 07:08 pm, Mike Hearn scribbled on a piece of papyrus: Last time I talked to Jaco, he was busy finding work. Hopefully he'll resurface soon, maybe he has a nice surprise for us :). Yeah, Jaco, are you there? :) Alive and kicking. Way behind, but alive. Real life has set in the past month or so and I'm only starting to re-surface at this point. Somewhere between needing to put food on the table and having a new small dog things just drops on the floor.*sigh* Add some HW troubles to this and I'll need to see where I am at this point. (I just damn well hope I have recent backups...) Well, I know my Win2K install is borked, along with my MDK 9.0 install (9.1RC1 seems fine but won't do for wine) been too scared to look for data that might have gone missing... Jaco-not-having-aloverly-time Hope your not-loverly-time improves! In the mean time I am pondering on the difference between a new small dog and a small new dog. Did you previously have a small dog (your old small dog) and a large one and replace the little one? OK, I'll stop talking nonsense now... :-) It's been a long day at work. David
Re: Wine 0.9 config applets?
On Saturday 22 February 2003 07:08 pm, Mike Hearn scribbled on a piece of papyrus: > > Last time I talked to Jaco, he was busy finding work. Hopefully he'll > > resurface soon, maybe he has a nice surprise for us :). > > Yeah, Jaco, are you there? :) Alive and kicking. Way behind, but alive. Real life has set in the past month or so and I'm only starting to re-surface at this point. Somewhere between needing to put food on the table and having a new small dog things just drops on the floor.*sigh* Add some HW troubles to this and I'll need to see where I am at this point. (I just damn well hope I have recent backups...) Well, I know my Win2K install is borked, along with my MDK 9.0 install (9.1RC1 seems fine but won't do for wine) been too scared to look for data that might have gone missing... Jaco-not-having-aloverly-time
Re: MoveFileW bug?
Hi Roderick, At 14.32 25/02/2003 +0100, Roderick Colenbrander wrote: [...] "The MoveFile function will move (rename) either a file or a directory (including its children) either in the same directory or across directories. The one caveat is that the MoveFile function will fail on directory moves when the destination is on a different volume." The update tool is using something like this: MoveFileW(steam.exe, e:\\steam.exe) If I read it right, MSDN says that you cannot move a *directory* between volumes, not a single file (like in this case). So, the check should be done only when the source path points to a directory. Alberto So it tries to move a file from c:\steam\steam.exe to e:\steam.exe which according to the MSDN docs is not possible. The same works fine on Win2k. After hacking MoveFileW to not check if the volumes are different it worked fine on Wine too. What shall we do? Shall we implement the same bugs Windows is doing or shall e listen to the docs at MSDN? (I'm sure some tests need to be made) Roderick Colenbrander
Re: Retiring...for now
good luck and see you soon... = Sylvain Petreolle [EMAIL PROTECTED] Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
Re: using-ms-vcpp-with-gnu-win article
Hi Dan Kegel wrote: Eric Pouech wrote: - the console creation at wcmd startup should we removed when run under wineconsole (but, this would be rather annoying for some users). I have a patch for this, but it would mean that there are two ways of running wcmd: 'wineconsole wcmd /switch_for_no_new_console' or 'wcmd' (for using a brand new console) Shall I scream again? We *really* need a way of running wcmd in an existing terminal, with *no* X stuff going on at all until the app requests it. Windows doesn't pop up a new window for wcmd by default, and we shouldn't either. - Dan I tried ttyterm or whatever its called instead of x11drv in "config", that did not work though. I would also like to try this below, but its not quite working, could anyone offer some sugestions please? Apparently because this calls cl with many source files it is quicker than using nmake. However, it will not run for me. $ cd chaos-src/iainlib $ wine -- d:\\vs\\common\\msdev98\\bin\\msdev.exe iainlib.dsp /MAKE fixme:ole:CoRegisterMessageFilter stub fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid err:ole:TLB_ReadTypeLib Loading of typelib L"D:\\vs\\common\\msdev98\\bin\\devprj.pkg" failed with error 0 fixme:process:SetProcessWorkingSetSize (0x,-1,-1): stub - harmless I need em.dll, but it is in the dir. msdev-log-1 shows this. D:\\vs\\common\\msdev98\\bin\\devprj.pkg does exist, so I do not know what this error is for. It is an MZ DLL though. I also had to use win2k msvcrt.dll instead of my win98se dll I used to run nmake and cl. running msdev.exe on its own opens the GUI (with one error about em.dll, but then procedes to load anyway!) When a dialog with "d:\chaos-src\iainlib\iainlib.dsw File not found" is displayed the log says: fixme:commdlg:GetFileName95 Flags 0x0082 not yet implemented msdev-log-2 Adding msvcp60.dll to the bin dir, stopped many errors, but still the program would not build from gui, or command line. Maybe the logs attatched offer some clues. Cheers JG [EMAIL PROTECTED] iainlib]$ wine -- d:\\vs\\common\\msdev98\\bin\\msdev.exe fixme:ole:CoRegisterMessageFilter stub fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign constructor/destructor memid fixme:ole:MSFT_DoTypeInfo Assign con
Re: using-ms-vcpp-with-gnu-win article
Hi, Eric Pouech wrote: Dan Kegel wrote: http://codingstyle.com/articles/using-ms-vcpp-with-gnu-wine.html was just mentioned at http://developers.slashdot.org/developers/03/02/23/1939225.shtml?tid=156 Yup, I've been doing this, and the author is right: the commandline tools show off a few rough edges of Wine. As more people start using them, maybe we'll get them smoothed off (e.g. my fix to wcmd the other day to keep it from stripping off switches too zealously)... if I look at the issues: - filename conversion (including #include to lowercase) => wine maker handles this Although wine supports this, it was bad coding that created this problem, so wine is not at fault here. - passing file names on command line (DOS vs UNIX paths) => wine requires DOS paths to work in all cases - inheriting in wine environment vars from DOS => either convert them as Unix vars, or use the yet to be committed autoexec.wine in wcmd This would be good to have. Also [Enviroment Variables] in ~/.wine/config would be better IMO. - compilation time: maybe linked to process startup (I don't see a need of lots of synchronization issues in cl.exe, but who knows) http://www.winehq.org/news/old/2001-11.html#1 Has there been much progress regarding this file access speedup? This most likely imacted my results results. - complaints on wcmd (which in fact apply to wineconsole) are mostly fixed (patches are committed, need to be applied) (=> size modification, clipboard corruptions) - the console creation at wcmd startup should we removed when run under wineconsole (but, this would be rather annoying for some users). I have a patch for this, but it would mean that there are two ways of running wcmd: 'wineconsole wcmd /switch_for_no_new_console' or 'wcmd' (for using a brand new console) - TRACE messages while running cl => does someone have a copy of those ? In my only "SetConsoleCtrlHandler" fixme atm. [EMAIL PROTECTED] iainlib]$ wine -- d:\\vs\\vc98\\bin\\nmake.exe /fiainlib.mak fixme:console:SetConsoleCtrlHandler (0x780109f8,1) - no error checking or testing yet Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. No configuration specified. Defaulting to iainlib - Win32 Debug. cl.exe /nologo /MLd /W3 /GX /Z7 /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /Fp".\Debug\iainlib.pch" /YX /Fo".\Debug\\" /Fd".\Debug\\" /FD /c .\c\app.c fixme:console:SetConsoleCtrlHandler (0x4062f6,1) - no error checking or testing yet app.c cl.exe /nologo /MLd /W3 /GX /Z7 /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /Fp".\Debug\iainlib.pch" /YX /Fo".\Debug\\" /Fd".\Debug\\" /FD /c .\c\appname.c fixme:console:SetConsoleCtrlHandler (0x4062f6,1) - no error checking or testing yet appname.c cl.exe /nologo /MLd /W3 /GX /Z7 /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /Fp".\Debug\iainlib.pch" /YX /Fo".\Debug\\" /Fd".\Debug\\" /FD /c .\c\callswis.c fixme:console:SetConsoleCtrlHandler (0x4062f6,1) - no error checking or testing yet callswis.c cl.exe /nologo /MLd /W3 /GX /Z7 /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /Fp".\Debug\iainlib.pch" /YX /Fo".\Debug\\" /Fd".\Debug\\" /FD /c .\cpp\winmisc.cpp fixme:console:SetConsoleCtrlHandler (0x4062f6,1) - no error checking or testing yet winmisc.cpp link.exe -lib @E:\nma11720. fixme:console:SetConsoleCtrlHandler (0x40d860,1) - no error checking or testing yet - msvcrt lookup (native/builtin) => fixed in CVS so, I don't think the situation is so bad: - a bunch of real bugs, which have been mostly fixed - a need for a bit more of documentation for this type of needs Agreed, Wine is great for this sort of stuff! Cheers JG
Re: MoveFileW bug?
> "Roderick" == Roderick Colenbrander <[EMAIL PROTECTED]> writes: Roderick> Wait a second. It seems I didn't read the MSDN info well Roderick> enough. It seems directory copies across multiple volumes Roderick> aren't allowed, but file copies are. (my fault). Roderick> Will submit a bugfix soon. Submitting a test case for dlls/kernel/test is appreciated. Bye -- Uwe Bonnes[EMAIL PROTECTED] Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt - Tel. 06151 162516 Fax. 06151 164321 --
Re: MoveFileW bug?
Wait a second. It seems I didn't read the MSDN info well enough. It seems directory copies across multiple volumes aren't allowed, but file copies are. (my fault). Will submit a bugfix soon. On Tuesday 25 February 2003 14:32, Roderick Colenbrander wrote: > Hi, > > Today someone asked me to look at some Wine problems when running a gaming > app called "Steam". Because I wasn't using the latest version of the app, > the program tried to update itself. During the update process the main > program (steam.exe) needs to be replaced by a new version. To do this the > old program exits and another executable is being launched. The new process > tries to backup the old steam.exe to wine's temp drive to restore it in > case something goes wrong. Here the real problem appears. After > "moving/renaming" the file the update tool gives an error stating that > steam.exe still exists. > > After looking at the debug output I saw that to move the file the update > tool is using MoveFileW. Normally nothing is wrong with this but according > to MSDN > (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/ba >se/movefile.asp) it can be used for about everything except for the > following: > > "The MoveFile function will move (rename) either a file or a directory > (including its children) either in the same directory or across > directories. The one caveat is that the MoveFile function will fail on > directory moves when the destination is on a different volume." > > The update tool is using something like this: MoveFileW(steam.exe, > e:\\steam.exe) > > So it tries to move a file from c:\steam\steam.exe to e:\steam.exe which > according to the MSDN docs is not possible. The same works fine on Win2k. > After hacking MoveFileW to not check if the volumes are different it worked > fine on Wine too. > > What shall we do? Shall we implement the same bugs Windows is doing or > shall e listen to the docs at MSDN? (I'm sure some tests need to be made) > > Roderick Colenbrander
Re: Wine 0.9 config applets?
On February 25, 2003 06:50 am, Jaco Greeff wrote: > Alive and kicking. Cool -- long time, no see! > [...] having a new small dog things just drops on the floor.*sigh* Yeah, I know, it happens when they are small :))) > Add some HW troubles to this and I'll need to see where I am at this point. > (I just damn well hope I have recent backups...) Well, I know my Win2K > install is borked, along with my MDK 9.0 install (9.1RC1 seems fine but > won't do for wine) been too scared to look for data that might have gone > missing... Ugh! That's why it's better to submit what you have early, and let WineHQ mirror it. Remember: "Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it ;)" -- Linus Torvalds, after his hard disk failed :))) -- Dimi.
MoveFileW bug?
Hi, Today someone asked me to look at some Wine problems when running a gaming app called "Steam". Because I wasn't using the latest version of the app, the program tried to update itself. During the update process the main program (steam.exe) needs to be replaced by a new version. To do this the old program exits and another executable is being launched. The new process tries to backup the old steam.exe to wine's temp drive to restore it in case something goes wrong. Here the real problem appears. After "moving/renaming" the file the update tool gives an error stating that steam.exe still exists. After looking at the debug output I saw that to move the file the update tool is using MoveFileW. Normally nothing is wrong with this but according to MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/movefile.asp) it can be used for about everything except for the following: "The MoveFile function will move (rename) either a file or a directory (including its children) either in the same directory or across directories. The one caveat is that the MoveFile function will fail on directory moves when the destination is on a different volume." The update tool is using something like this: MoveFileW(steam.exe, e:\\steam.exe) So it tries to move a file from c:\steam\steam.exe to e:\steam.exe which according to the MSDN docs is not possible. The same works fine on Win2k. After hacking MoveFileW to not check if the volumes are different it worked fine on Wine too. What shall we do? Shall we implement the same bugs Windows is doing or shall e listen to the docs at MSDN? (I'm sure some tests need to be made) Roderick Colenbrander
[Fwd: Re: GDI question]
-Forwarded Message- From: James Chaldecott <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: GDI question Date: 25 Feb 2003 09:32:48 + Mike, I'm a Win32 developer, and I take a look at WineHQ every so often and I noticed this thread. I don't know what Wine performance is like, but I thought you might be interested to know that some Windows graphics drivers (particularly Nvidia) are also very slow doing off-screen BitBlt operations under some circumstances. BitBlt'ing between two memory DC's seems to get very slow if the "acceleration level" is set to "Full" (the default) in the driver. I'm guessing they are, in fact, trying to overoptimize and they assume that at least one of the DC's is a real device (i.e. already in video memory), although I don't really know. We have the problem with our software and found the easy way to overcome it was to drop the driver acceleration factor a notch! I also spotted a bug in Mozilla's Bugzilla DB, and did some profiling for them. http://bugzilla.mozilla.org/show_bug.cgi?id=170272 Anyway, I thought you might be interested. I suppose it means that lots of the BitBlt's being done *are* being accelerated by the hardware, and this is a corner case were performance degrades. James Chaldecott P.S. Feel free to post this to the list if it's interesting, but I don't subscribe, ATM. >Well, I just tried a simple comparison of the Adobe SVG plugin under >Wine and IE6 on Windows XP. Wine _is_ slower by a visible amount when >doing repeated bitblts such as the plugin does on an animation I have, >but it's certainly not something that'd actually affect real world >usage. I don't think GDI performance is really an issue at present, most >apps don't do these kind of repeated double-buffer switches (i assume >flash doesn't actually use the gdi to render into its backbuffer?) so it >only affects apps like photoshop and director/flash. > >In particular when I run the SVG plugin, I can see a FIXME talking about >a potential optimization, so really the issue is just a case of elbow >grease for optimizations (esp in bitblt) rather than a rewrite I'd guess. > -- Mike Hearn <[EMAIL PROTECTED]> QinetiQ - Malvern Technology Center
Re: Was reading through the newest news and wondered about Transgaming'sfix.
I found a patch which I think was from them, and applied it to the cvs to try it out, it compiled OK but failed on startup and I haven't investigated it. David Mike Hearn wrote: I don't think anybody has a fix yet. The work TransGaming contributed was prototype code for using pthreads on non-x86 platforms iirc, it may well prove useful in the upcoming port to pthreads, but it's not a total solution On Mon, 2003-02-24 at 06:40, Joe Millenbach wrote: Did I read that correctly, in that they fixed whatever issues Wine has with glibc 2.3? So that issue with threads being different would be fixed with this? And if the above is true then are they planning to submit this to the Wine project or is this only for thier version? Thanks for your time, Joe Millenbach _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
Re: Was reading through the newest news and wondered aboutTransgaming's fix.
I don't think anybody has a fix yet. The work TransGaming contributed was prototype code for using pthreads on non-x86 platforms iirc, it may well prove useful in the upcoming port to pthreads, but it's not a total solution On Mon, 2003-02-24 at 06:40, Joe Millenbach wrote: > Did I read that correctly, in that they fixed whatever issues Wine has with > glibc 2.3? So that issue with threads being different would be fixed with > this? > > And if the above is true then are they planning to submit this to the Wine > project or is this only for thier version? > > Thanks for your time, > Joe Millenbach > > _ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus > -- Mike Hearn <[EMAIL PROTECTED]> QinetiQ - Malvern Technology Center
Re: Retiring...for now
> Anyways, It's been fun; anyone that wants to take over my bugs on > bugs.winehq.com may do so, anyone that wants to take over any of my > other tasks (User's Guide, etc) may do so as well, but save a spot for > in case I ever find a way to get back here.. May you all have much > luck in your journeys and I hope to see you all again someday... Good luck Dustin, your contributions will be missed keep on truckin' -mike
