February 2008 - Wine-Devel - list.winehq.org

Re: [Wine] How about this replacement of WINE.

by David Gerard

On 28/02/2008, Dan Kegel <dank(a)kegel.com> wrote: > We would, I think, like to move wineserver into the kernel > sometime. It's been discussed before. Linus is not > opposed to having native support for win32 system calls. > A fellow at Redhat wrote a kernel module for wine a number > of years ago, but it just wasn't time yet. If Wine works, what would you gain by moving it out of userspace? - d.

Feb. 28, 2008

Re: [Wine] How about this replacement of WINE.

by Dan Kegel

On Thu, Feb 28, 2008 at 8:47 AM, DARKGuy . <dark.guy.2008(a)gmail.com> wrote: > However, it's a great, great project IMO. It was about time something like > that should've been made. Redirecting calls is simply acting as a proxy, > instead of emulating. Wine is not an emulator. No emulation is going on anyway. We would, I think, like to move wineserver into the kernel sometime. It's been discussed before. Linus is not opposed to having native support for win32 system calls. A fellow at Redhat wrote a kernel module for wine a number of years ago, but it just wasn't time yet. For a related BSD thingy, see http://www.kernel-traffic.org/wine/wn20010313_87.html#1 That project was still going as of 2006, I think, but didn't get terribly far. - Dan

Feb. 28, 2008

Re: [Wine] How about this replacement of WINE.

by Steven Edwards

On Thu, Feb 28, 2008 at 11:37 AM, Dan Kegel <dank(a)kegel.com> wrote: > It's not a wine replacement; it uses wine. > Better description at > http://www.reactos.org/forum/viewtopic.php?t=5240 > > It looks like they added hooks to the linux kernel > to accept windows nt syscalls. Maybe they even allow using the > system's normal shared library loader instead of Wine's > special one. This is something > I've often wanted to do, but it was way lower priority > than getting wine working. I haven't looked at their > project at all, no idea if it was done well. A long long time ago there was a project called Captive NTFS that was mostly the same idea but in userspace, They tool the ReactOS kernel, combined it with FUSE, and used that to load the native ntfs.sys. It actually took a little more work because ReactOS Cache Manager was so broken (another sign there is no way in hell the code was stolen from Microsoft) that the author had to profile the native ntfs.sys and rewrite the entire Cache Manger in glib. It would not have been much of a stretch to add support for Win32 applications on top using Wine. This might end up being a better solution for certain device drivers like the copyprotection systems. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

Feb. 28, 2008

Re: [Wine] How about this replacement of WINE.

by DARKGuy .

However, it's a great, great project IMO. It was about time something like that should've been made. Redirecting calls is simply acting as a proxy, instead of emulating. However, it makes it only to be usable in Linux... but hey, this is genius. On Thu, Feb 28, 2008 at 12:07 PM, Dan Kegel <dank(a)kegel.com> wrote: > On Thu, Feb 28, 2008 at 8:26 AM, bussuser <wineforum-user(a)winehq.org> > wrote: > > http://www.reactos.org/forum/viewtopic.php?t=5240 > > > > It is based on WINE and ReactOS . > > It's not a wine replacement; it uses wine. > Better description at > http://www.reactos.org/forum/viewtopic.php?t=5240 > > It looks like they added hooks to the linux kernel > to accept windows nt syscalls. Maybe they even allow using the > system's normal shared library loader instead of Wine's > special one. This is something > I've often wanted to do, but it was way lower priority > than getting wine working. I haven't looked at their > project at all, no idea if it was done well. > - Dan > >

Feb. 28, 2008

Re: [Wine] How about this replacement of WINE.

by Dan Kegel

On Thu, Feb 28, 2008 at 8:26 AM, bussuser <wineforum-user(a)winehq.org> wrote: > http://www.reactos.org/forum/viewtopic.php?t=5240 > > It is based on WINE and ReactOS . It's not a wine replacement; it uses wine. Better description at http://www.reactos.org/forum/viewtopic.php?t=5240 It looks like they added hooks to the linux kernel to accept windows nt syscalls. Maybe they even allow using the system's normal shared library loader instead of Wine's special one. This is something I've often wanted to do, but it was way lower priority than getting wine working. I haven't looked at their project at all, no idea if it was done well. - Dan

