Re: Ubuntu 12.04 (version#2, drop previous mail)
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 arches on
the same machine in order to be usable. We are beautiful special
snowflakes here: Wine developers who aren't using the build daemons is
about the extent of the current use case.
I'm beginning to have memories of what happened when we removed gcc
from the default install. Setting up a 32-bit chroot for building Wine
should not be complicated -- I'll present a script to make it even
easier soon. You can build in a single command and even use things
like ccache and the like to speed it up.
to summarize:
ubuntu doesn't do anything to support developers
as it implies using ubuntu build daemons, not developers' machine (and
all the relevant environment)
as it implies to use chroot even on a multi lib arch => multi arch is
then for users, not developers
bye bye ubuntu then
If this is a blocker for you then I can't blame you then.
For reference the only successful way to build Wine I'm aware of is
http://wiki.winehq.org/Wine64ForPackagers under the "Alternatives"
section (ie, manually configuring and building 32 and 64 separately and
copying files from one into the other.) You may be able to do that
without a chroot (or something similar like pbuilder),
for the sake of record (I won't even dare to send it to wine-patches) a
workaround ubuntu recvmsg breakage in order to get ptrace API to be
usable on 12.04
diff --git a/dlls/ntdll/server.c b/dlls/ntdll/server.c
index 8a01d22..6c8e759 100644
--- a/dlls/ntdll/server.c
+++ b/dlls/ntdll/server.c
@@ -1016,6 +1016,37 @@ void server_init_process(void)
send_server_task_port();
#endif
#if defined(__linux__) && defined(HAVE_PRCTL)
+ /* work around Ubuntu's recvmsg breakage */
+ if (!server_pid)
+ {
+ int zfd;
+ struct flock fl;
+ char tmp[4096];
+ strcpy(tmp, wine_get_server_dir());
+ strcat(tmp, "/");
+ strcat(tmp, LOCKNAME);
+
+ if ((zfd = open( tmp, O_RDONLY )) == -1)
+ fatal_error( "no lock present %s.\n", tmp );
+
+ fl.l_type = F_WRLCK;
+ fl.l_whence = SEEK_SET;
+ fl.l_start = 0;
+ fl.l_len = 1;
+ if (fcntl( zfd, F_GETLK, &fl ) != -1)
+ {
+ if (fl.l_type == F_WRLCK)
+ {
+ /* the file is locked */
+ fprintf(stderr, "getting server_pid from lock %d\n", fl.l_pid);
+ server_pid = fl.l_pid;
+ }
+ fatal_error( "cannot get pid from lock (lock isn't locked)\n");
+ }
+ else
+ fatal_error( "cannot get pid from lock\n");
+ close(zfd);
+ }
/* work around Ubuntu's ptrace breakage */
if (server_pid != -1) prctl( 0x59616d61 /* PR_SET_PTRACER */, server_pid );
#endif
I showed this to the developer who originally wrote the kernel ptrace
stuff, and indeed this seems like an upstream kernel bug, albeit in
recvmsg rather than ptrace (also note that the ptrace stuff is now in
the mainline kernel as well, not just Ubuntu, so you may have found a
problem that was just exposed in Ubuntu first).
Anyway, I'll follow up on it. In the meantime I'm pushing your patch in
a stable release update for Wine (once I test another thing), so thank
you very much for it.
Thanks,
Scott Ritchie
Re: [2/5] gdi32: Set tmDigitizedAspectX/Y to 96 instead of 300 for consistency.
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.tmDigitizedAspectY = 300; > +TM.tmDigitizedAspectX = 96; /* FIXME */ > +TM.tmDigitizedAspectY = 96; /* FIXME */ A couple of comments to the patch: 1. the values should be set to the resolution of the target device, and 96 looks more natural since most of the time the device is a display. 2. the change is for consystency with get_bitmap_text_metrics() which sets these values to 96. 3. even if this pacth is rejected, other patches in the sequence should not be affected by it. -- Dmitry.
Re: running 16bit code
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 Bleifuß 2) on my Core 2 Duo CPU. Dosemu works for Settlers 2(I estimate that it is about 20 times faster), and Screamer 2 works with some 3DFX hacks that move the graphics calculations into the GPU. Ok, I realize that this is borderline off-topic, and both games aren't real mode apps strictly speaking, but 32 bit protected mode DOS/4G programs. They still need 16 bit real mode to launch though.
Re: [PATCH 4/4] dmsynth: Add stubbed IKsControl interface to DirectMusicSynthSink object.
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 dmsynth_test.exe.so dmsynth.c && touch dmsynth.ok dmsynth.c:56: Test succeeded inside todo block: IDirectMusicSynthSink_QueryInterface returned: 0 make: *** [dmsynth.ok] Error 1 -- Alexandre Julliard julli...@winehq.org
Re: [PATCH 5/5] d3dcompiler: Partially implement D3DCompile function.
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 compiler.c it should be static. > This is going to change in the following patches, but yeah, right now it can be static. >> + LPD3DBLOB buffer; > "ID3DBlob *" > >> + CopyMemory(pos, preproc_messages, strlen(preproc_messages) >> + 1); > memcpy() should do fine. > >> + hr = SlWriteBytecode(shader, 9, &res); > ... >> + size = HeapSize(GetProcessHeap(), 0, res); >> + hr = D3DCreateBlob(size, &buffer); > That's not very pretty, SlWriteBytecode() should probably just return > the size as well. > > True. I'll change that in assemble_shader() too, while I'm at it.
Re: [PATCH 5/5] d3dcompiler: Partially implement D3DCompile function.
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. > +LPD3DBLOB buffer; "ID3DBlob *" > +CopyMemory(pos, preproc_messages, strlen(preproc_messages) + > 1); memcpy() should do fine. > +hr = SlWriteBytecode(shader, 9, &res); ... > +size = HeapSize(GetProcessHeap(), 0, res); > +hr = D3DCreateBlob(size, &buffer); That's not very pretty, SlWriteBytecode() should probably just return the size as well.
Re: mscoree: Implement vtable fixups.
> 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.
Re: running 16bit code
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 NetBSD. In fact it will probably stop using vm86 on Linux in the near future. Note that 16-bit Windows apps don't need vm86, only DOS apps do. -- Alexandre Julliard julli...@winehq.org
Re: mscoree: Implement vtable fixups.
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]);
> +vtable[i] =
> (DWORD)host->mono->mono_marshal_get_vtfixup_ftnptr(
> +image, tokens[i], fixup->fixup->type);
This will cause warnings on 64-bit.
--
Alexandre Julliard
julli...@winehq.org
Re: running 16bit code
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 support > > > for 'virtual 8086 emulation'? > > > > > > I'm thinking of removing the VM86 support from NetBSD, > > > and wine is about the only likely user. > > > > > > ? ? ? ?David > > > > > > -- > > > David Laight: da...@l8s.co.uk > > > > > > > > > > 16 bit Windows applications are written and compiled to either use > > real mode or 16 bit protected mode. > > Those that use real mode (mostly MS-DOS and Windows 1 and 2 > > applications) need virtual 8086 mode. > > Those that use protected mode (mostly Windows >= 3.0 applications) > > don't need virtual 8086 mode. > > Ok, so wine users would be very unlikely to be affected. > Since most of the 16bit apps post-date windows 3. Correct. > > You'd break DOSBOX a lot more than Wine. > > Possibly, although some emulators are probably better bets for DOS. > > > But why do you want to remove > > this from NetBSD? I thought compatibility with other operating systems > > was one of its major features? > > Mainly because it isn't used much, and may well contain security holes. > There are two separate kernel options VM86 (usually enabled) and > KVM86 (usually disabled). > Both change some low level code is obscure ways. for what it is worth... 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 ;) Ciao, Marcus
Re: running 16bit code
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 removing the VM86 support from NetBSD, > > and wine is about the only likely user. > > > > ? ? ? ?David > > > > -- > > David Laight: da...@l8s.co.uk > > > > > > 16 bit Windows applications are written and compiled to either use > real mode or 16 bit protected mode. > Those that use real mode (mostly MS-DOS and Windows 1 and 2 > applications) need virtual 8086 mode. > Those that use protected mode (mostly Windows >= 3.0 applications) > don't need virtual 8086 mode. Ok, so wine users would be very unlikely to be affected. Since most of the 16bit apps post-date windows 3. > You'd break DOSBOX a lot more than Wine. Possibly, although some emulators are probably better bets for DOS. > But why do you want to remove > this from NetBSD? I thought compatibility with other operating systems > was one of its major features? Mainly because it isn't used much, and may well contain security holes. There are two separate kernel options VM86 (usually enabled) and KVM86 (usually disabled). Both change some low level code is obscure ways. David -- David Laight: da...@l8s.co.uk
Re: running 16bit code
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. > > David > > -- > David Laight: da...@l8s.co.uk > > 16 bit Windows applications are written and compiled to either use real mode or 16 bit protected mode. Those that use real mode (mostly MS-DOS and Windows 1 and 2 applications) need virtual 8086 mode. Those that use protected mode (mostly Windows >= 3.0 applications) don't need virtual 8086 mode. You'd break DOSBOX a lot more than Wine. But why do you want to remove this from NetBSD? I thought compatibility with other operating systems was one of its major features? Damjan
running 16bit code
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
