Re: [PATCH] Add test case to user32 winetests for edit control context menu. Try 2

Michael Martin wrote: This patch adds test for edit control clipboard context menu. The test passes on Windows XP as the WM_COMMAND message is not sent to the edit control by its context menu. Fails on wine because wine does incorrectly send that message. This problem shows up using the edit cl

Re: [PATCH] Add test case to user32 winetests for edit control contextmenu.

"Michael Martin" wrote: +WNDPROC editWndProc; Should be static. +static INT_PTR CALLBACK edit_control_wndproc(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) INT_PTR is wrong return type for a window proc. +{ +static int timerCount = 0; +HGLOBAL cbData; +LPTSTR lptStrCop

winetests running on win98, qemu

Hello, I installed windows 98 inside qemu (couldn't get windows xp working) It seems there are a lot of problems, ending with a crash somewhere in msacm (the last line in the created temporary file says acmDriverDetails failed) should I do something? install ie6 & windows updates ? something

Re: winetests/winrash

Hi, On Thu, Jul 29, 2004 at 12:05:08PM +0200, Rolf Kalbermatter wrote: > Chris Morgan <[EMAIL PROTECTED]> wrote: > > >I wouldn't mind adding a systray icon. I wasn't really sure how that was > >supposed to be done. I tried having the service add a systray icon without > >much success, I don't

Re: winetests/winrash

Chris Morgan <[EMAIL PROTECTED]> wrote: >I wouldn't mind adding a systray icon. I wasn't really sure how that was >supposed to be done. I tried having the service add a systray icon without >much success, I don't believe services can interact with the desktop. That >may mean that a separate w

Re: winetests/winrash

The winetests are testing windows behavior. Ideally they should all pass on wine and under windows. Winrash runs these winetests. It gets a script file from a script on winehq.org that creates the script based on the current version of winrash and the winetests that the client has already

winetests/winrash

What is it exactly that winrash does? Is it running winetests using the native libraries of the Windows operating system that the user is running the tests on, or are the wine libraries being tested through some means? Is there a site where this information is readily available? I have one

Re: slight trouble running winetests under windows

Hans Leidekker <[EMAIL PROTECTED]> writes: > I explored that possibility some time ago. Moving to dlls/ implies > using a spec file, because I don't think we want to use anything other > than a standard Makefile under dlls/, right? This puzzled me since > uuids are not functions and although spec

Re: slight trouble running winetests under windows

On Wednesday 14 January 2004 22:52, Alexandre Julliard wrote: > > Looks like a solution to me. What about dxguid? Should we split > > uuid up by creating a seperate directory with Makefile etc. or > > will a symlink to libuuid do? > > I think we should create a separate library. I'm also wondering

Re: slight trouble running winetests under windows

Hans Leidekker <[EMAIL PROTECTED]> writes: > Looks like a solution to me. What about dxguid? Should we split > uuid up by creating a seperate directory with Makefile etc. or > will a symlink to libuuid do? I think we should create a separate library. I'm also wondering if we shouldn't move them

Re: slight trouble running winetests under windows

On January 13, 2004 08:06 pm, Alexandre Julliard wrote: > The main problem is that winegcc only knows about gcc, and we want > Wine to build with other compilers too. So no, we can't use it yet. Good point. Situation is not too bad though. Wine source is not gcc specific, so we can invoke whatever

Re: slight trouble running winetests under windows

On Tuesday 13 January 2004 20:33, Alexandre Julliard wrote: > this doesn't help. A possibility could be to rename the library to > libuuid but install it in /usr/lib/wine to avoid conflicts. This will > require winegcc and winemaker to set the correct library path, but > they already have to do th

Re: slight trouble running winetests under windows

It doesn't show up in the object/library modules list, maybe something is wrong there? Chris On Tuesday 13 January 2004 07:33 pm, Francois Gouget wrote: > On Tue, 13 Jan 2004 [EMAIL PROTECTED] wrote: > [...] > > > Ahh yes, this appears to be the issue. If I go to "project > > settings->link->o

Re: slight trouble running winetests under windows

Mike Hearn <[EMAIL PROTECTED]> writes: > On Tue, 13 Jan 2004 11:33:25 -0800, Alexandre Julliard wrote: >> The current problem is that Wine itself is not built with winegcc so >> this doesn't help. A possibility could be to rename the library to >> libuuid but install it in /usr/lib/wine to avoid c

Re: slight trouble running winetests under windows

"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > Right. For some reason I've read winetest and understook winemaker :) > Sorry for the confusion. But we could build the tests with winegcc > right now, no? And programs/* as well. We can't deal with DLLs in > winegcc, I'm a lazy bum, I admit :/ The

Re: Re: slight trouble running winetests under windows

On Tue, 13 Jan 2004 [EMAIL PROTECTED] wrote: [...] > Ahh yes, this appears to be the issue. If I go to "project > settings->link->object/library modules" and add "uuid.lib" to the list > then the test compiles without many other issues. Shouldn't the > script be adding this to the .dsp/.dsw? Tha

Re: slight trouble running winetests under windows

On Tue, 13 Jan 2004 11:33:25 -0800, Alexandre Julliard wrote: > The current problem is that Wine itself is not built with winegcc so > this doesn't help. A possibility could be to rename the library to > libuuid but install it in /usr/lib/wine to avoid conflicts. This will > require winegcc and win

Re: slight trouble running winetests under windows

On Tue, 13 Jan 2004, Alexandre Julliard wrote: > The current problem is that Wine itself is not built with winegcc so > this doesn't help. Right. For some reason I've read winetest and understook winemaker :) Sorry for the confusion. But we could build the tests with winegcc right now, no? And p

Re: Re: slight trouble running winetests under windows

gt; Date: 2004/01/13 Tue AM 05:20:29 EST > To: wine-devel <[EMAIL PROTECTED]> > CC: Chris Morgan <[EMAIL PROTECTED]> > Subject: Re: slight trouble running winetests under windows > > On Tuesday 13 January 2004 05:47, Chris Morgan wrote: > > > I'm trying to ge

Re: slight trouble running winetests under windows

"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > The way it should work is the following: > -- winemaker generates MinGW compatible Makefiles. In it, it > uses -luuid and -ldxguid to link to these things. > -- on MinGW, this will work just fine > -- under Wine, winegcc will translate th

Re: slight trouble running winetests under windows

On Tue, 13 Jan 2004, Dimitrie O. Paun wrote: > On Tue, 13 Jan 2004, Francois Gouget wrote: > > > this particular problem. However this should let msvcmaker generate the > > right set of import libraries (currently it hard-codes the list of .lib > > files to link to, including uuid.lib but not dxgu

Re: slight trouble running winetests under windows

On Tue, 13 Jan 2004, Francois Gouget wrote: > this particular problem. However this should let msvcmaker generate the > right set of import libraries (currently it hard-codes the list of .lib > files to link to, including uuid.lib but not dxguid.lib). > > For MinGW it would be harder though. This

Re: slight trouble running winetests under windows

On Tue, 13 Jan 2004, Hans Leidekker wrote: [...] > Let's see if I can sum up the issues. In Wine uuids are put in > a lib called libwine_uuid. It's called like that because a > libuuid already exists. Second thing is that in MinGW and MSVC > there are two separate libraries with uuids, uuid and dxg

Re: slight trouble running winetests under windows

On Tuesday 13 January 2004 05:47, Chris Morgan wrote: > I'm trying to get some of the wine tests compiling and running under > windows, oleaut32 test specifically. I've got the project file built and > everything opens fine under visual studio 6. The only issue is that during > linking of the ol

slight trouble running winetests under windows

I'm trying to get some of the wine tests compiling and running under windows, oleaut32 test specifically. I've got the project file built and everything opens fine under visual studio 6. The only issue is that during linking of the oleaut32 tests _IID_IFont is undefined. Oddly enough if I swi

Re: new old winetests

David Laight <[EMAIL PROTECTED]> writes: > Just tell the Solaris user to put /usr/xpg4/bin on $PATH > before /usr/bin. Then 'sh' will be 'ksh' and posix > compliant... We are talking about #!/bin/sh now. $PATH is out of consideration here, I'm afraid. Feri.

Re: new old winetests

is case. And don't tell me the performance story, it's just BS in this case (in fact, I'll bet you can't measure _any_ significant difference between the build times of winetests with and without 'expr'). -- Dimi.

Re: new old winetests

On Sat, Dec 20, 2003 at 08:57:29PM +0100, Ferenc Wagner wrote: > David Laight <[EMAIL PROTECTED]> writes: > > >> BTW, there's no need to make the script bash specific, > >> we can use expr instead: > >> > >> -i=$(($i+1)) > >> +i=`expr $i + 1` > > > > That isn't a bashism, it is required t

Re: new old winetests

David Laight <[EMAIL PROTECTED]> writes: >> BTW, there's no need to make the script bash specific, >> we can use expr instead: >> >> -i=$(($i+1)) >> +i=`expr $i + 1` > > That isn't a bashism, it is required to be supported by > any shell that claims to be Posix compliant. That > probably

Re: winetests

On December 3, 2003 05:08 pm, Tom wrote: > Should we just look win98 onwards? and put win95/3.1 > in the past as it very well deserves to be? I think we can support win95 just fine for now. Win31 was never in our plans however... -- Dimi.

winetests

Michael Stefaniuc wrote: Dimitrie O. Paun wrote: On December 2, 2003 11:10 am, Brian Vincent (C) wrote: It came out shortly after as an add-on and was likely first included in OSR2. Not a big deal, we'd be hard pressed to find a Win95 pre OSR2 system these days anyway. We can live with it. Hi,

Re: new old winetests

Dimitrie O. Paun wrote: On December 2, 2003 11:10 am, Brian Vincent (C) wrote: It came out shortly after as an add-on and was likely first included in OSR2. Not a big deal, we'd be hard pressed to find a Win95 pre OSR2 system these days anyway. We can live with it. Well, i have one at home :). I

Re: new old winetests

On Wed, 3 Dec 2003, Ferenc Wagner wrote: [...] > Sure, we need very basic functionality only: socket, > connect, send and recv for TCP streams. It's just I didn't > find any documentation on it. Can you recommend something? > Or just change the version to MAKEWORD(1,1), don't #include > and link

Re: new old winetests

Francois Gouget <[EMAIL PROTECTED]> writes: > On Wed, 3 Dec 2003, Dimitrie O. Paun wrote: > >> On December 2, 2003 11:10 am, Brian Vincent (C) wrote: >> >>> It came out shortly after as an add-on and was likely >>> first included in OSR2. >> >> Not a big deal, we'd be hard pressed to find a Win95

Re: new old winetests

On Wed, 3 Dec 2003, Dimitrie O. Paun wrote: > On December 2, 2003 11:10 am, Brian Vincent (C) wrote: > > It came out shortly after as an add-on and > > was likely first included in OSR2. > > Not a big deal, we'd be hard pressed to find a Win95 > pre OSR2 system these days anyway. We can live with

Re: new old winetests

On December 2, 2003 11:10 am, Brian Vincent (C) wrote: > It came out shortly after as an add-on and > was likely first included in OSR2. Not a big deal, we'd be hard pressed to find a Win95 pre OSR2 system these days anyway. We can live with it. -- Dimi.

Re: new old winetests

"Brian Vincent (C)" <[EMAIL PROTECTED]> writes: >>> -- we're linking against ws2_32 >>> Is this DLL available on all versions of Windows we >>> want to run on? >> >> As far I know >> >> yes. > >

Re: new old winetests

Title: Re: new old winetests >>   -- we're linking against ws2_32 >>  Is this DLL available on all versions of Windows we >>  want to run on? > >As far I know ><http://msdn.microsoft.com/library/en-us/winsock/winsock/windows_sockets_start_page_2.as

Re: new old winetests

that's here to make it possible to do a > quick check under Windows when you modify a test. I don't really see > the same need for winetests, so I'd suggest we do things the clean way > first. If it turns out we really need the hack we can always add it > later. Sure, we

Re: new old winetests

the first place. It's convenient, but a bit > ugly (and I guess it survives since it's so small). However, > as you pointed out, if we do use it for tests, why not for > winetests, it fits in the same category, it's convenient, and > we can use it almost as is (this is

Re: new old winetests

#x27;s OK then. We need to depend on _something_ to send out the results, this seems like a decent dependency. > > > I can't see any showstoppers > > Good to you. :) What do you think about Alexandre's cross- > configuring idea? Well, it's a clean idea. The CRO

Re: new old winetests

"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > -- the mkdir() issue is still not 100% solved. We currently have: > #ifndef _WIN32 > # define mkdir(d) mkdir (d, 0777) > #endif > [...] Why don't we just link with msvcrt? "Dimitrie O. Paun" <[EMAIL PROTECTED]> also wrote: > "Doctor, it hu

Re: new old winetests

On November 25, 2003 02:53 pm, Ferenc Wagner wrote: > State of affairs attached. I didn't use popen() because Wine > doesn't support it. OK, This looks a lot cleaner. Very, very nice! There are still a few nits, but I think it should go in so we can send small incremental patches. Here are the f

Re: new old winetests

Alexandre Julliard <[EMAIL PROTECTED]> writes: > Ferenc Wagner <[EMAIL PROTECTED]> writes: > >> #ifdef _WIN32 >> # include >> # include >> #else >> # include "config.h" >> # include "wine/port.h" >> # define mkdir(d) mkdir (d, 0777) >> #endif > > I'm not sure why you don't want to use the n

Re: new old winetests

Ferenc Wagner <[EMAIL PROTECTED]> writes: > Is not > > #ifdef _WIN32 > # include > # include > #else > # include "config.h" > # include "wine/port.h" > # define mkdir(d) mkdir (d, 0777) > #endif > > an acceptable workaround? This should be compilable even > with MSVC after all, and Dimi ha

More spare time = New Winetests build

winetests has still not made it to CVS so one month later I have another build for you: Tests built with MSVC 7 from CVS 20031127. (Testing shell cross built with mingw32.) http://vmlinux.org/jakov/Wine/ And as Brian Vincent put it: "All you have to do is download winetests.exe and

Re: new old winetests

Alexandre Julliard <[EMAIL PROTECTED]> writes: > Ferenc Wagner <[EMAIL PROTECTED]> writes: > >> Has a problem, indeed: >> ../../include/wine/port.h:87: dlfcn.h: No such file or directory > > That's because if you want to cross-compile you need to > cross-configure too. The crosstest stuff is a hac

Re: new old winetests

Ferenc Wagner <[EMAIL PROTECTED]> writes: > Has a problem, indeed: > ../../include/wine/port.h:87: dlfcn.h: No such file or directory That's because if you want to cross-compile you need to cross-configure too. The crosstest stuff is a hack that works because the tests don't use Wine-specific fea

Re: new old winetests

"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: >-- cross compilation not tested at this point Has a problem, indeed: ../../include/wine/port.h:87: dlfcn.h: No such file or directory Understandable, as gcc has dlfcn.h, but the MinGW gcc does not. But commenting out the offending #define in c

Re: new old winetests

"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > On November 25, 2003 02:09 pm, Ferenc Wagner wrote: > >> I am sending a tarball of the present state to this >> thread shortly. > > ... the suspense it's killin' me! :) Sorry, I really sent everything a long time ago, but a spam flood seemingly br

Re: new old winetests

On November 25, 2003 02:09 pm, Ferenc Wagner wrote: > I am sending a tarball of the present state to this > thread shortly. ... the suspense it's killin' me! :) -- Dimi.

