[Fwd: Re: About the WWN]
Hello. As indicated by Zachary, I post the suggestion I made him on the wine-devel list. The suggestion was : what do you think about writing in the WWN an article about what did the last changes of the last release brought? I mean, knowing that there is a ton of rpcrt4 fixes or New Bidi text implementation that doesn't depend on libicu is really great, but from a user point of view it doesn't mean anything. It would be great if you'd explain us the problems it solves and which opportunities it gives. What he replies is that he need your help ! Thanks. François. --- Original Message --- Subject: Re: About the WWN From:Zachary Goldberg [EMAIL PROTECTED] Date:Tue, December 18, 2007 19:50 To: François Guerraz [EMAIL PROTECTED] Francois, If you could do me a favor of suggesting your second point on the wine-devel mailing list then we could start a discussion for it. I think it would be a good idea; however It would require perhaps a bit more detail being made in the commit comments to WINE so that I can go through them and put together the real changes. --Zach On Dec 18, 2007 1:47 PM, François Guerraz [EMAIL PROTECTED] wrote: Hello. First of all : thank you so much for being the new author of the WWN. I am a fervent reader and I was really upset that it was almost never written. I hope you'll find this task interesting and that you won't be fed up with it too quick :) Second I have a suggestion to make : what do you think about writing in the WWN an article about what did the last changes of the last release brought? I mean, knowing that there is a ton of rpcrt4 fixes or New Bidi text implementation that doesn't depend on libicu is really great, but from a user point of view it doesn't mean anything. It would be great if you'd explain us the problems it solves and which opportunities it gives. Thank you for your time and implication. Regards, François Guerraz [EMAIL PROTECTED] -- Zachary Goldberg Computer Science Engineering Electrical Captain of Penn Electric Race Team School of Engineering at the University of Pennsylvania
RE: [PATCH] Implement BindIoCompletionCallback
Andrey Turkin wrote:
diff --git a/dlls/kernel32/tests/sync.c b/dlls/kernel32/tests/sync.c
index e402fed..7bbb3e2 100644
--- a/dlls/kernel32/tests/sync.c
+++ b/dlls/kernel32/tests/sync.c
@@ -327,7 +327,7 @@ static void test_iocp_callback(void)
retb = p_BindIoCompletionCallback(hFile, iocp_callback, 0);
ok(retb == FALSE, BindIoCompletionCallback succeeded on a file that
wasn't created with FILE_FLAG_OVERLAPPED\n);
if(retb == FALSE GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) {
-todo_wine ok (0, BindIoCompletionCallback returned
ERROR_CALL_NOT_IMPLEMENTED\n);
+ok (0, BindIoCompletionCallback returned
ERROR_CALL_NOT_IMPLEMENTED\n);
return;
}
I don't think this check makes much sense after the change anymore. It's at
best a skip() for older Windows versions.
Rolf Kalbermatter
Re: [msiexec] A nicer icon
Hervÿe9 Chanal [EMAIL PROTECTED] writes: Hello, It's a larger nicer icon for msiexec with the svg source. Having icons in .svg format is a nice improvement, but we'll need a tool to build the .ico from the .svg. We also need to include multiple sizes in the .ico, most places want a 32x32 icon, and scaling down the 48x48 looks bad. Of course we should also look into taking advantage of the larger size where that's possible without breaking compatibility. -- Alexandre Julliard [EMAIL PROTECTED]
Re: [PATCH 2/3] qmgr: AddRef, QueryInterface, and stub functions for queue manager interface.
Roy Shea [EMAIL PROTECTED] writes:
+static ULONG WINAPI BITS_IBackgroundCopyManager_AddRef(
+IBackgroundCopyManager* iface)
+{
+ICOM_THIS_MULTI(BackgroundCopyManagerImpl, lpVtbl, iface);
There's no reason to use ICOM_THIS_MULTI with a single vtbl.
+if (This == NULL)
+{
+return E_POINTER;
+}
Checking This for NULL is a waste of time.
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: [PATCH] Implement BindIoCompletionCallback
Andrey Turkin wrote: Robert Shearman wrote: Andrey Turkin wrote: /** *BindIoCompletionCallback (KERNEL32.@) */ +extern NTSTATUS WINAPI RtlSetIoCompletionCallback(HANDLE,LPOVERLAPPED_COMPLETION_ROUTINE,ULONG); This should go in winternl.h. winternl.h may not depend on winbase.h for some reason, so this would mean either changing prototype to (HANDLE,LPVOID,ULONG), which seems wrong, or redefining LPOVERLAPPED_COMPLETION_ROUTINE and OVERLAPPED/LPOVERLAPPED, which seems to be too much duplication. I think you should guard the function with an #ifdef __WINE_WINBASE_H statement, but I would wait for some other developers to chime in to get a consensus before accepting this though. -- Rob Shearman
Re: [PATCH] Implement BindIoCompletionCallback
Robert Shearman [EMAIL PROTECTED] writes: Andrey Turkin wrote: Robert Shearman wrote: Andrey Turkin wrote: /** *BindIoCompletionCallback (KERNEL32.@) */ +extern NTSTATUS WINAPI RtlSetIoCompletionCallback(HANDLE,LPOVERLAPPED_COMPLETION_ROUTINE,ULONG); This should go in winternl.h. winternl.h may not depend on winbase.h for some reason, so this would mean either changing prototype to (HANDLE,LPVOID,ULONG), which seems wrong, or redefining LPOVERLAPPED_COMPLETION_ROUTINE and OVERLAPPED/LPOVERLAPPED, which seems to be too much duplication. I think you should guard the function with an #ifdef __WINE_WINBASE_H statement, but I would wait for some other developers to chime in to get a consensus before accepting this though. It doesn't seem right for an ntdll function to use an OVERLAPPED pointer. Shouldn't it take an IO_STATUS_BLOCK instead? -- Alexandre Julliard [EMAIL PROTECTED]
Re: Patch for process title on FreeBSD
How exactly would you like that done? I'm not much of a C programmer, I
live more in the C++ / Shell world :)
--
Kris Moore
PC-BSD Software
http://www.pcbsd.com
Alexandre Julliard wrote:
Kris Moore [EMAIL PROTECTED] writes:
--- dlls/kernel32/process.c.orig 2007-12-12 12:34:45.0 -0500
+++ dlls/kernel32/process.c 2007-12-12 12:35:17.0 -0500
@@ -853,6 +853,11 @@
*/
static void set_process_name( int argc, char *argv[] )
{
+
+#if defined(__FreeBSD__)
+setproctitle(-%s, argv[1]);
+#endif
You should add a configure check for this function, instead of checking
for __FreeBSD__.
Re: Early wine history
I found this announcement from Bob Amstadt announcing the mailing list, this was dated September 16, 1993: http://groups.google.com/group/comp.windows.x.i386unix/browse_thread/thread/ee272fa922314342/a08260429f730cdf But according to this status report, it was started in early June 1993: http://groups.google.com/group/comp.windows.x.i386unix/browse_thread/thread/88fbd87c0ae2e48f/5003eb8ed33ae522 Which makes your June 1, 1993 date sound about right :-). Looking a bit further in that discussion, you can see Eric making a call for volunteers the next day: http://groups.google.com/group/comp.os.linux/msg/106b5f2702b1c53d -Austin On Dec 19, 2007 12:26 AM, Dan Kegel [EMAIL PROTECTED] wrote: winehq.org doesn't seem to have a link to the message that launched the wine project, so I went looking. The first message I found contemplating it was dated 1 Jun 1993, http://groups.google.com/group/comp.os.linux/msg/0a7c3867abdb4a76 Is that about the right estimate for Wine's birthday? A roughly 1995 writeup about Wine is at http://www.softlookup.com/tutorial/redhat/rhl58.asp It has a screen shot of a game Pipe Dream running under Wine. I just checked; the game is still online at http://members.chello.at/theodor.lauppert/games/pipe1.htm and runs well on today's wine :-)
Re: Patch for process title on FreeBSD
Hi Kris, Kris Moore schreef: How exactly would you like that done? I'm not much of a C programmer, I live more in the C++ / Shell world :) With autoconf of course (configure.ac). Cheers, Maarten.
Re: [PATCH] Implement BindIoCompletionCallback
Alexandre Julliard wrote: Robert Shearman [EMAIL PROTECTED] writes: Andrey Turkin wrote: Robert Shearman wrote: Andrey Turkin wrote: /** *BindIoCompletionCallback (KERNEL32.@) */ +extern NTSTATUS WINAPI RtlSetIoCompletionCallback(HANDLE,LPOVERLAPPED_COMPLETION_ROUTINE,ULONG); This should go in winternl.h. winternl.h may not depend on winbase.h for some reason, so this would mean either changing prototype to (HANDLE,LPVOID,ULONG), which seems wrong, or redefining LPOVERLAPPED_COMPLETION_ROUTINE and OVERLAPPED/LPOVERLAPPED, which seems to be too much duplication. I think you should guard the function with an #ifdef __WINE_WINBASE_H statement, but I would wait for some other developers to chime in to get a consensus before accepting this though. It doesn't seem right for an ntdll function to use an OVERLAPPED pointer. Shouldn't it take an IO_STATUS_BLOCK instead? It is not used in the function itself, it is only passed to user-provided callback. So, I see several possibilities: 1) change RtlSetIoCompletionCallback to use another callback prototype, with LPVOID or ULONG_PTR or something instead of LPOVERLAPPED 2) leave callback prototype as in BindIoCompletionCallback, and protect RtlSetIoCompletionCallback with #ifdefs as Robert suggested 3) do not implement RtlSetIoCompletionCallback at all and move all code in kernel32
Re: Early wine history
Dan Kegel [EMAIL PROTECTED] writes: The first message I found contemplating it was dated 1 Jun 1993, http://groups.google.com/group/comp.os.linux/msg/0a7c3867abdb4a76 Is that about the right estimate for Wine's birthday? The 0.0.2 release was on June 29, and 0.0.1 was about a week before that IIRC. I don't have the exact date unfortunately. A roughly 1995 writeup about Wine is at http://www.softlookup.com/tutorial/redhat/rhl58.asp It has a screen shot of a game Pipe Dream running under Wine. I just checked; the game is still online at http://members.chello.at/theodor.lauppert/games/pipe1.htm and runs well on today's wine :-) Hehe, I remember spending lots of time playing, I mean testing that game... -- Alexandre Julliard [EMAIL PROTECTED]
Re: [PATCH] Implement BindIoCompletionCallback
Andrey Turkin [EMAIL PROTECTED] writes: It is not used in the function itself, it is only passed to user-provided callback. So, I see several possibilities: I know it's in the callback, what I meant is that the ntdll function should not be taking a LPOVERLAPPED_COMPLETION_ROUTINE, which is a kernel32 thing, it should be taking some sort of IO_COMPLETION_CALLBACK routine, that uses an IO_STATUS_BLOCK (or probably better a void*, since it's opaque) instead of an OVERLAPPED pointer. -- Alexandre Julliard [EMAIL PROTECTED]
dll to .so wrapper
Hi there, I've got a bit of a specific task, that I don't know if it's achievable via wine in some way or not. I'd like to make a windows dll available to linux programs as a .so file. The dll itself is a video plugin (freeframe.sourceforge.net). These are available commercially to buy, and I'd like to be able to use them in a linux application that supports the plugin format for native linux compiled plugins, without having to request linux native versions from the commercial developers. I've been doing some searching, and have found a few mails on this list about this sort of thing in the past, but haven't been able to find a conclusive method. I guess that this might be possible via some sort of wrapper that maps the inputs/outputs to the dll . Does anyone know if there is anything that runs like this already out there that I could take a look at as an example piece of code to hack about with? Cheers Dave
Re: [msiexec] A nicer icon
On 19.12.2007 13:04, Alexandre Julliard wrote: Having icons in .svg format is a nice improvement, but we'll need a tool to build the .ico from the .svg. We also need to include multiple sizes in the .ico, most places want a 32x32 icon, and scaling down the 48x48 looks bad. Of course we should also look into taking advantage of the larger size where that's possible without breaking compatibility. I've created a system to produce Win32 .icos from SVGs for another project[1]. I used rsvg to convert svg-png, imagemagick's convert to reduce color depths and finally icotool[2] to assemble the Win32 icon. -f.r. [1] http://trac.crystalspace3d.org/trac/CS/browser/CS/trunk/mk/jam/icons.jam - it's for the Jam build system, but at least you can see the commands used (the stuff in 'actions'). [2] Part of icoutils: http://www.nongnu.org/icoutils/
Re: Early wine history
I have a copy of iX Magazine ( http://www.heise.de/ix/ ) from July 1994 that has a four page write up about Wine. There is also a full page interview, QA with Bob Amstadt. Pages 122 to 127 Tom
Re: dll to .so wrapper
Hi bridd, bridd schreef: Hi there, I've got a bit of a specific task, that I don't know if it's achievable via wine in some way or not. I'd like to make a windows dll available to linux programs as a .so file. The dll itself is a video plugin (freeframe.sourceforge.net). These are available commercially to buy, and I'd like to be able to use them in a linux application that supports the plugin format for native linux compiled plugins, without having to request linux native versions from the commercial developers. I've been doing some searching, and have found a few mails on this list about this sort of thing in the past, but haven't been able to find a conclusive method. I guess that this might be possible via some sort of wrapper that maps the inputs/outputs to the dll . Does anyone know if there is anything that runs like this already out there that I could take a look at as an example piece of code to hack about with? This topic comes up from time to time, usually with mild variations. The problem is that wine sets up its own environment and memory layout. In the end you will need a .exe (or winelib binary) that uses wine, and a socket/pipe/shm function to communicate with the .so, there is no easy way to just dynamically load a dll in an existing program. Cheers, Maarten.
Re: dll to .so wrapper
On Wed, Dec 19, 2007 at 10:26:38PM +0100, Maarten Lankhorst wrote: Hi bridd, bridd schreef: Hi there, I've got a bit of a specific task, that I don't know if it's achievable via wine in some way or not. I'd like to make a windows dll available to linux programs as a .so file. The dll itself is a video plugin (freeframe.sourceforge.net). These are available commercially to buy, and I'd like to be able to use them in a linux application that supports the plugin format for native linux compiled plugins, without having to request linux native versions from the commercial developers. I've been doing some searching, and have found a few mails on this list about this sort of thing in the past, but haven't been able to find a conclusive method. Yes, it is called MPlayer, which has a rudimentary WIne derived Codec loading and executing framework. You are perhaps easier off using it ;) Ciao, Marcus
Re: dll to .so wrapper
On Wed, 2007-12-19 at 23:06 +0100, Marcus Meissner wrote: The dll itself is a video plugin (freeframe.sourceforge.net). These are available commercially to buy, and I'd like to be able to use them in a linux application that supports the plugin format for native linux compiled plugins, without having to request linux native versions from the commercial developers. I've been doing some searching, and have found a few mails on this list about this sort of thing in the past, but haven't been able to find a conclusive method. Yes, it is called MPlayer, which has a rudimentary WIne derived Codec loading and executing framework. You are perhaps easier off using it ;) That kind-of misses my point though; freeframe is a plug-in format for adding effects to a video input (usually used in live VJ applications). As far as I know, MPlayer doesn't support it, nor would that enable support in any linux VJ'ing software! :) I was simply looking at the possibility of running freeframe plugins compiled under windows, in linux using wine as the middle-layer. Cheers Dave
Re: dll to .so wrapper
On Wed, 2007-12-19 at 22:26 +0100, Maarten Lankhorst wrote: This topic comes up from time to time, usually with mild variations. The problem is that wine sets up its own environment and memory layout. In the end you will need a .exe (or winelib binary) that uses wine, and a socket/pipe/shm function to communicate with the .so, there is no easy way to just dynamically load a dll in an existing program. I see, so it's sounding like to do this I'd need to have something more akin to a VST host, that acts as an intermediatory and pumps the video data from the linux application via a native plugin (.so), into a winelib compiled program that executes the windows compiled plugin (.dll) and the sends it back out again. Probably beyond my skills right now, but thought it was worth seeing if anyone had trodden a similar route already! Thanks, Dave
Re: loader: Add --compile-info option to Wine.
Peter Beutner schrieb: John Klehm schrieb: On Dec 18, 2007 9:43 AM, Peter Beutner [EMAIL PROTECTED] wrote: As I recall this is not the only version that causes problems. Plus certain compiler flags have an influence as well. And as most distros ship gcc with a bunch of patches you probably can't even rely on the gcc version alone. Imo it would be better to collect the info on a wiki page. Like this one? http://wiki.winehq.org/GccVersions ah, nice. didn't know about that one. Nothing wrong with having the info output reflect the knowledge gathered on the wiki page. So let's add to that info that gcc 4.2.2 (on gentoo) doesn't work. As well as recent 4.3-snapshots. (At least that was the status a few releases back, haven't tested in a while.) just tested again with current git and it worked with every gcc version I had at hand here: 4.2.2, 4.1.2, 4.0.4 and 3.4.6.
Re: [patch 1/2, try 2] wined3d: rewrite IWineD3DSurfaceImpl_BltOverride colorfill codepath
Hi Alexander, I had a look at your patches again, and another issue came to my mind: I am not sure how the scissor rectangle and viewport affects ColorFill blits. IDirect3DDevice::Clear is limited by the viewport, the scissor test and the rectangles passed in, but I think that this doesn't apply to ColorFills. If that is true, I think there isn't much point in having a common codepath, and we should just put the glClear() call into COLORFILL itself - Dealing with the differences of those two calls will be more effort than the code shared. But I think we need a test for this. There is a clear() test in dlls/ddraw/tests/visual.c, but the d3d9 test tests a few more things. It should be possible to add a COLORFILL test to the visual.c clear test in ddraw as well, this will show if Windows honors the scissor and viewport in COLORFILL or not. Yes, I know... Start fixing one bug, and you'll run into a lot more. Happens to me all the time as well :-) Stefan
Re: Today's git won't hunt. Server crash, lots of other problems?
On Dec 18, 2007 10:38 AM, Dan Kegel [EMAIL PROTECTED] wrote: My git won't install DNS9P any more, as of today's git. But it doesn't seem easy to repeat; I keep getting other errors now. Roy next to me says he ran into another regression, he's doing a bisect, There were bunches of regressions, it seems, but today's git plus the patches sent to wine-patches by Rob and Maarten fix the DNS 9 problem. Thanks, guys! - Dan
