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
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
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
&
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
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
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.
"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.
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
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> On October 19, 2003 01:05 pm, Ferenc Wagner wrote:
>
>> Have you got an idea why your patch has not been committed?
>
> Not really. Maybe because I haven't solved the cross compilation
> problem... Alexandre was rather busy with the DLL separation
>
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
"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.
>>
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
"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?
> +
13 matches
Mail list logo
