On 5/1/12 2:32 AM, Eric Pouech wrote:
This is the downside people in this thread are complaining about:
compiling 32-bit programs on a 64-bit Ubuntu install is now slightly
more difficult. However, Wine is currently the _only_ piece of
software I've encountered that needs to be built for both a
Dmitry Timoshkov wrote:
> --- a/dlls/gdi32/freetype.c
> +++ b/dlls/gdi32/freetype.c
> @@ -6677,8 +6677,8 @@ static BOOL get_outline_text_metrics(GdiFont *font)
> TM.tmWeight = pOS2->usWeightClass;
> }
> TM.tmOverhang = 0;
> -TM.tmDigitizedAspectX = 300;
> -TM.tmDigi
Am Dienstag, 8. Mai 2012, 13:31:00 schrieb Marcus Meissner:
> DOSBOX and DOSEMU can fall back to full emulation today, so vm86 not
> strictly required anymore these days. Speed is probably no longer an
> issue ;)
No, speed is still an issue. DOSBOX is too slow to run Settlers 2 and Screamer
2(aka
Christian Costa writes:
> ---
> dlls/dmsynth/dmsynth_private.h |1 +
> dlls/dmsynth/synthsink.c | 67
>
> 2 files changed, 68 insertions(+), 0 deletions(-)
It fails here:
../../../tools/runtest -q -P wine -M dmsynth.dll -T ../../.. -p
dmsy
2012/5/8 Henri Verbeet :
> I realize compile_shader() is mostly a copy of assemble_shader(), but
> nevertheless:
>
> On 8 May 2012 16:17, Matteo Bruni wrote:
>> +struct bwriter_shader *parse_hlsl_shader(const char *text, enum shader_type
>> type, DWORD version,
> If this isn't called outside of c
I realize compile_shader() is mostly a copy of assemble_shader(), but
nevertheless:
On 8 May 2012 16:17, Matteo Bruni wrote:
> +struct bwriter_shader *parse_hlsl_shader(const char *text, enum shader_type
> type, DWORD version,
If this isn't called outside of compiler.c it should be static.
> +
> This will cause warnings on 64-bit.
Casting a pointer to a DWORD?
Well, any 64-bit image that reaches that line would be broken, so I
don't think there's any more correct thing to do. I'd rather not
change the code depending on architecture just to avoid a warning.
David Laight writes:
> Does wine support running of 16bit windows apps?
> If so does it rely on the underlying OS having support
> for 'virtual 8086 emulation'?
>
> I'm thinking of removing the VM86 support from NetBSD,
> and wine is about the only likley user.
Wine is not going to use vm86 on N
Vincent Povirk writes:
> +if (fixup->fixup->type & COR_VTABLE_32BIT)
> +{
> +DWORD *vtable = fixup->vtable;
> +DWORD *tokens = fixup->tokens;
> +for (i=0; ifixup->count; i++)
> +{
> +TRACE("%x\n", tokens[i]);
> +
On Tue, May 08, 2012 at 12:06:23PM +0100, David Laight wrote:
> On Tue, May 08, 2012 at 12:03:52PM +0200, Damjan Jovanovic wrote:
> > On Tue, May 8, 2012 at 11:40 AM, David Laight wrote:
> > > Does wine support running of 16bit windows apps?
> > > If so does it rely on the underlying OS having sup
On Tue, May 08, 2012 at 12:03:52PM +0200, Damjan Jovanovic wrote:
> On Tue, May 8, 2012 at 11:40 AM, David Laight wrote:
> > Does wine support running of 16bit windows apps?
> > If so does it rely on the underlying OS having support
> > for 'virtual 8086 emulation'?
> >
> > I'm thinking of removin
On Tue, May 8, 2012 at 11:40 AM, David Laight wrote:
> Does wine support running of 16bit windows apps?
> If so does it rely on the underlying OS having support
> for 'virtual 8086 emulation'?
>
> I'm thinking of removing the VM86 support from NetBSD,
> and wine is about the only likley user.
>
>
Does wine support running of 16bit windows apps?
If so does it rely on the underlying OS having support
for 'virtual 8086 emulation'?
I'm thinking of removing the VM86 support from NetBSD,
and wine is about the only likley user.
David
--
David Laight: da...@l8s.co.uk
13 matches
Mail list logo
