> Message du 15/04/04 00:35> De : Alexandre Julliard <[EMAIL PROTECTED]>> A : Christian Costa <[EMAIL PROTECTED]>> Copie à : wined <[EMAIL PROTECTED]>> Objet : Re: statvfs and cdrom problem> Christian Costa <[EMAIL PROTECTED]>writes:> > > Yes, this works fine. Thanks. :-)> > When do you plan to r
> Log message:
> Only create the device symlinks the first time around.
> + # Check if dosdevices exists and create it if necessary
> + if [ ! -d ~/.wine/dosdevices ]
> + then
> +mkdir ~/.wine/dosdevices
> +ln -s /mnt/fd0 ~/.wine/dosdevices/a:
> +ln -s $CROOT ~/.wine/dosdevice
OK.One place where this could be done is WM_NCCREATE which comes before
WM_CREATE. Other place (possibly better) where it might be possible to do
this is in CBTProc hook procedure. Not sure about the second option though.
Any thoughts?
Regards
Santosh Siddheshwar
> -Original Message-
> Fro
Santosh Siddheshwar <[EMAIL PROTECTED]> writes:
> But dont you think that the structure is not really required till the
> window has been created successfully?
Well, I don't think so, but the only way to know for sure is to write
a test program under Windows to determine the exact behavior.
--
Lionel Ulmer <[EMAIL PROTECTED]> writes:
> If it's normal for the sending to time-out, we should replace this code and
> add some HeapAlloc on the sender side and some HeapFree on the receiver side
> each time such a structure is sent ... Which will be a bit problematic for
> performance, but well
Hi,
But dont you think that the structure is not really required till the
window has been created successfully?
Regards
Santosh Siddheshwar
> -Original Message-
> From: Alexandre Julliard [SMTP:[EMAIL PROTECTED]
> Sent: Thursday, April 15, 2004 9:00 AM
> To: Dmitry Timoshkov
> Cc: Sa
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes:
> Yes, if Alexandre has no objections. Be patient, that may take some time.
Actually, I do have an objection... I think you should be allocating
the structure as soon as it is needed, WM_CREATE is not the first
message that the window will receive.
"Rafael аvila de EspМndola" <[EMAIL PROTECTED]> wrote:
> I have tested the patch with a abnt2 and a us-int keyboard. Both work
> correctly.
>
> Dmitry: Do you think that the "magic numbers" are reasonably explained? What I
> have done is basically to treat the comma similarilly to the decimal peri
I decided to try cross compiling all of wine using mingw..hit a couple problems in
dbghelp
This fixes a few of them, it still doesn't compile (primarily because of a missing
regex.h at the moment)
but it does get farther
I'm not sure if these fixes are quite right..I don't fully understand this
"Santosh Siddheshwar" <[EMAIL PROTECTED]> wrote:
> So can I expect this to be checked into cvs soon?
Yes, if Alexandre has no objections. Be patient, that may take some time.
--
Dmitry.
Jon Griffiths <[EMAIL PROTECTED]> writes:
> -#ifndef MAPICODE_H
> -#define MAPICODE_H
> +#ifndef __WINE_MAPICODE_H
> +#define __WINE_MAPICODE_H
It's better to keep the same defines as Windows, especially since in
that case they are used from other headers.
> -#define MAKE_MAPI_SCODE(sev,fac,code
This is an update for bug 560
http://bugs.winehq.org/show_bug.cgi?id=560
I have gone through each and every bug in Bugzilla (yes all 2174 of them) and
linked the ones that I could find an AppDB entry for. That translates into 756
bugs. Some of these bugs applied to more than one program. In those
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> ChangeLog
> Dimitrie O. Paun <[EMAIL PROTECTED]>
> Always use CC to compile the .spec.c file.
Doesn't compile_to_object() do this already?
--
Alexandre Julliard
[EMAIL PROTECTED]
Christian Costa <[EMAIL PROTECTED]> writes:
> Yes, this works fine. Thanks. :-)
> When do you plan to rewrite GetFreeDiskSpace?
In a few days I guess. There are still some missing features in
NtCreateFile that need to be done first.
--
Alexandre Julliard
[EMAIL PROTECTED]
* Mike Hearn (Thu, 08 Apr 2004 14:09:27 +0100) wrote:
| On Thu, 08 Apr 2004 00:27:40 +0200, Andrà Johansen wrote:
| > I di put the --no-exec-shield flag in /etc/sysconfig/prelink, and ran
| > "prelink -au" and "prelink -a" before running the new Wine version.
| >
| > Is that not good enough?
|
|
Am Mittwoch, 14. April 2004 19:09 schrieben Sie:
> The new filesystem code that I'm working on currently is supposed to
> fix that issue.
Great! Thank you.
It's just that all machines I install use autofs on removables and even on
native win and backup partitions. I already worked on excuses fo
Hi all,
While debugging GeneRally (a very nice game), I got some problems with
DInput receiving spurious events (basically, as if key '0' was pressed).
This is traced to the following problem :
In windows/input.c, the function 'queue_kbd_event' stores the
KBDLLHOOKSTRUCT structure on the stack a
Well, I broke down and pulled out the oscope and rs232 breakout box to
try to figure out why my app isn't able to communicate with the device.
turns out that Rein's patch is correctly deasserting DSR, however, I am
not getting any data over the Tx pin. And after I checked the output of
WriteFile,
Alexandre Julliard wrote:
Christian Costa <[EMAIL PROTECTED]> writes:
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
"Martin Fuchs" <[EMAIL PROTECTED]> writes:
> Even for drive letters?
> The only valid characters you will find in szElement[0] are a..z and A..Z.
Not all Unix locales map a..z to A..Z, so yes we have to use
toupperW. But a better fix is probably to make _ILCreateDrive take a
Unicode string and do
Hi Juan,
> Martin wrote:
> > But we could use the expression
> > "MAKE_HRESULT(SEVERITY_ERROR, FACILITY_WIN32,
> > ERROR_FILE_NOT_FOUND)" instead.
>
> A shorter version is
> HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND).
Yes, this would also be a possible solution.
But HRESULT_FROM_WIN32 contains so
Hi Martin,
Martin wrote:
> But we could use the expression
> "MAKE_HRESULT(SEVERITY_ERROR, FACILITY_WIN32,
> ERROR_FILE_NOT_FOUND)" instead.
A shorter version is
HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND).
Question: could you not change _ILCreateFromPathA to
return an HRESULT?
--Juan
13 Apr 2004 20:45:39 -
> > @@ -217,6 +217,7 @@ ISF_MyComputer_fnParseDisplayName (IShel
> > /* do we have an absolute path name ? */
> > else if (PathGetDriveNumberW (lpszDisplayName) >= 0 &&
> lpszDisplayName[2] == (WCHAR) '\\') {
> > szNext = GetNextElementW (lpszDispla
Hi Peter,
Peter wrote:
> 1) If I am using SetLastError, it is not obvious to
> me what error values I should be using there.
They should be a Win32 error message, the ones defined
in winerror.h that aren't HRESULTs (so, lowish values,
less then 32000 or so, not 0x80070002-ish).
> 2) Can I assume
> ...
> Martin> 0x80070002L; /* file not found */ } else { pidlTemp =
> ...
> Don't we have a symbolic error for that?
There is no such constant in winerror.h.
But we could use the expression "MAKE_HRESULT(SEVERITY_ERROR, FACILITY_WIN32,
ERROR_FILE_NOT_FOUND)" instead.
This is also used for
I just got around to patching and compiling the '0408 release of Wine,
and I notice a few improvements. I tried it out with Corel PerfectOffice
9, of which my family has several copies. Here are my
results:
WordPerfect hung at the splash screen. Presentations loaded up, but the
menu was empty
Mark Draheim <[EMAIL PROTECTED]> writes:
> However, Guido is busy right now and cannot work on the patch. And my C is
> pretty bad. If anybody is interested I can provide the last patch known to
> work. If for some reason the patch does not meet wine's standards, would it
> be possible that the
Having seen a lot of messages like:
-
fixme:console:SetConsoleCtrlHandler (0x41a8af,1) - no error checking or testing yet
-
lately, I thought I would actually see if I could fix it up and remove the FIXME.
It is in dlls/kernel/console.c, and the MSDN reference is
Christian Costa <[EMAIL PROTECTED]> writes:
> 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 doe
Peter Riocreux wrote:
In fact I spoke too soon - the "Notify Error" multiplied in one (of
v. many) runs and it got itself in an loop that seemed to be headed
for infinite status, repeating the message:
--
Notify Error: 1-Shm76 0xbf118b78 6
--
Anybody using autofs and wine? Does it work? I don't follow wine development
lists, so maybe autofs is no longer a problem. Once in a while I build a CVS
snapshot and test whether the odd app I still have works. And wine on autofs
doesn't work here. I think Guido already sent a mail about this
With this latest (version 4) of the patch my app now gives every
impression of working fine. It starts, spawns children, and appears to
run correctly to completion, including dealing with a license manager
on a remote machine. If used interactively, some of the fonts are a
bit ropey, but I haven't
> Changelog:
> Remove "Path" lines from sample config.
> Setup the links for the default DOS drives in wineinstall.
hey, it is plain and simple change but it makes me disappointed right
after second reinstall of Wine. GNU ln when encounters existing target
(link to directory, in fact) creates a sy
Mike Hearn wrote:
On Wed, 14 Apr 2004 18:44:45 +0900, Mike McCormack wrote:
Anybody have a FreeBSD machine to test this on?
If it still uses syscalls surely that won't work on anything other than
Linux?
It doesn't use syscalls any more, so it has a chance of working on some
other platform...
I
On Wed, 14 Apr 2004 18:44:45 +0900, Mike McCormack wrote:
> Anybody have a FreeBSD machine to test this on?
If it still uses syscalls surely that won't work on anything other than
Linux?
Hi,
So can I expect this to be checked into cvs soon?
Regards
Santosh Siddheshwar
> -Original Message-
> From: Dmitry Timoshkov [SMTP:[EMAIL PROTECTED]
> Sent: Wednesday, April 14, 2004 5:22 PM
> To: Santosh Siddheshwar; Robert Shearman
> Cc: [EMAIL PROTECTED]
> Subject: Re: Han
Nope, now the app just dies with very little trace as to why. Not to
worry, I just need to go eat some lunch or something and get my head
clear. This conversation has given me a much clearer understanding of
what goes on.
Mike McCormack wrote:
Izak Burger wrote:
Ok. I had to set +comm to ge
"Santosh Siddheshwar" <[EMAIL PROTECTED]> wrote:
> Thanks for the feedback. Excellent catches! Hope my next mail to
> wine-patches gets through!
Your new patch looks good for me. Thanks for doing this work!
--
Dmitry.
From what I can see, the culprit would be this :
trace:opengl:X11DRV_SwapBuffers (0x403d55e0)
trace:opengl:wglMakeCurrent ((nil),(nil))
X Error of failed request: GLXBadDrawable
As the glXSwapBuffers call may return before the buffer swap is actually
done in hardware, it may happen that the driver
Izak Burger wrote:
Ok. I had to set +comm to get that info, and modified the code to dump
the contents of the COMMTIMEOUTS structure:
trace:comm:SetCommTimeouts ReadIntervalTimeout=4294967295
trace:comm:SetCommTimeouts ReadTotalTimeoutMultiplier=0
trace:comm:SetCommTimeouts ReadTotalTimeoutCons
Thanks for the speedy reply.
Mike McCormack wrote:
The wineserver may also change the status of the request to
STATUS_SUCCESS after a certain timeout is reached. The problem is most
likely that the timeout is not being calculated properly.
>
> The code to do that is in server/async.c and server
Hi again,
Here's a fix for the bug that Peter found. The calculation of the
reserve area was correct, however the environment was not being cleared
correctly, so memory was being reserved for the wrong .exe file.
Anybody have a FreeBSD machine to test this on?
Mike
---
Thanks for the feedback. Excellent catches! Hope my next mail to
wine-patches gets through!
Regards
Santosh Siddheshwar
> -Original Message-
> From: Dmitry Timoshkov [SMTP:[EMAIL PROTECTED]
> Sent: Tuesday, April 13, 2004 7:38 PM
> To: Santosh Siddheshwar; Robert Shearman; [EMAIL PROTECT
Hi Izak,
The wineserver may also change the status of the request to
STATUS_SUCCESS after a certain timeout is reached. The problem is most
likely that the timeout is not being calculated properly.
The code to do that is in server/async.c and server/serial.c.
The timeouts are set by the SetCo
I end up showing my ignorance :-)
Ok, I see how it is supposed to work, so I changed it back to
FD_TYPE_DEFAULT. It looks like my real troubles is caused by the
snippet of code that decides when the read is successful:
if (io_status->Information >= fileio->count
|| fileio->fd_type == FD_TY
45 matches
Mail list logo
