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

re: Mixed-mode assembly support in Mono
by Dan Kegel April 28, 2008

April 28, 2008

Kornel wrote: > I have recently committed required changes to Mono SVN repository as r102052. > Now Mono has mixed-mode assembly support on Windows. Wow, congratulations! When will a windows installer be available for a version of mono with your changes included? It would make testing much easier. > These is no full MSVCRT support because that heavily depends > on the unmanaged API of .NET Framework but programs compiled using > Microsoft Visual C++ and not using MSVCRT should > be supported. Even exporting functions in managed DLLs is supported > that is supported by ildasm.exe and ilasm.exe as well. > > When the process is created using mono.exe there are some > limitations for executable assemblies but with a custom mscoree.dll > Mono has full support to create processes from managed executables. > > The attached mscoree.c is the source code for a custom mscoree.dll > that uses Mono for creating processes from executables. > I think that you should incorporate this into your mscoree.dll. We'll have a look, thanks. Do you happen to know of any real-world apps that would benefit? - Dan

2 1

Mixed-mode assembly support in Mono
by Kornél Pál April 28, 2008

April 28, 2008

Hi, I have recently committed required changes to Mono SVN repository as r102052. Now Mono has mixed-mode assembly support on Windows. These is no full MSVCRT support because that heavily depends on the unmanaged API of .NET Framework but programs compiled using Microsoft Visual C++ and not using MSVCRT should be supported. Even exporting functions in managed DLLs is supported that is supported by ildasm.exe and ilasm.exe as well. When the process is created using mono.exe there are some limitations for executable assemblies but with a custom mscoree.dll Mono has full support to create processes from managed executables. The attached mscoree.c is the source code for a custom mscoree.dll that uses Mono for creating processes from executables. I think that you should incorporate this into your mscoree.dll. Also note that you should only provide not implemented stubs in your mscoree.dll and implement missing functionality in Mono's coree.c if required. mscoree.c and http://anonsvn.mono-project.com/viewcvs/trunk/mono/mono/metadata/coree.c contains some comments about managed module support in ntdll.dll and msvcrt.dll of XP and later. If someone volunteers this could be implemented in Wine as well. Kornél

1 0

Re: ws2_32: Use WSAWaitForMultipleEvents instead of WaitForSingleObject
by Dmitry Timoshkov April 28, 2008

April 28, 2008

"Kai Blin" <kai.blin(a)gmail.com> wrote: > - HANDLE hEvent = INVALID_HANDLE_VALUE; > + WSAEVENT event_array[1]; Is that change only to avoid passing &hEvent to WSAWaitForMultipleEvents? -- Dmitry.

2 2

Re: [PATCH 2/7] widl: Keep const attributes applied to pointers when writing out the type.
by Alexandre Julliard April 28, 2008

April 28, 2008

Robert Shearman <rob(a)codeweavers.com> writes: > Use an attribute to store the const qualifier for the pointer and type. > > Allow multiple type-qualifiers to be applied to a type by adding a > declaration-specifier rule that encompasses type-qualifiers and types. This seems to drop the const in some cases, for instance: --- include/propidl.h.old 2008-04-28 13:52:01.000000000 +0200 +++ include/propidl.h 2008-04-28 13:52:11.000000000 +0200 @@ -332,7 +332,7 @@ virtual HRESULT STDMETHODCALLTYPE WritePropertyNames( ULONG cpropid, const PROPID rgpropid[], - const LPOLESTR rglpwstrName[]) = 0; + LPOLESTR rglpwstrName[]) = 0; virtual HRESULT STDMETHODCALLTYPE DeletePropertyNames( ULONG cpropid, -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] advapi32: attempt to use UuidToStringA if UuidToStringW isnot available.
by Dmitry Timoshkov April 28, 2008

April 28, 2008

"Lei Zhang" <thestig(a)google.com> wrote: > This adds more checks in CRYPT_CreateMachineGuid(), and attempt to use > UuidToStringA if UuidToStringW is not available. Instead of duplicating and complicating the code, IMO it would be more straightforward to use ansi APIs without trying unicode first. -- Dmitry.

2 1

Re: msvcrt: Remove two tests that fail on all platforms
by Eric Pouech April 27, 2008

April 27, 2008

James Hawkins a écrit : > Hi, > > Changelog > * Remove two tests that fail on all platforms. > > dlls/msvcrt/tests/cpp.c | 2 -- > 1 files changed, 0 insertions(+), 2 deletions(-) > > > ------------------------------------------------------------------------ > > the first one is actually bogus, I'll send a corrected test however, the second seems ok (except some space difference) can you post the failing test information ? A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 1

Re: [PATCH 6/7] widl: Accept integer constant suffixes in the lexer.
by Dan Hipschman April 27, 2008

April 27, 2008

On Sat, Apr 26, 2008 at 09:51:58AM +0100, Robert Shearman wrote: > +u_suffix (l|L) > +l_suffix (u|U) I'm guessing you meant for these to be the other way around.

2 1

Re: wined3d: Fix dead-loop condition with default setup.
by Vitaliy Margolen April 27, 2008

April 27, 2008

Vitaliy Margolen wrote: > As discussed in bug 11584 this Preload is wrong and should be removed. > --- > dlls/wined3d/context.c | 7 ------- > 1 files changed, 0 insertions(+), 7 deletions(-) > > BTW this is still not enough to fix all the problems. There are few more preloads that make Psychonauts crash. So I think that whole idea of using preload in the context switch is not right. Or activating context in texture pre-loading is wrong. Can some one familiar with this code take a closer look? This is basic functionality that should be working in 1.0 Vitaliy.

3 2

Wine64?
by Erik de Castro Lopo April 27, 2008

April 27, 2008

Hi all, I'm interested in the current state of work towards Wine64, ie running Win64 binaries on x86_64 Linux machines. My needs are actually really simple and hence may be a good base functionality to work towards. I just need to run Win64 binaries that read stdin, write stdout/stderr and do file I/O using the standard windows CreateFile/ReadFile/WriteFile/CloseHandle/ SetFilePointer etc functions. I have found and read this: http://wiki.winehq.org/Wine64 but some of that stuff seems rather out-of-date. When I configure with --enable-win64 it configures fine but then errors out in widl generated code because of things like this: #if !defined(__RPC_WIN32__) #error Currently only Wine and WIN32 are supported. #endif So, is anybody working on Wine64 stuff? Is there a Wine64 TODO list? Any way for me to get involved? Cheers, Erik -- ----------------------------------------------------------------- Erik de Castro Lopo ----------------------------------------------------------------- "If you have one apple and I have one apple, if we exchange, each will have one apple. If you have one idea and i have one idea, if we exchange them, each will have two ideas!" -- Attributed to George Bernard Shaw

4 3

Re: [dinput] initial support for BSD's usbhid joysticks
by Vitaliy Margolen April 27, 2008

April 27, 2008

Christoph Frick wrote: > Add dinput support for BSD's usbhid joysticks > > + if (have_joy_devs == 0) { > + joy_devs = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(struct JoyDev)); > + } else { > + HeapReAlloc(GetProcessHeap(), 0, joy_devs, (1 + have_joy_devs) * sizeof(struct JoyDev)); > + } > + joy_devs[have_joy_devs++] = joydev; > + > + hid_dispose_report_desc(rdesc); > + close(fd); > + } > +} This is ugly! Curly brackets should go on the separate line. And I asked no tabs please! And again you copied all the code - I'm against this. All the duplicate code should go into the new joystick base class. No reason to rewrite code if it can be written right the first time around. Vitaliy.

1 0