Feb. 28, 2008

Heap corruption in crypt32?

by Dan Kegel

I strolled down memory lane a bit, and revisited the Sandra benchmark today, see http://www.winehq.org/pipermail/wine-devel/2006-December/052821.html Now the win2k version gets a lot farther. To install, first do sh winetricks vcrun2005sp1 gdiplus (Without native gdiplus, the installer complains you don't have it; without vcrun2005sp1, you get a few errors like fixme:actctx:parse_assembly_elem wrong version for assembly manifest.) The installer claims to be happy, but one sees err:module:import_dll Library CRYPTUI.dll (which is needed by L"C:\\windows\\temp\\is-KH13O.tmp\\certmgr.exe") not found err:module:LdrInitializeThunk Main exe initialization for L"C:\\windows\\temp\\is-KH13O.tmp\\certmgr.exe" failed, status c0000135 Could not get handle to service. on the console. Worse, when the app starts up, you get a heap error: err:heap:HEAP_ValidateInUseArena Heap 0x7f000000: in-use arena 0x7f02e2e0 next block has PREV_FREE flag err:heap:HEAP_ValidateInUseArena Heap 0x7f000000: bad back ptr 0x1c9ba51e for arena 0x7f02e798 I suppose that could be a result of cryptui being missing, but I ran it under valgrind anyway. This turned up interesting items like ==20325== Invalid read of size 1 ==20325== at 0x46F5E49: HEAP_CreateFreeBlock (heap.c:486) ==20325== by 0x46F621D: HEAP_ShrinkBlock (heap.c:575) ==20325== by 0x46F7979: RtlAllocateHeap (heap.c:1228) ==20325== by 0x5C60B74: new_object (handle.c:441) ==20325== by 0x5C6B1CD: new_key (rsaenh.c:830) ==20325== by 0x5C6C9DB: RSAENH_CPImportKey (rsaenh.c:2464) ==20325== by 0x4B4324A: CryptImportKey (crypt.c:1767) ==20325== by 0x4F2DCDC: CRYPT_ImportRsaPublicKeyInfoEx (encode.c:3923) ==20325== by 0x4F2DA3B: CryptImportPublicKeyInfoEx (encode.c:3955) ==20325== by 0x4F183FA: CRYPT_VerifyCertSignatureFromPublicKeyInfo (cert.c:1641) ==20325== by 0x4F1B069: CryptVerifyCertificateSignatureEx (cert.c:1723) ==20325== by 0x4F1EDCD: CRYPT_CheckSimpleChain (chain.c:744) ==20325== Address 0x7f02ecf8 is not stack'd, malloc'd or (recently) free'd quite early in the run (well before the heap errs). Juan, what do you make of it? Might this be a real bug in crypt32 or our heap? - Dan

Feb. 28, 2008

Re: winejoystick.drv: Add axis remapping support

by Vitaliy Margolen

