Gibtsnich Gibtsauchnich wrote:
>
> Hello!
> I was wondering if there is any way to use a 16-bit-unicode-string with
> wine's TRACE, ERR or FIXME.
Yes, you can use "debugstr_w(unicode_string)", which will return the Unicode
string formatted so that it will display as an ANSI string. See
include/win
Hello!
I was wondering if there is any way to use a 16-bit-unicode-string with
wine's TRACE, ERR or FIXME.
I was thinking about something like:
WCHAR text={'b','l','a',0};
TRACE("%?s", text);
However, I found that these functions are a quite complicated wrapper around
vfprintf, wich only accepts
Well you can ignore my last message, from the source it's pretty obvious why
it doesn't work. Linuxisms !
At the very least it should be possible to declare a scsi device in the config
file and have it set up, IE one could probe each disk device declared for
scsi capability.
Possibly this shou
On March 20, 2004 3:42 pm, hatky wrote:
> tabs -> spaces (the cause of the bloated file)
You got to be kindin', right?
--
Dimi.
I am working on a Solaris CDROM plugin, but can't seem to get past the
configuration stage. I get
ASPI_GetNumControllers Could not open HKEY_DYN_DATA\WineScsi
How do I get wine to setup this key ?
Thanks
Bob
> I am kind of holding my breath for a regular build of winetest.exe - any
> chance for that soon? :-)
It depends on how you define regular. If you mean daily/weekly builds, I have no
idea. But I can build winetest.exe when I build the win32 packages, when A.J.
releases wine.
Ivan.
Ivan Leo Murray-Smith wrote:
So what we want is
wine-hdrs-.zip (headers)
wine-dlls-[-mingw].zip (2 packages with stripped and unstripped dlls)
wine-prgs-[-mingw].zip (2 packages with stripped and unstripped progs)
wine-w32api-[-mingw].zip (2 packages with stripped and unstripped libs)
right?
I
Dimitrie O. Paun wrote:
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
On March 20, 2004 8:01 am, Ivan Leo Murray-Smith wrote:
> So what we want is
> wine-hdrs-.zip (headers)
> wine-dlls-[-mingw].zip (2 packages with stripped and unstripped dlls)
> wine-prgs-[-mingw].zip (2 packages with stripped and unstripped progs)
> wine-w32api-[-mingw].zip (2 packages with stri
> The game checks if D3DDEVCAPS_HWTRANSFORMANDLIGHT flag is set in the
> device enumeration callback.
> If it is the case, the games fails saying there is no D3D device found.
> After all the enumeration, it checks the DRAWPRIMITIVE2EX flag. It it is
> not set it fails saying that the device is n
Lionel Ulmer wrote:
This makes Summoner recognize our D3D7 driver.
How did you find out ? Some R.E.ing of the game ?
Yes.
I ask this because I find it strange that a game would not be 'future proof'
and that it would refuse to run on future hardware that supports HW
transform and light.
I f
> Bug in binutils. A fix by Dimitry is in latest binutils.
OK, I'm rebuilding mingw with gcc-3.2.3-20030504-1,
binutils-2.15.90-20040222-1-src, mingw-runtime-3.2 and w32api-2.5, it should all
be up to date.
> MinGW folks split up the headers as well, (in their w32api package),
> and I think they a
On Sat, 2004-03-20 at 10:12, Lionel Ulmer wrote:
> But the problem is then what to do if another library FOO is used
> multi-threaded in Wine and require pthread emulation ? You can't really say
> 'OK, we emulate pthread for library FOO but not for OpenGL'.
Well thinking about it actually we could
> This makes Summoner recognize our D3D7 driver.
How did you find out ? Some R.E.ing of the game ?
I ask this because I find it strange that a game would not be 'future proof'
and that it would refuse to run on future hardware that supports HW
transform and light. You sure it's not just the addit
On Sat, 2004-03-20 at 10:12, Lionel Ulmer wrote:
> > The other approaches (marshalling etc) seem really not good to me.
>
> Yeah, but I fear it's the only way to go if we want to support all types of
> GL libraries out there (DRI, ATI and NVIDIA).
Or playing games with stack switches and hoping t
> Well, if shared context worked OK then I guess we could figure out a way
> to trick the GL libraries once again.
Well, an easy way to trick them is to re-break again the PTHREAD emulation
patch by reverting this :
http://cvs.winehq.com/patch.py?id=10090
But the problem is then what to do if
16 matches
Mail list logo