Re: new old winetests

Alexandre Julliard <[EMAIL PROTECTED]> writes: > Ferenc Wagner <[EMAIL PROTECTED]> writes: > >> What about this: >> >> makename="$BINDIR/`dirname $test`/Makefile.in" >> [...] >> sed -n '/^CTESTS =/,/[^\]$/{s/^CTESTS >> =//;s/\\$//;s/\([0-9a-zA-Z_]*\)\.c/"\1",/g;p;}' $makename

Re: new old winetests

Ferenc Wagner <[EMAIL PROTECTED]> writes: > What about this: > > makename="$BINDIR/`dirname $test`/Makefile.in" > [...] > sed -n '/^CTESTS =/,/[^\]$/{s/^CTESTS > =//;s/\\$//;s/\([0-9a-zA-Z_]*\)\.c/"\1",/g;p;}' $makename > > that is, extracting the subtest names from the corres

Re: new old winetests

Alexandre Julliard <[EMAIL PROTECTED]> writes: > "Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > >> Here is the fix for this one (to maketests): >> >> - wine $filename | sed '1,/^Valid/d;s/\(.*\)/"\1",/' >> + wine $filename | sed '1,/^Valid/d;s/\([0-9a-zA-Z_]*\)/

Re: new old winetests

"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > Here is the fix for this one (to maketests): > > - wine $filename | sed '1,/^Valid/d;s/\(.*\)/"\1",/' > + wine $filename | sed '1,/^Valid/d;s/\([0-9a-zA-Z_]*\)/"\1",/' This should really be done at run time, you