Adolfo R. Brandes wrote: > Hi there, > > On Wed, Feb 27, 2008 at 3:44 PM, Vitaliy Margolen > <wine-devel(a)kievinfo.com> wrote: >> Don't do that. Keep it uniform. As-is it's a pain to configure. You want to >> introduce even more? > > Actually, this was my shot at improving that particular aspect of > the configuration. As it is in dinput/joystick_linux.c, it's a bit of > a shot in the dark as to what is "Slider1", "Slider2", and so on. The > way I did it, you can run jstest to find out what each of your axes > are named, and use those names in regedit. > > I realize this introduces confusion. It's just that I think the > previous standard requires a bit of a revision, in that there should > be a more reliable way of determining what each axis in your joystick > is called (and what wine expects it to be called). Maybe > joystick_linux should be patched too? I'm not sure I like this. The names dinput joystick uses are the names windows uses in number of place. Also they are mentioned on MSDN and part of the API. Also for backwards compatibility if you change dinput joystick that means it will break all current configurations. Not that I like the way it's done now. But it needs to be part of the winecfg for example. Then it wouldn't matter what we use internally. >> Disabling axis might not be a bad thing, especially for testing. I don't >> think you need to worry about extra axis on the device that are not mapped >> to anything. > > I was worried about having two (or more) linux axes mapped to the > same wine one. That's the reason behind the fatal error. > Then you check for that particular case. >> Also what about multiple POVs? Here you checking for only one. > > It seems that the only pertinent JOYINFOEX constants from mmsystem.h > are "JOY_HASPOV" and "JOY_RETURNPOV". No "JOY_HASPOV2" ou > "JOY_RETURNPOV2". I'm assuming that more hats simply won't register. > Bear with me, everything I know about the Windows joystick API has > been gathered from reading this driver, and it seems like there's a > fundamental difference between DirectInput devices and "regular" ones. > Correct me if I'm wrong, but it looks to me like multiple POVs (or > more than 6 axes) aren't supported here. Yeah it seems the old interface does not support more then one POV. Sorry missed that. >> Now that you can remap axis it's not guaranteed that 6th axes is the speed >> and so on. > > Yes, that's correct. I previously tried a different approach, > basing the selection of x, y, z, r, u, and v on what the axis is > actually named (i.e., "Throttle" = z, "Rudder" = r), but that actually > moots the whole point. It turns out that it doesn't matter what the > axis' nominal function is; what matters is the order in which they > appear. For instance, my joystick's rudder is actually named "Rz", > which would wrongly map to "v" (as opposed to "r"). What's important > is not for wine to know the difference between "Throttle" and > "Rudder", but for the user to know what each axis is named and in what > order they are presented to the application, so that he can then > reoder them as he pleases. > I see, then you should also check for any gaps in mapping. If user skipped one axes it won't work. Vitaliy.

Feb. 28, 2008

Re: Valgrind can't *quite* handle Adobe InDesign yet

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > On Thu, Feb 28, 2008 at 6:46 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> For debugging you can disable use of fxrstor > > Thanks. What's the downside? I imagine apps that use floating > point inside exception handlers will break? Floating point will still work, but apps using the MMX/SSE registers will break. -- Alexandre Julliard julliard(a)winehq.org

Feb. 28, 2008

Re: Valgrind can't *quite* handle Adobe InDesign yet

by Dan Kegel

On Thu, Feb 28, 2008 at 6:46 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > For debugging you can disable use of fxrstor Thanks. What's the downside? I imagine apps that use floating point inside exception handlers will break? - Dan

Feb. 28, 2008

Re: Valgrind can't *quite* handle Adobe InDesign yet

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > http://bugs.kde.org/show_bug.cgi?id=126389 > means that valgrind can't yet handle apps that > throw exceptions during regular operation. > Like, say, Adobe InDesign's installer. > I would like to valgrind that to track down > http://bugs.winehq.org/show_bug.cgi?id=11757 > but I can't because valgrind doesn't handle fxrestor. For debugging you can disable use of fxrstor with this: diff --git a/dlls/ntdll/signal_i386.c b/dlls/ntdll/signal_i386.c index a6ca6fd..8ba0590 100644 --- a/dlls/ntdll/signal_i386.c +++ b/dlls/ntdll/signal_i386.c @@ -125,7 +125,7 @@ typedef ucontext_t SIGCONTEXT; #define ERROR_sig(context) ((context)->uc_mcontext.gregs[REG_ERR]) #define FPU_sig(context) ((FLOATING_SAVE_AREA*)((context)->uc_mcontext.fpregs)) -#define FPUX_sig(context) (FPU_sig(context) && !((context)->uc_mcontext.fpregs->status >> 16) ? (XMM_SAVE_AREA32 *)(FPU_sig(context) + 1) : NULL) +#define FPUX_sig(context) NULL #define VM86_EAX 0 /* the %eax value while vm86_enter is executing */ -- Alexandre Julliard julliard(a)winehq.org

Feb. 28, 2008