On March 19, 2004 8:13 pm, Alexandre Julliard wrote:
> Also the whole file has been reformatted, making it impossible to see
> what changed. Please don't do that.
One more note: the file seems to have been edited with a tab
setting of 4. Please don't redefine tab, keep it to the standard 8,
other
Steven Edwards <[EMAIL PROTECTED]> writes:
> We found quite a few problems using version.dll on ReactOS and Windows
> XP. According to Royce there was a issue regarding ANSI converion that
> was causing applications (Winzip) to fail to load. Also we found that
> Microsoft doesnt support reading of
On Fri, 19 Mar 2004 19:09:39 +0100, Lionel Ulmer wrote:
> It worked before because our pthread emulation was broken which lead the GL
> libraries to not find out at all that they were running in a multi-threaded
> environment (so the contxt was 'shared' between threads).
Well, if shared context wo
--- Hans Leidekker <[EMAIL PROTECTED]> wrote:
> Some networking related dlls rely heavily on Unix networking APIs. It
>
> will probably take a while before they are rewritten to build on
> MinGW (with help from ReactOS perhaps?).
I tried to fix wininet but the WINE winsock headers are kind of
> After google-ing a bit I think it is necessary to make a
> glXmakeCurrent() call before using a gl-call in a new thread (at least
> for the Nvidia GL-driver, DRI should work). Not all GL-calls are
> affected but definitely the textures calls.
Well, as said before, Wine is completely broken regar
--- "Gregory M. Turner" <[EMAIL PROTECTED]> wrote:
> o Not the best win32 support AFAIK
We already turn way to many Win32 developers off to WINE as it is.
__
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com
> > I'm now sure that the call to glGenTextures didn't return. I can think
> > of three reasons:
> >
> > 1. Another wine thread is just doing a call to libGL
> > 2. The libGL of Nvidia has a bug
> > 3. both of the above
>
> If you run with +ddraw,+tid and you get two different numbers before the
>
On Fri, 19 Mar 2004, Hans Leidekker wrote:
> > That's a good idea. In fact, maybe 3 packages: programs, dlls, headers:
> > wine-prgs-[-mingw].zip
> > wine-dlls-[-mingw].zip
> > wine-hdrs-.zip
> >
> > MinGW folks split up the headers as well, (in their w32api package),
> > and I think
On Friday 19 March 2004 14:21, Dimitrie O. Paun wrote:
> That's a good idea. In fact, maybe 3 packages: programs, dlls, headers:
> wine-prgs-[-mingw].zip
> wine-dlls-[-mingw].zip
> wine-hdrs-.zip
>
> MinGW folks split up the headers as well, (in their w32api package),
> and I th
On March 19, 2004 7:54 am, Hans Leidekker wrote:
> I think it would be nice if we provided just two packages: one
> with PE versions of our programs. Just the relevant ones that
> actually build, so no winecfg or winedbg for example, and a
> second package with PE dlls that build.
That's a good id
On Wednesday 17 March 2004 18:05, Ivan Leo Murray-Smith wrote:
> > Can you please post the list of errors to wine-devel, so people are aware of the
> > problems (and hopefully send patches to fix them :))?
> Complete compile error log is attached.
../../../wine-src/tools/winebuild/spec32.c: In
Kevin Koltzau wrote:
IE overrides MIME types for more then just ambiguous types, to quote one test mentioned in the appendix
"If the server-provided MIME type is either known or ambiguous, the buffer is scanned
in an attempt to verify
or obtain a MIME type from the actual content. If a positive
12 matches
Mail list logo