Re: new old winetests

"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > On November 22, 2003 12:32 pm, Ferenc Wagner wrote: >> Thanks for the detailed explanations; I never use implicit >> rules (prefer static patters). > > Same here, but Alexandre prefers them. Why is that Alexandre? Portability, some versions of make

Re: new old winetests

On November 22, 2003 12:32 pm, Ferenc Wagner wrote: > Thanks for the detailed explanations; I never use implicit > rules (prefer static patters). Same here, but Alexandre prefers them. Why is that Alexandre? > I didn't want to bother with this until we decide on the > interface. I don't know wha

Re: new old winetests

> BTW, there's no need to make the script bash specific, > we can use expr instead: > > -i=$(($i+1)) > +i=`expr $i + 1` That isn't a bashism, it is required to be supported by any shell that claims to be Posix compliant. That probably means everything except an AT&T/SYSV bourne shell. If

Re: new old winetests

"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > For unknown reasons, for msvcrt I get this: > const char* subtests_for_test5[] = { > "cpp^M", > "file^M", > "heap^M", > "scanf^M", > }; Oh, silly me, I forgot that I already noticed this problem and get rid of it by putting sed '1,/

Re: new old winetests

On November 22, 2003 11:45 am, Dimitrie O. Paun wrote: > Yes, there was a problem. For unknown reasons, for msvcrt > I get this: > const char* subtests_for_test5[] = { > "cpp^M", > "file^M", > "heap^M", > "scanf^M", > }; Here is the fix for this one (to maketests): - win

