On November 25, 2003 10:57 pm, Alexandre Julliard wrote:
> But I don't really care enough to keep fighting about it,
> so I put your patch in...
Thank you so much for understanding! I'm sure you've made
a bunch of people happy with this one.
--
Dimi.
On November 25, 2003 11:10 pm, Alexandre Julliard wrote:
> Modified files:
> programs/winedbg: debug.l
>
> Log message:
> Fixed one more HeapReAlloc call.
Good catch! I didn't lie when I said all calls were reviewed,
it's just that I didn't search .l files...
--
Dimi.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Alexandre Julliard
> Sent: 26 November 2003 04:09
> To: [EMAIL PROTECTED]
> Subject: wine/ windows/win.c windows/message.c programs ...
>
> Log message:
> Fixed declarations of BroadcastSystemMessage
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> I know we've discussed this before, but I feel things
> have changed and it's worth another try :) Namely,
> have the winehq.org name be the default one. It seems
> virtually everybody (except you) prefer the .org name
> over the .com name, it's way
I'm trying to debug a crash in some changes to the jack
audio driver and can't seem to have the wine debugger show
me the actual source code of the crash. I start up the
debugger and get this:
oaded debug information from ELF 'wine' ((nil))
No debug information in 32bit DLL 'C:\Program
Files\w
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> What do you mean by "delayed imports". When I defined, proper, the
> entire spec as actual functions, I got conflicts when I tried to
> define GetProcAddress. In any case, even then I'm going to need to
> call GetProcAddress (yes, I guess I can use the
Alexandre Julliard wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
My existing patch is in DOSFS_GetFullName, which is called by
GetFileAttributes. Another thing, however, is that I'm begining to
doubt whether it is indeed used for what you said it is. It seems that
calling "GetFileAttribut
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> My existing patch is in DOSFS_GetFullName, which is called by
> GetFileAttributes. Another thing, however, is that I'm begining to
> doubt whether it is indeed used for what you said it is. It seems that
> calling "GetFileAttributesW" on Windows 98 ret
Alexandre Julliard wrote:
Shachar Shemesh <[EMAIL PROTECTED]> writes:
I'll send a patch, then.
Note that this needs a general solution. Please don't just add a
special case in GetFileAttributes.
My existing patch is in DOSFS_GetFullName, which is called by
GetFileAttributes. Another t
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> I'll send a patch, then.
Note that this needs a general solution. Please don't just add a
special case in GetFileAttributes.
> I already have a plan for doing that. Unfortunetly, it's not a nice
> one. Basically, it means changing unicows.spec.c afte
Lists (And screenshots) of lots of stuff m$ never released, like windows
neptune, Whistler
Advanced Server, Cairo, Nashville (Windows 96), windows titanium, windows 99,
and more.
http://ad-iso.mine.nu/~air101/
I'm using a build that is about one month old, but I don't think that this is
the problem. I will update in the next few days and then I will see if this
goes away.
OK. I have written this small tool which you can download at
http://sourceforge.net/projects/launchmen. The Linux port uses a normal
Alexandre Julliard wrote:
It seems to be a way to detect NT/Win95, I suspect Win95 returns a
different error code in that case. Using GetVersion() would of course
have been too easy...
And that, after they DO call "GetVersion", and do keep a variable
telling whether it's NT or not. Oh well.
W
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> It appears that applications using unicows will not work in NT mode on
> wine unless the attached patch is applied. Unicows' init calls
> "GetFileAttributesW" with "???.???". It expects, if it fails, to get
> error code 123 (ERROR_INVALID_NAME), otherw
Rolf Kalbermatter wrote:
Now here's the puzzle - GetProcAddress is never called. Neither are
these functions imported from the DLL in the PE header. In fact,
unicows.dll does not even appear in the PE header (which makes sense -
on NT you don't even want to install it). This means that unicows.
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
"Dimitrie O. Paun" <[EMAIL PROTECTED]> writes:
> Any more info on this stuff other than this:
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysinfo/base/writeprivateprofilestring.asp
No, but I think the above page is a pretty good description of the
mechanism (better a
Rein Klazes wrote:
- How did you see the example before, as screen coordinates and client
coordinates where mixed up: I never saw the example text.
I applied your patch.
I don't know what happened to the font dialog. It did work back when I
made the changes. something must have happened to it
Message: 4
Subject: Re: PE stack trick not working on lowmem machines
From: Mike Hearn <[EMAIL PROTECTED]>
To: Alexandre Julliard <[EMAIL PROTECTED]>
Cc: Marcus Meissner <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Date: Mon, 24 Nov 2003 21:00:33 +
On Mon, 2003-11-24 at 20:38, Alexandre Julliard wro
Le mar 25/11/2003 Ã 00:37, Alex Tribble a Ãcrit :
> Hi,
> When upgrading to Fedora Core 1 (the new RedHat release, sort of),
> wine stopped compiling for me. I was getting errors while parsing
> , et al. -DOPENSSL_NO_KRB5 makes these go away.
>
> Any thoughts? Please CC me, as I'm not subscribed
On Tue, 25 Nov 2003 18:13:55 +0100, I wrote:
> Just two questions:
>
>
> - Why don't I see this? Even with selecting a font with Hebrew encoding
> I only see the AaBb string.
No I did not look good enough, I see the Hebrew characters now.
Rein.
--
Rein Klazes
[EMAIL PROTECTED]
On Tue, 25 Nov 2003 18:42:45 +0200, you wrote:
> Rein Klazes wrote:
>
> > HPEN hOrigPen;
> > HFONT hOrigFont;
> > COLORREF rgbPrev;
> >-WCHAR sample[SAMPLE_EXTLEN+5]={'A','a','B','b'};
> >+WCHAR sample[SAMPLE_EXTLEN+9]={'A','a','B','b','Y','y','Z','z'};
> >
Rein Klazes wrote:
HPEN hOrigPen;
HFONT hOrigFont;
COLORREF rgbPrev;
-WCHAR sample[SAMPLE_EXTLEN+5]={'A','a','B','b'};
+WCHAR sample[SAMPLE_EXTLEN+9]={'A','a','B','b','Y','y','Z','z'};
This is wrong. "YyZz" are only added if it's a western encoding. This
On 24 nov. 03, at 21:11, Alexandre Julliard wrote:
"Pierre d'Herbemont" <[EMAIL PROTECTED]> writes:
Here is my second try for a replacement of the _end symbol. I think
that since there is no support of it we need a kind of emulation
function, which I thought should be located in the wine_port lib
Alexandre Julliard wrote:
"Rolf Kalbermatter" <[EMAIL PROTECTED]> writes:
My tests show that RemoveDirectory just as CreateDirectory rejects all
paths which contain one of the wildcards ": * ? \" < > |" with error 123
completely independent where that character occurs (not just in the path
ele
Steven Edwards wrote:
--- Shachar Shemesh <[EMAIL PROTECTED]> wrote:
If anyone can help me shed more light on this, I would be most
grateful.
I dont know if you've seen this or not. Maybe it will be of some help.
http://libunicows.sourceforge.net/
Thanks
Steven
I guess the same proble
26 matches
Mail list logo
