This one could have a configure check but I havent had the time to learn
How to properly write one and mingw is the only platform I know of that
doesn't
have ftruncate support. If anyone has the time and wants to help I have
about
4 or 5 things I need ./conf checks written for.
Changlog: Added ftruncate support for makedep on MingW32
cvs diff -u makedep.c
Index: makedep.c
===================================================================
RCS file: /home/wine/wine/tools/makedep.c,v
…
[View More]retrieving revision 1.10
diff -u -r1.10 makedep.c
--- makedep.c 10 Mar 2002 00:24:22 -0000 1.10
+++ makedep.c 25 Apr 2002 01:42:50 -0000
@@ -24,6 +24,10 @@
#include <string.h>
#include <unistd.h>
+#ifdef _MINGW_ /* Taken from GLib */
+#define ftruncate(fd, size)
+#endif
+
/* Max first-level includes per file */
#define MAX_INCLUDES 200
[View Less]
> -----Original Message-----
> From: Alexandre Julliard julliard(a)winehq.com {WineHQ-devel}
> Version checks are a bad idea because this is not how Wine is
> implemented. For instance GetLongPathName under Wine doesn't try to
> fail if you are running with -winver win95, it just works. Adding
> version checks in the tests just means that some functions won't get
> tested if you run with the wrong version.
>
> The right way is to always call the function no matter …
[View More]the version,
> and check that the call either succeeds as expected, or fails in the
> way that it's supposed to fail on a platform that doesn't support it.
The problem I forsee with this is that it makes writing tests a bit tricky
for functions that behave differently on different platforms (i.e. defining
the failure conditions correctly). Otherwise, it is a good thing to strive
for.
I'll try to modify the tests I've written to behave in this manner, and see
how much work it is. Unfortunately, it is somewhat difficult, since I don't
(in general) have access to the platforms which don't support the functions.
So I can write tests that pass on Win2k, Win98, and wine, but as soon as
someone runs it on win95 or nt4.0, it will likely fail (since I have no idea
what the failure mechanism will be on these platforms, and thus can't gaurd
against it) until someone can provide enough feedback to allow the test to
be fixed.
My assumption has always been: Make the function work correctly on Windows,
and then add todo's to support wine. Thus I've put the effort in upfront to
catch errors when the application runs on an MS OS. It sounds to me that
you are proposing a more wine-centric testing base (make the tests work in
Wine, and fix problems encountered in Windows as they pop up...or be a lot
more knowledgeable than me at how Windows is supposed to behave). So far I
have written all my tests based purely on the MSDN spec, and then tweaked
them when an OS behaves differently than documented. If I don't use
OS-specific checks, I just feel like I'm leaving a known whole in my test if
I don't account for the the cases which are documented not to work (and
which I don't know how they will behave).
For instance the thread.c test that I wrote makes (some) checks for access
control, which only work on win2k+. The way I wrote the test, it just
worked in win98 when I finally got around to testing it. Had I just
executed the checks, I would have had no idea how Win98 would behave
(hopefully with a nice SetError, but god only knows), and the test would
certainly have failed on win98 until I was able to try it and figure out how
it dealt with this unsupported functionality.
Lastly, what is the recomendation for dealing with cases like this:
lstrcpyA(tmpstr,"aaaaaaaa");
len1=GetTempPathA(len,tmpstr); /*this should fail because len is too small
*/
ok(len1==len+1,
"GetTempPathA should return string length %d instead of
%d",len+1,len1);
if(WIN2K_PLUS(version)) {
/* in Win2k, the path won't be modified, but in win98, wine it is */
todo_wine {
ok(lstrcmpiA(tmpstr,"aaaaaaaa")==0,
"GetTempPathA should not have modified the buffer");
}
}
One answer is not to test this, since it is not documented what the result
will be, but the OSes certainly behave differently, and it is possible that
some program takes advantage of this. I'm sure there are other similar
cases, and I'd like to know (in general) what the right solution will be.
I'm probably making a mountain out of a molehill, and I'll just try
modifying my tests to work the way Alexandre proposes. I'm just afraid this
is setting additonal obstacles for (non Wine) developers to write regression
tests.
Thanks,
.Geoff
[View Less]
On Wednesday 24 Apr 2002 7:51 pm, you wrote:
> --- Michael Wetherell <mike.wetherell(a)ntlworld.com>
>
> wrote:
> > Yes I know cygpath, winepath is intended to be a
> > kind of Wine version of the
> > same thing.
> >
> > The programs aren't interchangeable though, cygpath
> > knows about Cygwin's
> > mount points while winepath knows about Wine's DOS
> > drives.
>
> Agree. Thought you may not know about cygpath and this
> …
[View More]information will be interesting for you.
>
> Andiry
>
Yes thanks, it was interesting, many options.
Mike
[View Less]
Hi,
Starting a program with:
wine --winver win2k --debugmsg -relay,+x11drv,+snoop+dll iyp022.exe
(the same error occurs with --winver win98/win95)
gives me the folowing error:
x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config
file
fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet.
err:ntdll:RtlpWaitForCriticalSection section 0x400f164c "module.c:
loader_section" wait timed out, retrying (60 sec) fs=021f
wine: Unhandled exception, starting debugger...
…
[View More]x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config
file
err:ntdll:RtlpWaitForCriticalSection section 0x400f164c "module.c:
loader_section" wait timed out, retrying (60 sec) fs=021f
err:win:WIN_FindWndPtr window 30021 belongs to other process
err:win:WIN_FindWndPtr window 30021 belongs to other process
In the debbuger windows I have some debug msgs that the debbuger is trying
to
load and at the end it shows this message:
Unhandled exception: wait failed on critical section 0x400f164c
(loader_section in libntdll.dll.so)
First chance exception: wait failed on critical section 0x400f164c
(loader_section in libntdll.dll.so)
and this message keeps repeating.
How can I solve this?
Already tryed with native ntdll.dll and it doesn't work.
The program runs OK under Windows.
Another problem I'm having is that if I don't specify --winver
it doesn't work at all. Is it right?
Thanks,
Ricardo.
[View Less]
Hi,
Found attached bug. Curiously, the test doesn't fail even if wine is
pretending to be Windows 95 :)
ChangeLog:
Fixed typo "Major" -> "Minor"
BTW,
After the patch, the test for WIN98 or later is:
#define WIN98_PLUS(version) (version.dwMajorVersion==4 && \
version.dwMinorVersion>0)
but, MS's documentation:
http://msdn.microsoft.com/library/en-us/sysinfo/sysinfo_49iw.asp
suggests something more like:
#define WIN98_PLUS(version) \
( (…
[View More]version.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS) && \
( (version.dwMajorVersion > 4) || \
(version.dwMajorVersion==4 && version.dwMinorVersion>0)))
Is this more correct?
----
Paul Millar
[View Less]
> -----Original Message-----
> From: Paul Millar paulm(a)astro.gla.ac.uk {WineHQ-devel}
> ...
> > Perhaps it would be best to make a test.h somewhere
> > and put all of these kind of definitions someplace so we
> don't need to
> > redefine them for each test.
>
> Hmmm, was there an email about that a while ago? I thought Alexandre
> wasn't happy with the idea, but I can't remember why...
>
I looked through the archives again, and couldn't find …
[View More]this topic having
been discussed before. In any case, there is already wine/test.h, so I
think adding some defines in there should be ok (I don't have a copy in
front of me, so maybe it's not exactly the right place). If I don't see any
further activity on this thread, I'll just stick the required defines in
there next time I submit a test, and see if anyone complains.
.Geoff
[View Less]
Greatings
I have some application qhen use the comm.c:TransmitCommChar function, but this function are not implemented.
anybody have one ideia to me go around this problem...?
thaks and sorry per my litle english
Marcelo Welter
Hi everybody,
I'm currently very interested by porting some of the Wine tech.on PPC.
I've been looking for people interested in this kind of painful duty but
I didn't see anybody carrying this type of idea anywhere on the Web.
I've already mailed some people on that subject and someone told me some
people were trying to port WineLib on Sparc (Ulrich Weigand for
instance...). Does anybody of you have more information on that ? Did
somebody did that somewhere on the globe?
Besides that, to …
[View More]achieve my binary compatibility, I was looking at the
Bochs emulation. Of course, I'm currently affected by some messages on
the web saying the performances are not that great. I have nothing
against emulation of machines but I only want to know of it is possible
to port the Bochs on my Linux PPC and what performances can I expect
(aren't there any benches to help me make my decision ?). Someone said
that with a PIII 933, one can reach 3.5MIPS. Who can tell me success
stories on that before I start working ?
Yann K.
[View Less]