Re: new old winetests

On November 22, 2003 11:07 am, Ferenc Wagner wrote: > Btw, if it's you who ran the program > under Wine, you may be interested in the results: Speaking of which, I find the program too quite. I wasn't sure (until I got your email) that it ran at all! We should print the name of the currently runn

Re: new old winetests

an't tell it from your patch... I hope I did. Namely this part: $(CROSSOBJS:_so.res.cross.o=_pe.res.cross.o) > >-- supports out of tree builds > > What was needed for this? We need to explicitly give the maketests script the tests.list file. I did so as the second parameter

Re: new old winetests

. >-- supports out of tree builds What was needed for this? >-- cleans up file when winetests fails May I ask you to point it out? I can't see it on fatals. >-- supplies an automatic build label for unattended builds Might the CVS date of ChangeLog not be better per

Re: new old winetests

hen winetests fails -- more uniform naming convention in the Makefile -- tested on Linux, it builds just fine -- cross compilation not tested at this point -- fix indentation and a few cosmetic things in main.c -- indent util.c to 4-space indent -- send.c not indented, I'll let you d

Re: new old winetests

grams/winemenubuilder/Makefile programs/winemine/Makefile programs/winepath/Makefile +programs/winetests/Makefile programs/winevdm/Makefile programs/winhelp/Makefile programs/winver/Makefile Index: Make.rules.in === RCS file:

