"Martin Fuchs" <[EMAIL PROTECTED]> wrote:
> Changelog:
> make drive letters in PIDLs always uppercase to enable PIDL comparison
>
>
> Index: shfldr_mycomp.c
> ===
> RCS file: /CVS/ReactOS/reactos/lib/shell32/shfldr_mycomp.c,v
> retr
> "Martin" == Martin Fuchs <[EMAIL PROTECTED]> writes:
Martin> Changelog: return "file not found" error values instead of
Martin> E_INVALIDARG if _ILCreateFromPathA() failed to find files
...
Martin> 0x80070002L; /* file not found */ } else { pidlTemp =
...
Don't we have a symbo
Michael Stefaniuc wrote:
Afaik, if it's const it should be somewhere in the .bss and therefor it
shouldn't be allocated on the stack on function entry.
bye
michael
That MAY be true for C++. It is defenitely not true for C. In C, const
just means it's the same ol' var, only it can't be changed
Hi,
I'm trying to make GetFreeDiskSpace working with CDROM because a game
needs it.
However, I'm experiencing problem with statvfs...
Indeed, statvfs always returns f_frsize = 0 and f_blocks = 0.
If I cd to /mnt/cdrom or edit a file in it, this does not help however
if I run a grep or launch Kon
Izak Burger <[EMAIL PROTECTED]> writes:
> I'm currently debugging a problem with serial comms over wine, and I
> see that when a serial device is opened (in server/serial.c) the
> serial_get_info function returns a type of FD_TYPE_DEFAULT, which in
> turn causes the serial device to be read from a
On Tue, Apr 13, 2004 at 11:40:00PM +0300, Shachar Shemesh wrote:
> Francois Gouget wrote:
> >On Tue, 13 Apr 2004, Mike McCormack wrote:
> >>Perhaps we should make a janitorial task to CONST-ify strings where
> >>possible?
> >In some places the Unicode strings that are declared *inside functions*
>
Francois Gouget wrote:
On Tue, 13 Apr 2004, Mike McCormack wrote:
[...]
Perhaps we should make a janitorial task to CONST-ify strings where
possible?
In some places the Unicode strings that are declared *inside functions*
are declared both static and const. Is the static necessary in that
On Tue, 13 Apr 2004 17:40:46 +, j.cooper1 wrote:
> I am trying to compile Wine (the latest CVS) on Mac os x.
Hi,
Thanks for the bug report. The best thing to do is produce a patch and
mail it to [EMAIL PROTECTED]
Wine on MacOS/X does not compile reliably. See the darwine project
(darwine.ope
I am trying to compile Wine (the latest CVS) on Mac os x. If I emailed the wrong list
sorry
I noticed what I think is a bug
in file dll/kernel/console.c
around line 1003 exists function below
when compiling it gives me an error about x being undefined or something similar
COORD WINAPI GetLarge
On Tue, 13 Apr 2004, Mike McCormack wrote:
[...]
> Perhaps we should make a janitorial task to CONST-ify strings where
> possible?
In some places the Unicode strings that are declared *inside functions*
are declared both static and const. Is the static necessary in that
context?
The following com
Juan Lang wrote:
>
> --- Robert Shearman <[EMAIL PROTECTED]>
> wrote:
> > CryptGetOIDFunctionAddress is
> > kind of like GetProcAddress and so all of the real
> > work is done by
> > CertDllOpenStoreProv which is provided by the
> > certificate provider.
>
> > CertOpenStore is just a wrapper for
>
Hello,
I'm currently debugging a problem with serial comms over wine, and I see
that when a serial device is opened (in server/serial.c) the
serial_get_info function returns a type of FD_TYPE_DEFAULT, which in
turn causes the serial device to be read from and written to with pread
and pwrite i
--- Robert Shearman <[EMAIL PROTECTED]>
wrote:
> CryptGetOIDFunctionAddress is
> kind of like GetProcAddress and so all of the real
> work is done by
> CertDllOpenStoreProv which is provided by the
> certificate provider.
> CertOpenStore is just a wrapper for
> CryptGetOIDFunctionAddress("CertDllO
Mike McCormack <[EMAIL PROTECTED]> writes:
>> ---
>> err:virtual:map_image Image was mapped at 0x11c000: standard load address for a
>> Win32 program (0x0040) not available
>> err:virtual:map_image Do you have exec-shield or prelink active?
>> wine: could not load L"G:
Peter Riocreux wrote:
vars.pe_size = 0x0100;
vars.pe_address = (void*)0x0040;
// wld_reserve_wine_memory( pe_file, &vars.pe_address, &vars.pe_size );
mmap( vars.pe_address, vars.pe_size, PROT_NONE,
MAP_FIXED|MAP_PRIVATE|MAP_ANON, -1, 0);
Is this a get-it-working-
Peter Riocreux wrote:
It seems to be behaving as if none of your cunning
exec-shield-avoidance code is in there. The error messages certainly
seem to indicate this:
---
err:virtual:map_image Image was mapped at 0x11c000: standard load address for a Win32
program (0x00400
Mike McCormack <[EMAIL PROTECTED]> writes:
> What's the problem with wineconsole?
It seems to be behaving as if none of your cunning
exec-shield-avoidance code is in there. The error messages certainly
seem to indicate this:
---
err:virtual:map_image Image was mapped at 0
What's the problem with wineconsole?
I discovered a bug in the calculation of the area to reserve when
parsing the PE header, so I'll write a fix for that too.
Mike
Peter Riocreux wrote:
Have tested this a little and seems alright (a few offsets versus the
CVS as of 10:00 GMT, but applies clean
Have tested this a little and seems alright (a few offsets versus the
CVS as of 10:00 GMT, but applies cleanly). Alas our license for the
tool I was testing it with is not currently available, so I can't test
it out properly. It does at least load the first binary cleanly
though, so that is definit
"Santosh Siddheshwar" <[EMAIL PROTECTED]> wrote:
> I didnt get the second point that you mention
> Another one might be that WM_CREATE must be always
> passed to DEFDLG_Proc regardless of what result an application
> returned to DefDlgProc16/A/W.
Here is a snippet of DefDlgProc16 (DefDlgProcA/W
Hi,
Some time ago I fixed some stubs on SHLWapi lib, but the patch needs some
cleanup. I haven't the time to do them (because they are not "natural" for
me, and when I tried to post the cleaned up version I missed a lot of
cleans.
If someone can take a look at it, clean it up and possibly merge it,
Hi,
I didnt get the second point that you mention
Another one might be that WM_CREATE must be always
passed to DEFDLG_Proc regardless of what result an application
returned to DefDlgProc16/A/W.
Regards
Santosh Siddheshwar
> -Original Message-
> From: Dmitry Timosh
"Robert Shearman" <[EMAIL PROTECTED]> wrote:
> > +if (!(dlgInfo = HeapAlloc( GetProcessHeap(), 0,
> sizeof(*dlgInfo) ))) return 0;
>
> Minor point, but you probably want to return -1 here to say that window
> creation failed.
Good catch. Another one might be that WM_CREATE must be al
Santosh Siddheshwar wrote:
>
> Change Log:
> windows/defdlg.c - Added code for allocating DIALOGINFO structure and
> storing it as an attribute of the window
> windows/dialog.c - Removed code for allocating DIALOGINFO structure and
> moved initialization of DIALOGINFO structure
> to after CreateWin
Given the problems that Wine has had with Installers, had anyone noticed
that WiX has now been released by Microsoft (under the CPL license) on
Sourceforge.
http://seattlepi.nwsource.com/business/168652_msftnotebook12.html
It seems to be accessible as http://wix.sf.net, but that redirects to a
bl
On Tue, 13 Apr 2004 11:33:02 +0900, Dmitry Timoshkov wrote:
> Did you try to add +win?
>
> Is that what you are looiking for?
>
> windows/winpos.c,1176:
Yes, I should have thought to check there. I didn't enable +win
because it adds a lot of spew I wasn't interested in, but I should have
guesse
On Mon, 12 Apr 2004 21:33:52 +, [EMAIL PROTECTED] wrote:
> fixme:dc:LockWindowUpdate (0x10029), partial stub!
You can ignore this. You might get a bit of unnecessary flashing. It'll be
fixed as part of moving part of the remaining windowing code into the
wineserver.
> fixme:winhelp:HLPFILE_Un
27 matches
Mail list logo
