"Mike McCormack" <[EMAIL PROTECTED]> wrote:
> There's quite a few strcasecmp calls revealed by:
>
> find . -name \*.c -exec grep strcasecmp {} \; -ls
>
> We probably need somebody to go through and clean them all up. Maybe a
> janitorial task?
Almost all of them can be directly replaced by ls
-if (strcasecmp ( szData1, szData2 )!=0 )
+if (strcasecmp( szData1, szData2 ))
As a common rule strcasecmp should never be used in Wine code, since
it introduces problem with portability and unexpected side effects
when locale of the underlying system differs from a Wine one.
You
"Mike McCormack" <[EMAIL PROTECTED]> wrote:
> ChangeLog:
> * cleanup, create unicode versions of _ILCreateFromPath,
> _ILCreateGuidFromStr, and _ILCreateFromFindData
> @@ -524,7 +516,7 @@ BOOL WINAPI ILIsEqual(LPCITEMIDLIST pidl
> _ILSimpleGetText(pidltemp1, szData1, MAX_PATH);
>
Joris Huizer wrote:
I'm supposed to choose a topic - and work it out - for a "bachelor
project";
Now, at the moment I have no clue, and teachers are discussing what
topics to hand; in the mean time, I think maybe it might be interesting
to do some wine work in such a form that it's ok for this "
On Tue, 22 Feb 2005 09:22, [EMAIL PROTECTED] wrote:
> >Since it's the only entry where the string and
> >pointer/function/object/structure/whatever don't match I wondered it
> >"wglGetSwapIntervalEXT" ... wglSwapIntervalEXT might be a typo rather
> >than.
>
> You are right
> Seems that lionel made
Casper Hornstrup wrote:
W32api IS the MinGW headers.
No, we have a wine win32 package on our download page, it's build with
wine headers, not the
mingw ones.
Ivan.
--- Mike Hearn <[EMAIL PROTECTED]> wrote:
> On Mon, 21 Feb 2005 16:47:11 +, Oliver Stieber
> wrote:
> > Now it starts up and I get the error.
> >
> > "err:virtual:NtMapViewOfSection Sizes larger than
> 4Gb
> > not supported"
>
> Wacky. Can you post a +ole,+tid,+seh trace please.
>
>
>
Le lun 21/02/2005 à 13:47, Alexandre Julliard a écrit :
> Vincent Béron <[EMAIL PROTECTED]> writes:
>
> > Move definitions from winerror.h to issperr.h.
>
> I don't think you want to do that, issperr.h is supposed to be an
> obsolete header.
Ok, I don't have a current SDK to check against.
Anyw
--- Casper Hornstrup <[EMAIL PROTECTED]> wrote:
> Yes, but then you need to publish the sources for the non-free application
> under the LGPL. When using headers to build your application, you create a
> derived work of those headers.
>
> http://www.fsf.org/licensing/licenses/lgpl.html
The heade
> >I have absolutely no understanding of this but in the list at the
> >end of your patch mailed to the list there is...
> >
> > { "wglGetSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, NULL},
> >
> >and 5 lines later
> >
> > { "wglSwapIntervalEXT", (void *) wglSwapIntervalEXT, NULL, N
On Mon, Feb 21, 2005 at 10:19:42PM +, [EMAIL PROTECTED] wrote:
> GL_VERSION isn't pertinent as it contains (only) provider and
> driver version while GLX_VERSION is really the version string of GLX impl.
Well, on my machine:
OpenGL version string: 1.4.0 NVIDIA 43.63
So it gives you, at lea
On Mon, Feb 21, 2005 at 09:25:05PM +, Alex Woods wrote:
> It looks as though it's the Pbuffer stuff it is after. Right after all
> those wglGetProcAddress it does this:
>
> trace:opengl:wglCreatePbufferARB (0x7b8, 1, 1024, 1024, 0x55bdfc4c)
> trace:opengl:wglGetPbufferDCARB ((nil))
Ah ah !!
On Monday, February 21, 2005 03:43 pm, Rein Klazes wrote:
> On 10 Feb 2005 21:19:46 +0100, you wrote:
> > Carl Sopchak <[EMAIL PROTECTED]> writes:
> > > I guess my problem is that I have NO CLUE as to how this SHOULD be
> > > handled. Should the style be set to (style & ~WS_VISIBLE) when the
> > >
Message d'origine
>De: Colin Wright <[EMAIL PROTECTED]>
>A: Raphael <[EMAIL PROTECTED]>
>Sujet: Re: World Of Warcraft
>Date: Mon, 21 Feb 2005 21:07:14 +
>
>Raphael wrote:
>
>> Ouppsss
>>
>> better patch
>>
>> sorry
>>
>> Regards,
>> Raphael
>>
>> On Monday 21 February 2005 09:58,
On Mon, Feb 21, 2005 at 09:39:31PM +0100, Raphael wrote:
> Ouppsss
>
> better patch
It looks as though it's the Pbuffer stuff it is after. Right after all
those wglGetProcAddress it does this:
trace:opengl:wglCreatePbufferARB (0x7b8, 1, 1024, 1024, 0x55bdfc4c)
trace:opengl:wglGetPbufferDCARB ((
Hi lionel,
GL_VERSION isn't pertinent as it contains (only) provider and
driver version while GLX_VERSION is really the version string of GLX impl.
Regards,
Raphael
Message d'origine
>De: Lionel Ulmer <[EMAIL PROTECTED]>
>A: Raphael <[EMAIL PROTECTED]>
>Copie à: Alex Woods <[EMAIL PROT
Hi,
--- Casper Hornstrup <[EMAIL PROTECTED]> wrote:
> I might vote for using WINE headers in ReactOS if WINE relicensed
> its headers to a w32api or BSD like license that will allow use in
> a non-free application. What I would like to see most though, is
> for all three projects to share w32api.
On Mon, Feb 21, 2005 at 09:39:31PM +0100, Raphael wrote:
> Ouppsss
>
> better patch
Thanks, and good timing - I was just about to go and debug it ;)
The new patch gives the following wglGetProcAddress stuff, which looks
more like it (chopping the top bits off):
trace:opengl:wglGetProcAddress (g
On Sun, 20 Feb 2005 16:41:09 +0100, you wrote:
> On Sun, 20 Feb 2005 16:04:54 +0100
> Rein Klazes <[EMAIL PROTECTED]> wrote:
> >
> > Does this patch help?
> >
> > Rein.
>
> Unfortunately not - still the exact same error.
Surprise :(
OK, I can try once more, perhaps the counter is much more th
On Mon, Feb 21, 2005 at 09:39:31PM +0100, Raphael wrote:
> Ouppsss
>
> better patch
Why did you do this change:
-const char *gl_version = (const char *) glGetString(GL_VERSION);
+const char *gl_version = glXGetClientString(display, GLX_VERSION);
I.e. replacing the GL version with the on
On 10 Feb 2005 21:19:46 +0100, you wrote:
> Carl Sopchak <[EMAIL PROTECTED]> writes:
>
> > I guess my problem is that I have NO CLUE as to how this SHOULD be handled.
> >
> > Should the style be set to (style & ~WS_VISIBLE) when the rectangle is
> > {0,0;0,0}? Should {0,0;0,0} be considered
Ouppsss
better patch
sorry
Regards,
Raphael
On Monday 21 February 2005 09:58, Alex Woods wrote:
> On Mon, Feb 21, 2005 at 09:33:29AM +0100, Raphael wrote:
> > can you try this patch ?
>
> Yes, doesn't look any different though. I did notice that with either
> patch I get this though:
>
> 0009:
Adds support for NZDT (New Zealand Daylight Time) to TZ_INFO.
Cheers,
--
Darryl Dixon <[EMAIL PROTECTED]>
diff -ru wine-20050211/dlls/ntdll/time.c wine-20050211_NZDT/dlls/ntdll/time.c
--- wine-20050211/dlls/ntdll/time.c 2005-02-09 01:13:36.0 +1300
+++ wine-20050211_NZDT/dlls/n
TANABE Hiroshi <[EMAIL PROTECTED]> writes:
> if(!(fuFormat & GGO_GLYPH_INDEX)) {
> -p = FONT_mbtowc(hdc, (char*)&uChar, 1, NULL, NULL);
> +int len;
> +if(uChar > 0xff) { /* but, 2 bytes charactor only */
> +len = 2;
> +uChar = (uChar & 0xff) <<
Vincent Béron <[EMAIL PROTECTED]> writes:
> Move definitions from winerror.h to issperr.h.
I don't think you want to do that, issperr.h is supposed to be an
obsolete header.
--
Alexandre Julliard
[EMAIL PROTECTED]
Francois Gouget <[EMAIL PROTECTED]> writes:
> On Mon, 21 Feb 2005, Alexandre Julliard wrote:
>
> > Francois Gouget <[EMAIL PROTECTED]> writes:
> >
> >> -noname vs. ordinal internal consistency
> >> -
> >>
> >> This check verifies that all APIs which have th
Hey,
I was wondering if winecfg should create symlinks for devices
(dosdevices/d:: -> /dev/cdrom)?
If it has to, how should it be implented. I can only see drive device
symlinks created here:
http://source.winehq.org/source/dlls/kernel/volume.c#L219
But I don't think that's the correct place to d
On Mon, 21 Feb 2005, Alexandre Julliard wrote:
Francois Gouget <[EMAIL PROTECTED]> writes:
-noname vs. ordinal internal consistency
-
This check verifies that all APIs which have the '-noname' property,
also have an explicit ordinal. This is the only check wh
George Ginden ha scritto:
Hi do you guys know anything about that already ?
It looks like some keys are not mapped correctly:
Also this is related to bug #2742:
http://bugs.winehq.org/show_bug.cgi?id=2742
On Mon, 21 Feb 2005 16:47:11 +, Oliver Stieber wrote:
> Now it starts up and I get the error.
>
> "err:virtual:NtMapViewOfSection Sizes larger than 4Gb
> not supported"
Wacky. Can you post a +ole,+tid,+seh trace please.
Francois Gouget <[EMAIL PROTECTED]> writes:
> -noname vs. ordinal internal consistency
> -
>
> This check verifies that all APIs which have the '-noname' property,
> also have an explicit ordinal. This is the only check which does not
> depend on dumps of t
Le samedi 19 fÃvrier 2005 Ã 10:02 +0100, Tobias Burnus a Ãcrit :
> PPS: Can one now submit new applications to the app.winehq.org app
> database? I already tried several times, but I got no response at all,
> then I gave up.
>
It works. But the application you submit have to be reviewed before
Michael Jung <[EMAIL PROTECTED]> writes:
> * I think we should get rid of the rsabase.dll entry on the status_dll site
> (and probably also in wine cvs): rsaenh.dll is a complete replacement and
> rsabase isn't shipped anymore by Microsoft since Win2k (Applications don't
> load rsabase/rsaenh d
Hi, I've had a regression with Creatures 2 between
and 2005-02-03 and 2005-02-19..
Creatures 2 makes heavy use of out-of-process COM for
it's components, the main screen used to work ok (but
the components didn't).
Now it starts up and I get the error.
"err:virtual:NtMapViewOfSection Sizes larg
The recent problems with -noname in shell32.spec got be to dig up an old
script I had which reads spec and dumpbin files and processes them. I
then retrofitted it so it could do some hopefully useful checks for this
kind of issues.
So this script works by comparing the output of winedump or dum
On Mon, Feb 21, 2005 at 04:57:05PM +0100, Paul Vriens wrote:
> On Mon, 2005-02-21 at 15:16, Paul Vriens wrote:
> > Hi (again),
> >
> > I've applied OLE#75 and OLE#76 and now I've something that doesn't look
> > right:
> >
> > trace (without OLE75/OLE76 and with native stdole32.tlb):
> >
> > 000b
Hi do you guys know anything about that already ?
It looks like some keys are not mapped correctly:
grep -r VK_* * | grep include/winuser.h
include/winuser.h:#define VK_LEFT 0x25
include/winuser.h:#define VK_UP 0x26
include/winuser.h:#define VK_RIGHT0x27
inclu
On Mon, 2005-02-21 at 15:16, Paul Vriens wrote:
> Hi (again),
>
> I've applied OLE#75 and OLE#76 and now I've something that doesn't look
> right:
>
> trace (without OLE75/OLE76 and with native stdole32.tlb):
>
> 000b:trace:ole:LoadTypeLib (L"C:\\windows\\system\\stdole32.tlb",0xa9d0dc)
> 000b:t
Hello,
I'm supposed to choose a topic - and work it out - for a "bachelor
project";
Now, at the moment I have no clue, and teachers are discussing what
topics to hand; in the mean time, I think maybe it might be interesting
to do some wine work in such a form that it's ok for this "bachelor
pro
On February 19, 2005 03:19 pm, Brian Vincent wrote:
> On Sat, 19 Feb 2005 13:25:17 -0700, Jesse Allen <[EMAIL PROTECTED]>
wrote:
> > On Wed, 16 Feb 2005 22:28:59 +0100, Ivan Leo Puoti <[EMAIL PROTECTED]>
wrote:
> > > By quickly looking at the program, I noticed it looks for a registry
> > > key,
Hi (again),
I've applied OLE#75 and OLE#76 and now I've something that doesn't look
right:
trace (without OLE75/OLE76 and with native stdole32.tlb):
000b:trace:ole:LoadTypeLib (L"C:\\windows\\system\\stdole32.tlb",0xa9d0dc)
000b:trace:ole:LoadTypeLibEx (L"C:\\windows\\system\\stdole32.tlb",0,0xa
Rob Shearman wrote:
Does this happen with only builtin oleaut32?
I'm not sure, I didn't try mixing native/builtins for this problem.
If so, it should be fixed
so that it doesn't cause an infinite loop. I don't think standard
marshaled proxies should cause infinite loops (if I remember the test
On Mon, Feb 21, 2005 at 10:58:31AM +0100, Lionel Ulmer wrote:
> Can you send me the same snippet of log but with the patch you sent the
> other day ? It's just to be sure that it correctly advertises the three new
> extensions you added in your patch :)
>
> If all the wglGetProcAddress lines were
On Mon, Feb 21, 2005 at 08:58:26AM +, Alex Woods wrote:
> Yes, doesn't look any different though. I did notice that with either
> patch I get this though:
>
> 0009:warn:opengl:wglGetProcAddress Did not find extension
> wglGetExtensionsStringARB in either Wine or your OpenGL library.
>
> Whe
On Mon, Feb 21, 2005 at 09:33:29AM +0100, Raphael wrote:
> Hi Alex,
>
> can you try this patch ?
Well, as even with adding the new extensions in the string reported to the
application via wglQueryExtensionStrings it does not try to get these
extensions, I wonder if the problem is really related t
On Mon, Feb 21, 2005 at 09:33:29AM +0100, Raphael wrote:
> can you try this patch ?
Yes, doesn't look any different though. I did notice that with either
patch I get this though:
0009:warn:opengl:wglGetProcAddress Did not find extension
wglGetExtensionsStringARB in either Wine or your OpenGL li
Hey Alex,
On Mon, 21 Feb 2005 09:33:29 +0100, Raphael <[EMAIL PROTECTED]> wrote:
> Hi Alex,
>
> can you try this patch ?
Just applied and tried. It doesn't seem to get the game any further. I
can provide you with a log if you like.
Paul
Hi Alex,
can you try this patch ?
Regards,
Raphael
> On Sun, Feb 20, 2005 at 01:43:44PM +0100, Lionel Ulmer wrote:
> > Well, if you want just to test if the application works better, just add
> > (stubbed) support for the following extensions:
> >
> > http://oss.sgi.com/projects/ogl-sample/regi
Dimitrie O. Paun wrote:
> Heh, the MinGW folks seem to have some strange requirements for their
headers, I don't think they'll drop theirs. But we can start by having
ReactOS adopt our headers.
We should also offer our headers as a separate package that works out
of the box as a replacement for th
Francois Gouget wrote:
__TRY {}/__FINALLY()? I'm not sure the changes I did are now compilable
under MSVC nor MingW.
4) Would there be a way to transform __try {}/__finally{} blocks to
Unfortunately they don't work exactly the same. There has been many
attempts to improve exception support in Wine
50 matches
Mail list logo