new old winetests

em: I hacked something together which works, but not sure at all if that's the right way. One other is that I did not notice that the tests return the number of tests failed as their exit status. It adds a couple of lines to the output... Anyway: programs/winetests directory: win

Re: old addition: winetests

Mike Hearn <[EMAIL PROTECTED]> writes: > On Tue, 11 Nov 2003 11:56:56 +0100, Sir Ferenc Wagner scribed thus: > >>> I think he did but... SMTP is a horrible protocol. HTTP >>> is sweet. :-) >> >> They got complicated the same way when the machine is behind >> a firewall or proxy, I am afraid. It

Re: old addition: winetests

Ferenc Wagner wrote: Jakob Eriksson <[EMAIL PROTECTED]> writes: I think he did but... SMTP is a horrible protocol. HTTP is sweet. :-) They got complicated the same way when the machine is behind a firewall or proxy, I am afraid. It's a pity Windows does not have a standard mailer...

Re: old addition: winetests

On Tue, Nov 11, 2003 at 04:18:20AM +0100, Ferenc Wagner wrote: > Hello, > > I am making slow progress with this thing. It grew sort of > usable: can be cross compiled and run to produce sensible > output (tested on XP only). Present questions: Ahh! Progress, sweet! :-) > 4. Did Jon Bright co

Re: old addition: winetests

On Tue, 11 Nov 2003 11:56:56 +0100, Sir Ferenc Wagner scribed thus: >> I think he did but... SMTP is a horrible protocol. HTTP >> is sweet. :-) > > They got complicated the same way when the machine is behind > a firewall or proxy, I am afraid. It's a pity Windows does > not have a standard mai

Re: old addition: winetests

the > shell dependencies for now. Yes, but I'm not that sure it's a good trade. I think the shell idea was a good first-order approximation. I'd rather get winetests in the tree with the shell dependency, get your scripts integrated into WineHQ, get people to test, etc. (that is, ther

Re: old addition: winetests

Jakob Eriksson <[EMAIL PROTECTED]> writes: > On Tue, Nov 11, 2003 at 04:18:20AM +0100, Ferenc Wagner wrote: > >> 4. Did Jon Bright contribute his SMTP client in the end? >>We could as well use it... Or would it be better (more >>reliable) to POST it through HTTP? > > I think he did but...

Re: old addition: winetests

integrate cross compilation into the Makefile? > > That's an interesting question. I suggest we create two > .rc files: winetests-elf.rc and winetests-pe.rc, and we > link it with the other stuff in two executables: winetests > and winetests.exe respectively. Any other ideas?

Re: old addition: winetests

uess it's fine, we will want to go down that path eventually... > 1. How to integrate cross compilation into the Makefile? That's an interesting question. I suggest we create two .rc files: winetests-elf.rc and winetests-pe.rc, and we link it with the other stuff in two exec

old addition: winetests

the wrong way. 7. Is there a way to get this into CVS after all? Feri. winetests.tgz Description: contents of programs/winetests

Re: winetests: new addition

Hi there, below is my present vision of main.c. It does not work: seems like the spawnvp call does nothing. Can you give me a clue? Feri. /* * Wine Conformance Test EXE * * Copyright 2003 Jakob Eriksson (for Solid Form Sweden AB) * Copyright 2003 Di

Re: winetests: new addition

Rolf Kalbermatter wrote: You mean something like this: (Stolen shamelessly and a little modified fror SHELL_DeleteDirectory in shlfileop.c) #define IsDotDir(x) ((x[0] == '.') && ((x[1] == 0) || ((x[1] == '.') && (x[2] == 0 static BOOL removeDir(LPCSTR dir) { BOOL ret = TRUE; HANDLE hFi

Re: winetests: new addition

Message: 1 Date: Wed, 22 Oct 2003 10:10:58 +0200 From: Jakob Eriksson <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] CC: Ferenc Wagner <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: winetests: new addition >My thought exactly. I also tried to write a recursive delete using &

Re: winetests: new addition

Ferenc Wagner wrote: Here we use the advanced Shell API but later not the Win32 API for opening files and such. What is our policy? Aha... now I understand what you mean. The fopen instead of some Win32-ism. Also inherited from my version of the program, no doubt. I just used cause I was fam

Re: winetests: new addition

Dimitrie O. Paun wrote: +void deletePath( char *path ) +{ +SHFILEOPSTRUCT fileop; + +path[strlen( path ) + 1] = '\0'; We do not have space allocated for this NUL. Se later down this message... Here we use the advanced Shell API but later not the Win32 API for opening files and

Re: winetests: new addition

On October 21, 2003 07:43 pm, Ferenc Wagner wrote: > Thanks, that is fine. I came across a webpage > http://www.websteves.com/win32asm/datrsrc.htm > stating that DISCARDABLE, LOADONCALL etc. are > not needed anymore. Do we still need them? Good point, I'll get rid of them. -- Dimi.

Re: winetests: new addition

"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > here is a tar.gz of the new files. Thanks, that is fine. I came across a webpage http://www.websteves.com/win32asm/datrsrc.htm stating that DISCARDABLE, LOADONCALL etc. are not needed anymore. Do we still need them? Feri.

Re: winetests: new addition

On Tue, 21 Oct 2003, Ferenc Wagner wrote: > It is a shame, but I can not apply your patch... It gives: Sorry about that, maybe I should submit a new patch. I'll do so when I get home, meanwhile here is a tar.gz of the new files. -- Dimi. winetests.tar.gz Description: GNU Zip compressed data

Re: winetests: new addition

re was rather busy with the DLL separation > work, I didn't want to bother him with this stuff. But now that > he finished... It is a shame, but I can not apply your patch... It gives: $ patch -p0 <~winetest.patch patching file configure.ac Hunk #1 succeeded at 1580 (offset 3 li

Re: winetests: new addition

On October 19, 2003 01:05 pm, Ferenc Wagner wrote: > But here is the reason: I was sure fgets was deprecated. > For whole bunch of libc input functions this is for possible > buffer overruns, but not for fgets. The problem here is > that you can not tell a NUL in the input stream. Yes, I know, I

Re: winetests: new addition

"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > On October 18, 2003 07:04 am, Ferenc Wagner wrote: > >>> +char line[512], *cmd; >> >> Fixed size buffers are wrong... > > Oh come on, it's just a temp buffer to copy stuff through. > It introduces no limitation. Sorry, I was too quick here. >>

Re: winetests: new addition

On October 18, 2003 07:04 am, Ferenc Wagner wrote: > > +#include > > +#include > > Do we really need it twice? Of course not :) > > +while (1) > > +{ > > +va_start(ap, fmt); > > + n = vsnprintf (p, size, fmt, ap); > > + va_end(ap); > > +if (n > -1 && n < size) return

Re: winetests: new addition

"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes: > I'm still not sure how to support building with PE .exes Could you outline the problems you can see? Since it is still not in the tree, instead of patches I send comments and questions. > +#include > +#include Do we really need it twice? > +

Re: winetests compile errors with MSVC and Wine headers

On Fri, 26 Sep 2003, Jakob Eriksson wrote: > Alas, now the MSVC headers build fail again at the same places as with > Wine headers. > Visual Studio and I do not get along very well... * > After I made "build clean" I was down to 17 tests compiling again. [sigh] I'd be really curious to know t

Re: winetests compile errors with MSVC and Wine headers

Dimitrie O. Paun wrote: On Fri, 26 Sep 2003, Jakob Eriksson wrote: I have upgraded all my include files and lib files in Visual Studio. I just got another message from you saying they all compile. Which one is true? :) Well this IS embarassing. What I meant was, Wine headers fail, MSV

Re: winetests compile errors with MSVC and Wine headers

On Fri, 26 Sep 2003, Jakob Eriksson wrote: > I have upgraded all my include files and lib files in Visual Studio. I just got another message from you saying they all compile. Which one is true? :) -- Dimi.

winetests compile errors with MSVC and Wine headers

I have upgraded all my include files and lib files in Visual Studio. -- Build started: Project: msvcrt_test, Configuration: Wine Headers Win32 -- Compiling... testlist.c scanf.c file.c Generating Code... Linking... testlist.obj : error LNK2001: unresolved external symbol _func_cpp .\Ou