Re: Winelib's role in converting Windows applications
Ira Krakow wrote: As many of you know, Brian and I are writing a book on Wine and Winelib for Prentice Hall. Brian's doing the Wine part; I'm doing the Winelib part. At Wineconf, I had a number of conversations about Winelib's role in converting Windows apps. The consensus seems to be that the most efficient conversion path is for much of the Windows app to stay in Visual C++ (or whatever) and that only the modules that specifically require native Linux calls should be recompiled, via MinGW/Dev-C++ on the Windows side, and Winemaker on the Linux side, into Winelib objects. For example, if the application requires PAM authentication, or a Linux-based help system, these modules would be separated out and encapsulated as Winelib objects. I was thinking of using PAM authentication as a good example, since it works for any authentication scheme that the application requires. This is the approach I plan to take. I welcome all feedback. What I found, when I suggested to clients to work this way, was that the debugging tools were wholly and utterly inadequate. With all due respect (and I have TONS of respect) to winedbg, it's not up to the standards of working with ddd or the Visual Studio integrated debugger. Maybe running the remote Visual Studio debugger will work. I know it worked for me on some occasions. I also know that when I tried to run it in the most crucial of cases, it crashed the parent Visual Studio (i.e. - the part that ran on Windows). As such, there are occasions where compiling natively is, more or less, the only choice. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Commercial support
Tom Wickline wrote: On 5/3/05, Dimitrie O. Paun [EMAIL PROTECTED] wrote: Yes, I think being inclusive is better. However, I also think that we need to pick the rules carefully so we don't set up a bad precedent when half the world will be using Wine :). So here is what I propose: 1. The list should be capped to n entries (n=50, 100?) 2. It should be kept up to date, and refreshed at least yearly 3. Any list has an order by definition, this one should be ranked by how much each company benefits the project. Hello All, Here is my proposal... 1) a token monetary fee of around $10,000 per year. 2) at least 1,000 lines of code or some major contributions to documentation. 3) a link back to winehq.org from there site and not twenty pages into there site. 4) a clear and thought out business plan (there company goal) and have links to it. 5) they agree to be bound by the LGPL license and to give back all code changes that apply under this license. 6) anyone found in contempt of the LGPL will be banned from all future winehq.org listings. 7) if a banned party wants re-instatement they must pay a fine of $25,000 and post a written apology to the community for there actions. 8) each party should contribute to the Wine party fund to fund future Wineconf's. Tom Wickline Before going into elaborate schemes here, I suggest that everyone consider the following points: 1. Sure, commercial companies have something to gain from being listed on the WineHQ page, but so does Wine. 2. If I, as a business owner, am going to be charged more than a token amount, I had better get a receipt. Otherwise the actual cost to me is about double the amount I pay Wine. I don't mind if it's 50$ or 100$, but more then that, and I'd want it as a deductible expense. As Wine is not a legally existing body, however, there is no one to issue said receipt. 3. On the flip side, if Wine is going to be receiving such amounts, it will have to report them to some tax authority. Who will do the reporting, and how? 4. If we are going to go into 8 steps programs, a contract had better be involved. Creating one costs money. Keeping it enforced costs money. This money, a.k.a. overhead, had better come from somewhere. 5. More importantly than money, keeping the contract and money matters enforced requires human supervision. This means that someone who could really spend their time hacking wine will need to make sure that the commercial companies adhere to our standards. I really suggest we adhere to KISS - Keep It Simple. I actually liked the hackers rating idea. If a company is well known among the wine hackers, they'll vote for it. If not, list it alphabetically at the end of the former list. As I said before, the token cost was meant mostly to make sure that the company is still alive, but as Andrew said, sending an email once a year to make sure someone responds also works, and does not get anyone in trouble with any tax authority. Having said all of that, I think I'll actually go with Brian's idea. Let him phrase the criteria. Unlike me, he does not have a commercial interest in Wine. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: Game sound problem with wine 20050310 (Debian testing)
On 5/6/05, J. Grant [EMAIL PROTECTED] wrote: I added these extra lines to my ~/.wine/config file, pasted them to me on #winehq. I could not find these in the config documentation, could they be added somewhere please? There is basically no documentation on the config file. [dsound] ;Drivers = wineoss.drv ; default for most common configurations ;Drivers = winearts.drv ; for KDE Drivers = winealsa.drv ; for ALSA users Those should not be in [dsound] but in [winmm]. Try ALSA or OSS. Could make a difference. You could also set UseMmap to n in [wineoss] when using that. Unfortunately these did not really change anything. I uncomment them and changed them around to see if anything changed, but I had to go with eh Emulation bit uncommented as above to get the game to work at all. (Gave a sound error while loading otherwise) It's quite common to have dsound in emulation (it won't work without). This means a lot of load comes down to the cpu, and where perhaps your latency comes from. Paul
Stack size allocations
I wish to propose two changes that I currently have in my Solaris patchkit.
I'll use two separate e-mails here to avoid confusion.
Both changes add environment variables controlling the way wine does things.
The first patch addresses a problem I have found where Windows applications
under wine exceed the allocated stack. By default wine allocates the same 1MB
stack that windows does but wine has a different stack consumption that does
windows, adding the wine translation layers, possibly OGL then X calls on top
of this.
The following patch allows an environment variable WINE_STACK to redefine the
minimum stack to give applications and to add extra stack to that declared in
the executables header to allow for additional stack consumption. Currently
it works like this
if WINE_STACK is not set the default semantics are used just like wine does
today
if WINE_STACK is set then wine allocates the maximum of the value given in the
WINE_STACK env var or 1MB. 25% of the value specified in WINE_STACK is added
to the value declared in the applications executable header to provide more
headroom for wine/X calls.
Please excuse the primitive debugging included for now, it'll have to be
removed for primetime.
Comments anyone ?
Index: dlls/ntdll/thread.c
===
RCS file: /home/wine/wine/dlls/ntdll/thread.c,v
retrieving revision 1.26
diff -u -3 -p -r1.26 thread.c
--- dlls/ntdll/thread.c 27 Apr 2005 08:18:20 - 1.26
+++ dlls/ntdll/thread.c 6 May 2005 21:21:30 -
@@ -25,7 +25,7 @@
#ifdef HAVE_SYS_MMAN_H
#include sys/mman.h
#endif
-
+#include stdio.h
#include ntstatus.h
#include thread.h
#include winternl.h
@@ -221,6 +221,9 @@ NTSTATUS WINAPI RtlCreateUserThread( HAN
ULONG size;
int request_pipe[2];
NTSTATUS status;
+unsigned long stack_min=1024*1024;
+unsigned long stack_overhead=0;
+char stack_mul=0;
if( ! is_current_process( process ) )
{
@@ -273,23 +276,67 @@ NTSTATUS WINAPI RtlCreateUserThread( HAN
MEM_SYSTEM, PAGE_EXECUTE_READWRITE );
info-pthread_info.teb_size = size;
info-pthread_info.teb_sel = teb-teb_sel;
-
+
+
+ /* Allocate the stack:
+ Allow the user to set an environment variable to specify the stack
size
+ WINE_STACK, allow the user to use multiplier notation
+ eg K for kilobyts or M for Megabytes or M
+ example WINE_STCK=2048K or WINE_STACK=2M bithe specify 2 Megabytes
+*/
+
+ if(getenv(WINE_STACK)) {
+ sscanf(getenv(WINE_STACK), %lu%c ,stack_min,stack_mul);
+ fprintf(stderr,Got stack spec of %lu %c bytes from
environment,stack_min,stack_mul);
+ }
+
+ switch (stack_mul) {
+ case 'm':
+ case 'M':
+ stack_min=stack_min*1024*1024;
+ stack_overhead=stack_min/4;
+ break;
+ case 'b':
+ case 'B':
+ stack_overhead=stack_min/4;
+ break;
+ case 'k':
+ case 'K':
+ stack_min=stack_min*1024;
+ stack_overhead=stack_min/4;
+ break;
+
+ default:
+ stack_min=1024*1024;
+ stack_overhead=0;
+ break;
+ }
+
+ stack_min=max(stack_min,1024*1024);
+fprintf(stderr,Minimum Stack Set to %lu overhead allowance =
%d\n,stack_min,stack_overhead);
+/* Get the stack size recommendation from the program prefix (Executible
header)
+ Because this is not real windows we have additional stack overheads
particularly in xlib
+ where the user has specified a stack requirement (IE VIA WINE_STACK)
add 25% of the minimum
+ stack over and above the value in the header to allow for this
+*/
if (!stack_reserve || !stack_commit)
{
IMAGE_NT_HEADERS *nt =
RtlImageNtHeader( NtCurrentTeb()-Peb-ImageBaseAddress );
-if (!stack_reserve) stack_reserve =
nt-OptionalHeader.SizeOfStackReserve;
+if (!stack_reserve) stack_reserve =
nt-OptionalHeader.SizeOfStackReserve+stack_overhead;
if (!stack_commit) stack_commit =
nt-OptionalHeader.SizeOfStackCommit;
}
if (stack_reserve stack_commit) stack_reserve = stack_commit;
stack_reserve = (stack_reserve + 0x) ~0x; /* round to 64K
boundary */
-if (stack_reserve 1024 * 1024) stack_reserve = 1024 * 1024; /* Xlib
needs a large stack */
+if (stack_reserve stack_min) stack_reserve = stack_min; /* Xlib needs
a large stack */
info-pthread_info.stack_base = NULL;
info-pthread_info.stack_size = stack_reserve;
info-pthread_info.entry = start_thread;
info-entry_point = start;
info-entry_arg
Support for multiple threading models
Some time ago, I wrote code to support native threads instead of lwp for SYSV
operating systems, the way I wrote the code all available threading models
were compiled into wine and the actual one to be used was selected by setting
an environment variable. (Currently WINE_THREADMODE). On OSes that support
multiple threading methods, IE Solaris and probably the BSDs this allows for
easy development and testing of thread support. It also allows the simulation
of no thread support (Not that that seems to be very useful).
Originally when I wrote this Solaris 9 was having some problems with crashing
in mutexes if native threads were used, but LWPs weren't perfect either, in
particular lwps aren't necessarily safe to use with some libraries (There is
a warning about this in the Man pages for the _lwp calls, For example. this
caused problems with alarm/usleep calls used at the time in winmm). These
days however in Solaris 10 the native thread code works quite well.
Anyway the fallout was that non winmm code worked best using native threads on
certain Solaris MUs and winmm dependent programs worked best using LWPs and
having the Threading model selectable made sense. This is still the case for
Solaris 8/9 users.
I can still see situations where it would be advantageous to be able to select
the threading model at runtime and I'd like to leave this support in (Solaris
9 for example). This possibility has received a luke warm reception before
but I thought I'd re-raise the possibility now while I'm doing the putback
from my latest patch kit.
Just as a final point Solaris no longer supports _lwp_create calls, without
this patch wine is unable to run on Solaris versions Solaris 9
Bob
Threading patch attached
Index: loader/kthread.c
===
RCS file: /home/wine/wine/loader/kthread.c,v
retrieving revision 1.11
diff -u -3 -p -r1.11 kthread.c
--- loader/kthread.c 2 Dec 2004 18:19:25 - 1.11
+++ loader/kthread.c 6 May 2005 21:22:11 -
@@ -68,6 +68,16 @@ struct _pthread_cleanup_buffer;
#include sched.h
#endif
+#ifdef HAVE_THREAD_H
+
+/* Fixme: Wine creates a namespace problem since it has it's own thread.h,
++for the time being explicitly load the system header
+*/
+
+#include errno.h
+#include /usr/include/thread.h
+#endif
+
#include wine/library.h
#include wine/pthread.h
@@ -83,6 +93,31 @@ static struct wine_pthread_functions fun
#define MAX_KEYS 16 /* libc6 doesn't use that many, but... */
#define MAX_TSD 16
+#define THREADS_SYSV 1
+#define THREADS_LWP 2
+#define THREADS_PTHREAD 3
+#define THREADS_CLONE 4
+#define THREADS_RFORK 5
+#define THREADS_NONE 6
+
+#if defined (HAVE_NPTL) || defined (HAVE_PTHREAD)
+#define THREADS_DEFAULT THREADS_PTHREAD
+#elif defined( HAVE_CLONE)
+#define THREADS_DEFAULT THREADS_CLONE
+#elif defined (HAVE_RFORK)
+#define THREADS_DEFAULT THREADS_RFORK
+#elif defined (HAVE_THR)
+#define THREADS_DEFAULT THREADS_SYSV
+#elif defined (HAVE__LWP_CREATE)
+#define THREADS_DEFAULT THREADS_LWP
+#else
+#define THREADS_DEFAULT THREADS_NONE
+#endif
+
+#define TRACE printf
+#define ERR printf
+
+int threadmode =0;
struct pthread_descr_struct
{
char dummy[2048];
@@ -123,7 +158,7 @@ int *__errno_location(void)
}
int *__error(void) { return __errno_location(); } /* FreeBSD */
int *__errno(void) { return __errno_location(); } /* NetBSD */
-int *___errno(void){ return __errno_location(); } /* Solaris */
+//int *___errno(void){ return __errno_location(); } /* Solaris */
int *__thr_errno(void) { return __errno_location(); } /* UnixWare */
/***
@@ -179,6 +214,44 @@ inline static char *get_temp_stack(void)
return temp_stacks[next % NB_TEMP_STACKS] + TEMP_STACK_SIZE;
}
+#ifdef HAVE_THR
+/*
+ * THR library specific, store thread specific data
+*/
+#define THREAD_GET_DATA 0
+#define THREAD_SET_DATA 1
+void * solaris_thread_data(int op, void *data)
+{
+ static mutex_t keylock; /* static ensures only one copy of keylock */
+ static thread_key_t key;
+ static int once_per_keyname = 0;
+ void *tsd = NULL;
+
+ if (!once_per_keyname) {
+mutex_lock(keylock);
+if (!once_per_keyname) {
+ thr_keycreate(key, free);
+ once_per_keyname++;
+ }
+mutex_unlock(keylock);
+ }
+
+ thr_getspecific(key, tsd);
+ if(op==THREAD_GET_DATA) return(tsd);
+ if (tsd == NULL) {
+thr_setspecific(key, data);
+ }
+ else
+ ERR(Thread private data already set !\n);
+thr_getspecific(key, tsd);
+ return((void *) tsd);
+}
+ /* end thread_specific_data */
+#endif
+
+
+
+
/***
* cleanup_thread
@@ -192,9 +265,18 @@ static void cleanup_thread( void
Re: Regression in Half life
I switched to the Xorg radeon driver which has 16 bpp support(the 2nd column shows 16 now), and made sure that hl runs with 16bpp, but the error still occurs. Yes it don't work, because you speak about frame buffer (named Color buffer on traces) when you speak about 16bpp. I spoke about depth buffer Good, thanks for explaining this to me. I mixed the two buffers. Well, HL doesn't offer any depth buffer setting. There's only one console command, gl_zmax, which is supposed to set the maximum depth buffer size. The default is 4096, and changing this value has no effect on the error.(HL still tries to get a 32 bit depth buffer) I sort of fixed the problem for me by forcing the depth buffer to 24 bit in dlls/x11drv/opengl.c, but I understand that this is not a real solution. Is there any chance for a better fix? I have no chance to fix this in the game nor in the video driver Stefan
Re: Stack size allocations
Robert Lunnon wrote: I wish to propose two changes that I currently have in my Solaris patchkit. I'll use two separate e-mails here to avoid confusion. Both changes add environment variables controlling the way wine does things. The first patch addresses a problem I have found where Windows applications under wine exceed the allocated stack. By default wine allocates the same 1MB stack that windows does but wine has a different stack consumption that does windows, adding the wine translation layers, possibly OGL then X calls on top of this. The following patch allows an environment variable WINE_STACK to redefine the minimum stack to give applications and to add extra stack to that declared in the executables header to allow for additional stack consumption. Currently it works like this if WINE_STACK is not set the default semantics are used just like wine does today if WINE_STACK is set then wine allocates the maximum of the value given in the WINE_STACK env var or 1MB. 25% of the value specified in WINE_STACK is added to the value declared in the applications executable header to provide more headroom for wine/X calls. Please excuse the primitive debugging included for now, it'll have to be removed for primetime. Comments anyone ? I think this is a bit weird: `wine prog.exe` is not equivalent to: `WINE_STACK=1M wine prog.exe` -- it is equivalent to this weird thing: `WINE_STACK=838860B wine prog.exe` Why wouldn't you simple add that 25% extra in every case? regards, Joris
Re: Game sound problem with wine 20050310 (Debian testing)
Hi, On Sat, May 07, 2005 at 10:00:59AM +0200, Paul van Schayck wrote: It's quite common to have dsound in emulation (it won't work without). This means a lot of load comes down to the cpu, and where perhaps your latency comes from. BTW, I'm planning to implement SetThreadPriority(). Maybe it actually gets called by the game (but at least it should get called by our multimedia DLLs in recent CVS now). This could also help a lot, provided that you're running on a SCHED_ISO and SCHED_BATCH aware kernel... Of course this SetThreadPriority() implementation wouldn't be perfect, but at least it would be a first implementation to see whether it helps, and in that case one could do further discussion with Con Kolivas to try to make Linux almost fully compatible with the Windows thread priority model. Andreas Mohr
16 bit hwnd in SendmessageA/W
Hi,
Another case where I don't think I know enough of the finer details for
a
correct solution.
MS Visual C++ 1.5 IDE - 16 bit win application - communicates its window
handle to WINTEE32.EXE - win32 app - to handle the build process:
E:\\MSVC\\BIN\\WINTEE32.EXE -h2a -vn
5e is the 16 bit window handle.
Here it sends data to the IDE:
0035:Call user32.SendMessageA(002a,004a,0008004a,77a3fe28)
ret=77a51649
That does not work, SendMessageA does only expect full 32 bit win
handles.
Things work with this patch:
==
--- wine/dlls/user/message.c2005-05-05 10:26:28.0 +0200
+++ mywine/dlls/user/message.c 2005-05-05 20:07:46.0 +0200
@@ -2388,6 +2388,13 @@ LRESULT WINAPI SendMessageTimeoutA( HWND
return 1;
}
+/* if it is not a 32bit window handle */
+if( !IsWindow( hwnd)) {
+/* try if it is a 16 bit handle */
+hwnd = WIN_Handle32( (HWND16) hwnd );
+info.hwnd = hwnd;
+}
+
if (!(dest_tid = GetWindowThreadProcessId( hwnd, dest_pid )))
return 0;
if (USER_IsExitingThread( dest_tid )) return 0;
==
Is anything else needed, I wonder?
Rein.
Re: 16 bit hwnd in SendmessageA/W
Rein Klazes [EMAIL PROTECTED] wrote: E:\\MSVC\\BIN\\WINTEE32.EXE -h2a -vn 5e is the 16 bit window handle. 2a I'd guess, not 5e. Here it sends data to the IDE: 0035:Call user32.SendMessageA(002a,004a,0008004a,77a3fe28) ret=77a51649 That does not work, SendMessageA does only expect full 32 bit win handles. You need to find out why and how 2a became 002a in the first place. -- Dmitry.
Re: portability improvements for wineshelllink script
On Sat, 7 May 2005, Robert Lunnon wrote: [...] # diff -u wineshelllink.old wineshelllink --- wineshelllink.old mer mai 4 11:47:30 2005 +++ wineshelllink mer mai 4 11:50:03 2005 @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash This is wrong. Some users may not have bash installed and the script should still work on their systems. So the fix is not to make the script fail to run on any system which does not have bash but to modify it so it works with any standard Bourne shell, including the Solaris one. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Linux: the choice of a GNU generation
Re: Commercial support
On Samstag 07 Mai 2005 08:39, Shachar Shemesh wrote: I really suggest we adhere to KISS - Keep It Simple. I actually liked the hackers rating idea. If a company is well known among the wine hackers, they'll vote for it. If not, list it alphabetically at the end of the former list. While I certainly don't think that's a bad idea, I am still a bit concerned that this puts too much emphasis on code contributions alone, while the bunch of other stuff that seems also very important to me (docs, training, helping out users, whatever) might get a bit forgotten. However, that's certainly a question of how the hackers' rating would be implemented, not a conceptual problem. As I said before, the token cost was meant mostly to make sure that the company is still alive, but as Andrew said, sending an email once a year to make sure someone responds also works, and does not get anyone in trouble with any tax authority. Yep, I do think that should suffice. Having said all of that, I think I'll actually go with Brian's idea. Let him phrase the criteria. Unlike me, he does not have a commercial interest in Wine. I'd be much in favor of that, too. Cheers, David pgpberGqp294P.pgp Description: PGP signature
Re: winecfg: Match the new way to use unixfs
On Sat, 2005-05-07 at 09:46 +0200, Michael Jung wrote: P.S.: What's the reason for disabling the i18n resources in winecfg.rc? They're out of date and don't reflect the current English GUI. thanks -mike
Re: Stack size allocations
On Sat, 07 May 2005 18:13:41 +1000, Robert Lunnon wrote: Comments anyone ?
Re: Stack size allocations
On Sat, 7 May 2005 07:47 pm, Joris Huizer wrote: Robert Lunnon wrote: I wish to propose two changes that I currently have in my Solaris patchkit. I'll use two separate e-mails here to avoid confusion. Both changes add environment variables controlling the way wine does things. The first patch addresses a problem I have found where Windows applications under wine exceed the allocated stack. By default wine allocates the same 1MB stack that windows does but wine has a different stack consumption that does windows, adding the wine translation layers, possibly OGL then X calls on top of this. The following patch allows an environment variable WINE_STACK to redefine the minimum stack to give applications and to add extra stack to that declared in the executables header to allow for additional stack consumption. Currently it works like this if WINE_STACK is not set the default semantics are used just like wine does today if WINE_STACK is set then wine allocates the maximum of the value given in the WINE_STACK env var or 1MB. 25% of the value specified in WINE_STACK is added to the value declared in the applications executable header to provide more headroom for wine/X calls. Please excuse the primitive debugging included for now, it'll have to be removed for primetime. Comments anyone ? I think this is a bit weird: `wine prog.exe` is not equivalent to: `WINE_STACK=1M wine prog.exe` -- it is equivalent to this weird thing: `WINE_STACK=838860B wine prog.exe` Why wouldn't you simple add that 25% extra in every case? Well, that would be a solution but it doesn't allow a fallback to Standard windows behaviour I have no idea if there are any applications out there that are sensitive to the size of their stack segments Bob
Re: Stack size allocations
Robert Lunnon [EMAIL PROTECTED] writes: The first patch addresses a problem I have found where Windows applications under wine exceed the allocated stack. By default wine allocates the same 1MB stack that windows does but wine has a different stack consumption that does windows, adding the wine translation layers, possibly OGL then X calls on top of this. Actually Wine stack usage should be very similar to Windows. The real problem is that Xlib seems to allocate large amount of stack space in some cases; I believe this has improved lately, since it's obviously also a problem for threaded Unix apps, and we haven't had reports of stack overflows on Linux for a long time. What you probably want to do is just unconditionally add some more space on Solaris until the X libraries are fixed. -- Alexandre Julliard [EMAIL PROTECTED]
Wiki stuff
Hi, It seems some users have started creating pages that are simply intended to dupe the appdb: http://wiki.winehq.com/Running_Errors http://wiki.winehq.com/WindowsGames I doubt it makes any sense to have this sort of info on the wiki. What do others think? thanks -mike
Re: portability improvements for wineshelllink script
On Sat, 7 May 2005 08:52 pm, Francois Gouget wrote: On Sat, 7 May 2005, Robert Lunnon wrote: [...] # diff -u wineshelllink.old wineshelllink --- wineshelllink.old mer mai 4 11:47:30 2005 +++ wineshelllink mer mai 4 11:50:03 2005 @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash This is wrong. Some users may not have bash installed and the script should still work on their systems. So the fix is not to make the script fail to run on any system which does not have bash but to modify it so it works with any standard Bourne shell, including the Solaris one. Wrong? Well actually, bash is wrong, it doesn't properly emulate Bourne shell behaviour when called as sh, a constant source of irritation for Solaris users I assure you. So the Correct fix is to fix bash, but then doing that will break half of linux. Now you see why I choose Solaris... But this is besides the point. Let's agree the solution is not necessarily *Wrong*, It does in fact work, so it can't be wrong. The script as written is bash feature bound, and therefore should be executed by bash. What you really mean is that Laurent didn't fix the problem the way you wanted it to be fixed. BTW I have no objection to making wine dependent on bash, bash is available for all platforms and is probably more regular than bourne shell across platforms, though I think perhaps perhaps ksh might be a safer standard shell choice and it's more likely to be closer than /bin/sh to being able to parse bash dependent scripts properly. Maybe there are other thoughts out there on which interpreter would be best for wine's purposes. Perhaps Laurent might be willing to take a look at the bash dependencies, if not I'll add it to my patch list to be maintained outside the wine project until I get around to looking at it. Bob
Re: 16 bit hwnd in SendmessageA/W
Rein Klazes [EMAIL PROTECTED] writes:
Is anything else needed, I wonder?
Yes, try something like this:
Index: dlls/user/win.c
===
RCS file: /opt/cvs-commit/wine/dlls/user/win.c,v
retrieving revision 1.2
diff -u -p -r1.2 win.c
--- dlls/user/win.c 27 Apr 2005 10:23:24 - 1.2
+++ dlls/user/win.c 7 May 2005 12:18:40 -
@@ -307,13 +307,14 @@ WND *WIN_GetPtr( HWND hwnd )
USER_Lock();
if ((ptr = user_handles[index]))
{
-if (ptr-dwMagic == WND_MAGIC (!HIWORD(hwnd) || hwnd ==
ptr-hwndSelf))
+if (ptr-dwMagic == WND_MAGIC
+(hwnd == ptr-hwndSelf || !HIWORD(hwnd) || HIWORD(hwnd) == 0x))
return ptr;
ptr = NULL;
}
else if (index == USER_HANDLE_TO_INDEX(hwndDesktop))
{
-if (!HIWORD(hwnd) || hwnd == GetDesktopWindow()) ptr = WND_DESKTOP;
+if (hwnd == GetDesktopWindow() || !HIWORD(hwnd) || HIWORD(hwnd) ==
0x) ptr = WND_DESKTOP;
else ptr = NULL;
}
else ptr = WND_OTHER_PROCESS;
Index: server/user.c
===
RCS file: /opt/cvs-commit/wine/server/user.c,v
retrieving revision 1.8
diff -u -p -r1.8 user.c
--- server/user.c 28 May 2004 19:35:37 - 1.8
+++ server/user.c 7 May 2005 12:18:40 -
@@ -35,12 +35,14 @@ static int allocated_handles;
static struct user_handle *handle_to_entry( user_handle_t handle )
{
+unsigned short generation;
int index = (((unsigned int)handle 0x) - FIRST_USER_HANDLE) 1;
if (index 0 || index = nb_handles) return NULL;
if (!handles[index].type) return NULL;
-if (((unsigned int)handle 16) ((unsigned int)handle 16 !=
handles[index].generation))
-return NULL;
-return handles[index];
+generation = (unsigned int)handle 16;
+if (generation == handles[index].generation || !generation || generation
== 0x)
+return handles[index];
+return NULL;
}
inline static user_handle_t entry_to_handle( struct user_handle *ptr )
--
Alexandre Julliard
[EMAIL PROTECTED]
Re: Commercial support
On 5/7/05, Shachar Shemesh [EMAIL PROTECTED] wrote: Before going into elaborate schemes here, I suggest that everyone consider the following points: 1. Sure, commercial companies have something to gain from being listed on the WineHQ page, but so does Wine. So this is a mute point. 2. If I, as a business owner, am going to be charged more than a token amount, I had better get a receipt. You should save all your small receipt's they will add up come tax time. Otherwise the actual cost to me is about double the amount I pay Wine. I don't mind if it's 50$ or 100$, but more then that, and I'd want it as a deductible expense. As Wine is not a legally existing body, however, there is no one to issue said receipt. The Wine Party Fund is listed as a non-profit charity in the state of Minnesota so the listing fee could be a minimum donation to this fund. and as its a non-profit you should have the ability to write this off. 3. On the flip side, if Wine is going to be receiving such amounts, it will have to report them to some tax authority. Who will do the reporting, and how? WPF is a non-profit... 4. If we are going to go into 8 steps programs, a contract had better be involved. Creating one costs money. Keeping it enforced costs money. This money, a.k.a. overhead, had better come from somewhere. The kind donations to be listed.. 5. More importantly than money, keeping the contract and money matters enforced requires human supervision. This means that someone who could really spend their time hacking wine will need to make sure that the commercial companies adhere to our standards. Okay, now we get to my concerns. Who is going to do this even if the listing fee is a poultry $100.00 ? There sure as heck wont be any money to in force anything. I really suggest we adhere to KISS - Keep It Simple. And have nothing in place if a rouge company fails to adhear to the LGPL!!! I actually liked the hackers rating idea. If a company is well known among the wine hackers, they'll vote for it. If not, list it alphabetically at the end of the former list. As I said before, the token cost was meant mostly to make sure that the company is still alive, but as Andrew said, sending an email once a year to make sure someone responds also works, and does not get anyone in trouble with any tax authority. Having said all of that, I think I'll actually go with Brian's idea. Let him phrase the criteria. Unlike me, he does not have a commercial interest in Wine. I say we have a *OPEN* vote on this. Democracy at its best... Tom Wickline Shachar
Re: Commercial support
9 million hits a month != visits 509874 visits != http://www.winehq.org/site/support pages visits (as a fact, it isn't even listed under the top 30, not surprising) ~ 2000 pages visits != referrers referrers != sales.. But of course, $ 100 per year is a nice price, but than everybody can. Tom Wickline wrote: I have a question and I feel its important to ask. Lets for example say I start a small company and I have a Wine based product. And I refuse to give back any changes that I make to the source. What are you going to do in a case like this? And I'm sure I can afford $8.00 a month for a nice listing here! Winehq.org receives between 7 and 9 million hits a month, so I hope this $8.00 is a wise investment for my future company... http://www.winehq.org/webalizer/ Tom Wickline -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org MediaHost at www.mediahost.org Skype: startcom Phone: +1.213.341.0390 Import StartCom Public CA smime.p7s Description: S/MIME Cryptographic Signature
Re: Commercial support
On 5/7/05, Tom Wickline [EMAIL PROTECTED] wrote: The Wine Party Fund is listed as a non-profit charity in the state of Minnesota When did this happen? I'm pretty sure it's not unless it some how happened over the past few months. We've discussed it before, but always decided the amount of paperwork isn't worth it. I'm sure Steven can tell us how bad it sucks. With regard to the rest of the page, I took a stab at starting it the other night. Including a list of support companies is just one aspect of it. Anyway, I fully intend to list some companies that can do support and include a few paragraphs discussing that process. I'm not going to tell them it'll cost $10,000 either, or even $100. We're a free software development community and that implies some level of trust. Plus, if you want to support Wine (or, IMHO, any piece of software) you're *(@ing crazy. If anyone thinks that sucks, then feel free to beat me to it and write the page. -Brian
Re: Solaris Compatibility -dlls/wineps/driver.c
Robert Lunnon [EMAIL PROTECTED] writes: Notes about patch: PAGESIZE is a risky name for a symbol since it an obvious candidate for use to define the page size of the OSes VM pages and in fact does Collide under Solaris We already have a #undef PAGESIZE to work around that problem. If it doesn't work you probably need to tweak the include files order. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Game sound problem with wine 20050310 (Debian testing)
On 5/7/05, J. Grant [EMAIL PROTECTED] wrote: I did find man wine.conf, however that is quite incomplete it seems. Incomplete and not to be trusted on accurate information. I wonder if this could be added to the man page? Also could /usr/share/wine/skel/config be added to the man page? No, we are dropping the config file completely. And as heads up, there will be no conversion tool to the new system. As Alexandre said: we should stop being nice [in this conversion period]. The config will be moved to the registry and winecfg. I remember there used to be a --winver=win2k style command line argument, but it seems to have gone now. Or is it still present, but undocumented? (Or maybe I missed some documentation?) That option was dropped a bit over a year ago. I did find a copy of the wine.conf man page on the website as well, could that copy of the man page be expanded to cover all the options please? There is no list of options in the first place right now. With the system we will be looking into creating a tool that will grab all options from the source code so we can keep the list up to date. I could not find [wineoss] section documentation in any of the locations I am aware of. I just set it to 1 but it did not seem to make any difference to the audio lag unfortunately. Both the [wineoss] and [winealsa] options have never been documented. The normal behaviour though with a lack of performance and dsound is not lag but cliping sound. So I don't think it's a performance issue. I do get far more network lag than I did when running Call of Duty on win2k. Could this be caused by the sound lag? Is network lag a second issue with is sometimes common? Set the [winmm] drivers option to nothing. You won't get any sound at all. Is the lag now less? Paul
Stable release builds with fixme output (Wine 20050310 debian sarge/testing)
Hello, I typically launch applications using wine from the terminal, I get pages of these fixme debug messages. I wonder if there is a reason these fixme harmless messages are being displayed? IMHO stable releases should only output err messages, thus not displaying fixme or warnings. I wonder if this has been considered already? fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. fixme:powermgnt:SetThreadExecutionState (0x2): stub, harmless. I am not on this list, please include my email address in any replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio
Re: Game sound problem with wine 20050310 (Debian testing)
Hi Paul Thank you for your quick response On 07/05/05 09:00, Paul van Schayck wrote: On 5/6/05, J. Grant [EMAIL PROTECTED] wrote: I added these extra lines to my ~/.wine/config file, pasted them to me on #winehq. I could not find these in the config documentation, could they be added somewhere please? There is basically no documentation on the config file. I did find man wine.conf, however that is quite incomplete it seems. Also these files: 22 /usr/share/doc/wine/config - ../../wine/skel/config 8050 /usr/share/wine/skel/config This FAQ entry http://www.winehq.com/site/docs/wine-faq/index 5.3. How do I configure Wine to run on my system? Wine requires that you have a config file as ~/.wine/config. The format of this file is explained in the wine.conf man page. The file documentation/samples/config ( http://source.winehq.org/source/documentation/samples/config) contains a config file example. More explicit directions can be found in the README file ( http://source.winehq.org/source/README) that will be located in the base Wine directory after you gunzip and untar the distribution file. I wonder if this could be added to the man page? Also could /usr/share/wine/skel/config be added to the man page? The other area of document which I think could be improved is man wine. For instance Call of Duty would not run with whatever was the default Windows that resulted when no override in [Version] section of ~/.wine/config So I had to create one with this: [Version] Windows=win2k I remember there used to be a --winver=win2k style command line argument, but it seems to have gone now. Or is it still present, but undocumented? (Or maybe I missed some documentation?) I did find a copy of the wine.conf man page on the website as well, could that copy of the man page be expanded to cover all the options please? [dsound] ;Drivers = wineoss.drv ; default for most common configurations ;Drivers = winearts.drv ; for KDE Drivers = winealsa.drv ; for ALSA users Those should not be in [dsound] but in [winmm]. Try ALSA or OSS. Could make a difference. You could also set UseMmap to n in [wineoss] when using that. ok, thank you. Sorry I got them in the wrong section, I was just guessing as I had not found any complete documentation then. I could not find [wineoss] section documentation in any of the locations I am aware of. I just set it to 1 but it did not seem to make any difference to the audio lag unfortunately. Unfortunately these did not really change anything. I uncomment them and changed them around to see if anything changed, but I had to go with eh Emulation bit uncommented as above to get the game to work at all. (Gave a sound error while loading otherwise) It's quite common to have dsound in emulation (it won't work without). This means a lot of load comes down to the cpu, and where perhaps your latency comes from. By emulation do you simply mean that the dsound api is wrapped, and then the data passed to ALSA or OSS etc? Or do you mean that there is a significant amount of dsound emulation processing on the data before it is passed to ALSA or OSS etc? Is it very common to have this lag? I am using a 2.2Ghz AlthonXP 32bit (3200+) with 1GB ram. I do get far more network lag than I did when running Call of Duty on win2k. Could this be caused by the sound lag? Is network lag a second issue with is sometimes common? I am not on this list, please include my email address in any replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio
wineconsole exits immediately (Wine 20050310 debian sarge/testing)
Hello, I was trying to run wcmd, it seems to have been renamed wineconsole. However, unfortunately it exits immediately before producing a DOS command prompt in my terminal like wcmd used to. I think this is a bug, (unless I missed something). $ wineconsole Invoking /usr/lib/wine/wine.bin wineconsole.exe ... Wine exited with a successful status $ I thought that maybe there was an argument I needed to pass, but there isn't a man page, or command line --help /? help unfortunately at present. $ wineconsole --help Invoking /usr/lib/wine/wine.bin wineconsole.exe --help ... err:wineconsole:WinMain Wrong command line options Wine exited with a successful status $ wineconsole /? Invoking /usr/lib/wine/wine.bin wineconsole.exe /? ... Wine exited with a successful status $ I am not on this list, please include my email address in any replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio
Re: Game sound problem with wine 20050310 (Debian testing)
Hi Andreas, Thank you for your quick response. On 07/05/05 10:49, Andreas Mohr wrote: Hi, On Sat, May 07, 2005 at 10:00:59AM +0200, Paul van Schayck wrote: It's quite common to have dsound in emulation (it won't work without). This means a lot of load comes down to the cpu, and where perhaps your latency comes from. BTW, I'm planning to implement SetThreadPriority(). Maybe it actually gets called by the game (but at least it should get called by our multimedia DLLs in recent CVS now). This could also help a lot, provided that you're running on a SCHED_ISO and SCHED_BATCH aware kernel... Okay, great! I am running debian sarge 2.6.8-2-k7 kernel, not sure if that is SCHED_ISO and SCHED_BATCH aware, but I can upgrade to the latest kernel in debian testing/sarge if necessary. Of course this SetThreadPriority() implementation wouldn't be perfect, but at least it would be a first implementation to see whether it helps, and in that case one could do further discussion with Con Kolivas to try to make Linux almost fully compatible with the Windows thread priority model. Hopefully it would give some improvement. I am not on this list, please include my email address in any replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio
Re: wineconsole exits immediately (Wine 20050310 debian sarge/testing)
I forgot to mention. my terminal (KDE Konsole) is broken after running those commands and no appearance of wineconsole. man and other terminal applications do not display correctly, I have to clear the terminal or restart it to get it working again. When running other win32 software such as Call of Duty the terminal still works when I exit the game. I am not on this list, please include my email address in any replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio
Re: Stable release builds with fixme output (Wine 20050310 debian sarge/testing)
On 5/7/05, J. Grant [EMAIL PROTECTED] wrote: I typically launch applications using wine from the terminal, I get pages of these fixme debug messages. I wonder if there is a reason these fixme harmless messages are being displayed? IMHO stable releases should only output err messages, thus not displaying fixme or warnings. I wonder if this has been considered already? From ANNOUNCE: This is still a developers only release. There are many bugs and unimplemented features. Most applications still do not work correctly. And from BUGS: Wine is still considered alpha software and is still incomplete. There are no stable wine releases yet. Paul
Re: portability improvements for wineshelllink script
On Sat, 7 May 2005, Robert Lunnon wrote: On Sat, 7 May 2005 08:52 pm, Francois Gouget wrote: On Sat, 7 May 2005, Robert Lunnon wrote: [...] # diff -u wineshelllink.old wineshelllink --- wineshelllink.old mer mai 4 11:47:30 2005 +++ wineshelllink mer mai 4 11:50:03 2005 @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash [...] Wrong? Well actually, bash is wrong, it doesn't properly emulate Bourne shell behaviour when called as sh, a constant source of irritation for Solaris users I assure you. It irritates *BSD users too. [...] Let's agree the solution is not necessarily *Wrong*, It does in fact work, so it can't be wrong. It is wrong because Wine should not depend on bash. The script as written is bash feature bound, This is wrong and must be fixed, not 'swept under the carpet'. and therefore should be executed by bash. What you really mean is that Laurent didn't fix the problem the way you wanted it to be fixed. This is true too but I think most Wine developers will agree with me that Wine should not depend on bash which means the above is not 'the right fix(tm)' which makes it 'the wrong fix'. BTW I have no objection to making wine dependent on bash, I have a strong objection as I'm sure many other developers do. bash is available for all platforms and is probably more regular than bourne shell across platforms, though I think perhaps perhaps ksh might be a safer standard shell choice Putting '/bin/bash' is just as wrong as putting '/bin/ksh'. If you did the latter that script would fail to run on 90% of Linux systems. If you did the former it would certainly fail to run on a good number of *BSD systems (owned by persons alergic to bash) and maybe some Linux systems too. [...] Maybe there are other thoughts out there on which interpreter would be best for wine's purposes. '/bin/sh' is the right interpreter, there's simply no doubt about it. Perhaps Laurent might be willing to take a look at the bash dependencies, if not I'll add it to my patch list to be maintained outside the wine project until I get around to looking at it. Yes, it seems Laurent is in a pretty good position to fix this script since his '/bin/sh' does not point to bash. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;) -- Linus Torvalds
Re: Commercial support
On 5/7/05, MediaHost (TM) [EMAIL PROTECTED] wrote: 9 million hits a month != visits 509874 visits != http://www.winehq.org/site/support pages visits (as a fact, it isn't even listed under the top 30, not surprising) There is no link to this support page from our main page, and im sure there is a large number of people who don't even know it exist. So if there is better linking to this page it should receive allot more hits. At any rate you didn't answer the question of what will happen if wine is ever hijacked. But I guess it could happen even without this referral page, if it does ever happen lets just hope its not by someone listed here. But of course, $ 100 per year is a nice price, but than everybody can. Yea a nice referral for only $8.00 a month... hold on I just read Brian's mail and now the cost has just went to $0.00 sign up now at this everyday low price folks.. To bad this project will never have sponsoring like blender3d.. http://www.blender3d.org/cms/Sponsoring_prospectus.58.0.html Tom
Re: wineconsole exits immediately (Wine 20050310 debian sarge/testing)
Hello, J. Grant wrote: I was trying to run wcmd, it seems to have been renamed wineconsole. No, wcmd is still there, wineconsole is only the terminal emulation window. If you want wcmd call it something like: wineconsole --backend=user wcmd bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: Commercial support
On 5/7/05, Brian Vincent [EMAIL PROTECTED] wrote: When did this happen? I thought Jer set it up when he set up the pay-pal account, I guess not, my bad. We're a free software development community and that implies some level of trust. I can only think of the quote that's accredited to PT Barnum.. :D Tom
Re: 16 bit hwnd in SendmessageA/W
On 07 May 2005 14:21:42 +0200, you wrote: Is anything else needed, I wonder? Yes, try something like this: Index: dlls/user/win.c Works great. Thanks, Rein.
Re: 16 bit hwnd in SendmessageA/W
On Sat, 7 May 2005 19:48:02 +0900, you wrote: Rein Klazes [EMAIL PROTECTED] wrote: E:\\MSVC\\BIN\\WINTEE32.EXE -h2a -vn 5e is the 16 bit window handle. 2a I'd guess, not 5e. You guess correctly. Here it sends data to the IDE: 0035:Call user32.SendMessageA(002a,004a,0008004a,77a3fe28) ret=77a51649 That does not work, SendMessageA does only expect full 32 bit win handles. You need to find out why and how 2a became 002a in the first place. Setting the hiword to , I think. I hoped I did not need to prove that by going through the disassembled code. Rein.
Re: portability improvements for wineshelllink script
Francois Gouget wrote: This is true too but I think most Wine developers will agree with me that Wine should not depend on bash which means the above is not 'the right fix(tm)' which makes it 'the wrong fix'. Of course The Microsoft Fix(tm) would be to say ahh to hell with it. Lets make our own proprietary shell and require that everyone using our product use that :-D *ducks and runs for cover* I feel the heat of your flames already! Dustin
Re: wineconsole exits immediately (Wine 20050310 debian sarge/testing)
J. Grant wrote: Hi Michael, Thank you for your quick response. [...] I was trying to run wcmd, it seems to have been renamed wineconsole. No, wcmd is still there, wineconsole is only the terminal emulation window. If you want wcmd call it something like: wineconsole --backend=user wcmd Ok, I gave that a shot: $ wineconsole --backend=user wcmd Invoking /usr/lib/wine/wine.bin wineconsole.exe --backend=user wcmd ... err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WCUSER_SetFont wrong font wineconsole: spawning client program failed (Lwcmd), invalid/missing command line arguments ? Wine exited with a successful status ]$ lrwxrwxrwx 1 now3d now3d 25 2005-05-06 19:36 wcmd.exe - /usr/lib/wine/wcmd.exe.so That symbolic link is not flashing, but I noticed the file it points to does not exist. I attatched the list of files I do have in /usr/lib/wine/ Is it not possible to just type wcmd in bash like we used to be able to? could that not be a default or even a shell script which ran wineconsole --backend=user wcmd if that is now the way to run things ? Worksforme(TM). Seems your wine installation is broken/incomplete. I mean both methods work wcmd and wineconsole --backend=user wcmd. The later one runs a console which is fully compatible to that on Windows and some programs rely on that. And it has also the advantage that the wine debugging output (FIXME/ERR) don't clutter the output. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart
Re: Game sound problem with wine 20050310 (Debian testing)
On 07/05/05 14:54, Paul van Schayck wrote: On 5/7/05, J. Grant [EMAIL PROTECTED] wrote: I did find man wine.conf, however that is quite incomplete it seems. Incomplete and not to be trusted on accurate information. Is there a reason the man page does not state that? I wonder if this could be added to the man page? Also could /usr/share/wine/skel/config be added to the man page? No, we are dropping the config file completely. And as heads up, there will be no conversion tool to the new system. As Alexandre said: we should stop being nice [in this conversion period]. The config will be moved to the registry and winecfg. Until it is it would be very useful to have it documented. is there a reason the man page does not state it is not required anymore? Presently it states wine expects a configuration file I remember there used to be a --winver=win2k style command line argument, but it seems to have gone now. Or is it still present, but undocumented? (Or maybe I missed some documentation?) That option was dropped a bit over a year ago. So how can I set the winver when I run an program from the command prompt? I did find a copy of the wine.conf man page on the website as well, could that copy of the man page be expanded to cover all the options please? There is no list of options in the first place right now. With the system we will be looking into creating a tool that will grab all options from the source code so we can keep the list up to date. I could not find [wineoss] section documentation in any of the locations I am aware of. I just set it to 1 but it did not seem to make any difference to the audio lag unfortunately. Both the [wineoss] and [winealsa] options have never been documented. The normal behaviour though with a lack of performance and dsound is not lag but cliping sound. So I don't think it's a performance issue. I do get far more network lag than I did when running Call of Duty on win2k. Could this be caused by the sound lag? Is network lag a second issue with is sometimes common? Set the [winmm] drivers option to nothing. You won't get any sound at all. Is the lag now less? Does the case not matter? err:wave:DSDB_MapBuffer Could not map sound device for direct access (Input/output error) err:wave:DSDB_MapBuffer Use: HardwareAcceleration = Emulation in the [dsound] section of your config file ^^ had to turn this back on. then there was sound again, so I could not test. please include my email address in replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio
Re: Stable release builds with fixme output (Wine 20050310 debian sarge/testing)
On 07/05/05 16:15, Paul van Schayck wrote: On 5/7/05, J. Grant [EMAIL PROTECTED] wrote: I typically launch applications using wine from the terminal, I get pages of these fixme debug messages. I wonder if there is a reason these fixme harmless messages are being displayed? IMHO stable releases should only output err messages, thus not displaying fixme or warnings. I wonder if this has been considered already? From ANNOUNCE: This is still a developers only release. There are many bugs and unimplemented features. Most applications still do not work correctly. People choose to use whatever there is because there is no other choice, in these circumstances it would be more suitable to release a version suitable for users which will mean you get bug reports. And from BUGS: Wine is still considered alpha software and is still incomplete. There are no stable wine releases yet. However, as people have been using it for years, and giving feedback and bug reports it would be better to accept there will be interim releases. For those releases they should not be development builds. Please include my email address in replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio
Re: wineconsole exits immediately (Wine 20050310 debian sarge/testing)
Hi Michael, Thank you for your quick response. [...] I was trying to run wcmd, it seems to have been renamed wineconsole. No, wcmd is still there, wineconsole is only the terminal emulation window. If you want wcmd call it something like: wineconsole --backend=user wcmd Ok, I gave that a shot: $ wineconsole --backend=user wcmd Invoking /usr/lib/wine/wine.bin wineconsole.exe --backend=user wcmd ... err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WCUSER_SetFont wrong font err:wineconsole:WCUSER_SetFont wrong font wineconsole: spawning client program failed (Lwcmd), invalid/missing command line arguments ? Wine exited with a successful status ]$ lrwxrwxrwx 1 now3d now3d 25 2005-05-06 19:36 wcmd.exe - /usr/lib/wine/wcmd.exe.so That symbolic link is not flashing, but I noticed the file it points to does not exist. I attatched the list of files I do have in /usr/lib/wine/ Is it not possible to just type wcmd in bash like we used to be able to? could that not be a default or even a shell script which ran wineconsole --backend=user wcmd if that is now the way to run things ? Please include my email address in replies. Kind regards JG -- Homepage: http://jguk.org/ Blog: http://jguk.org/blog.rss Radio: http://jguk.org/#radio usr_lib_wine.txt.gz Description: GNU Zip compressed data
Re: wineconsole exits immediately (Wine 20050310 debian sarge/testing)
Le sam 07/05/2005 à 13:40, Michael Stefaniuc a écrit : J. Grant wrote: [snip] Is it not possible to just type wcmd in bash like we used to be able to? could that not be a default or even a shell script which ran wineconsole --backend=user wcmd if that is now the way to run things ? Worksforme(TM). Seems your wine installation is broken/incomplete. Install the wine-utils package. It is a suggested package for wine, but should be more recommended than suggested. Vincent
Re: Commercial support
Tom Wickline wrote: On 5/7/05, Brian Vincent [EMAIL PROTECTED] wrote: When did this happen? I thought Jer set it up when he set up the pay-pal account, I guess not, my bad. I registered 'The Wine Project' as a 'Doing Business As' name. Basically, this means that I have a legal right to also use that name in Minnesota; that gave me the right to create a bank account with that name. There's no official corporation around that; it's just me, and that's where the paypal money goes (bwahahahah, you're all fools to trust me grin). Last year, I spent most of the money in that account on travel subsidies. This year, we didn't get as many requests, so we're fairly flush. I need to square a few expenses; like the 100 EUR we promised for the students party fund, so I don't have an exact amount; probably $1200 or so. We've debated in the past how best to spend that money; I've come to believe that the best use of it is on Wineconf, in whatever ways make sense. Cheers, Jeremy
Re: [DInput] Fix 'peek' code for mouse (S3 problem)
It doesn't look like the normal X cursor. S3 changes the cursor the same way in Wine as it does on Windows, but I think, appart of it's look that it's the normal X cursor / the normal Windows GDI cursor. trace:dinput:SysMouseAImpl_SetCooperativeLevel (this=0x77c55f18,0x0008004c,0x0006) trace:dinput:SysMouseAImpl_SetCooperativeLevel cooperative level : DISCL_FOREGROUND DISCL_NONEXCLUSIVE ---^ And this means that the mouse cursor will NOT be hidden by DInput. So S3 really uses the standard GDI cursor at the same time than DInput. This means that one (hacky) way to fix your issue would be to disable mouse warping as soon as 'NONEXCLUSIVE' is given AND that the application did not hide the mouse cursor itself. After, one just needs to hope the application did not resort to setting an 'empty' mouse cursor :-) I wanted first to work on the real fix but as no-one answered my mail on the XOrg list yet, I will maybe do the 'hacky' patch described above waiting for things to move on the X11 side. I don't know if this Demo works with Wine. The original S3 does a lot of checks on system dlls and such, which causes the game to refuse to run on Windows XP and Wine. Bluebyte has published a modified s3.exe which makes the game start on Windows 2K, Windows XP and (as a side effect) with Wine. I don't know how the demo behaves. Nope it does not work in Wine and neither does it on WinXP. But it works fine in Win98 + QEMU :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Commercial support
Tom Wickline wrote: At any rate you didn't answer the question of what will happen if wine is ever hijacked. But I guess it could happen even without this referral page, if it does ever happen lets just hope its not by someone listed here. This is actually a very good point in favor of not charging money at all. If you charge money, you create obligation. That's the way the legal system works. If you do not, you can easily delist any known LGPL offender. Having said that, I think the focus on code contributions to wine may be exaggerated. Looking from what we know right now, there are just three companies that have the capability to change wine to fit a specific client. Of these three, CodeWeavers is the only one who is doing any significant work on wine on a regular basis. They may be some freelance work going on as well, but it seems to me most of it is for Code Weavers anyways. But of course, $ 100 per year is a nice price, but than everybody can. Yea a nice referral for only $8.00 a month... hold on I just read Brian's mail and now the cost has just went to $0.00 sign up now at this everyday low price folks.. Then again, it seems we have heard on this thread alone of three different companies that either package wine or play with it's deployment. As we learned at wineconf, not having these companies listed is a major hurdle for commercial Wine adoption, which is where money for more wine improvement ultimately comes from. This does tell us that worrying about LGPL violation should not be too serious. It seems that most commercial wine deployers don't mess with the code anyways. Now, you might say that I'm biased because I have an interest. That would certainly be true. After all, if David's company is listed, and they get much more business then they do today, as there are only three companies that can provide second tier support, I obviously stand to win. The thing is, that so does WineHQ. I don't think I have to convince anyone that I give back what I do (and sometimes fight Alexandre ferociously about getting it included), and so does Dimi. As for CodeWeavers, well, I don't think anyone involved with Wine can raise anything against them. So, ultimately, we ALL get to win from getting more money into Wine, and charging an amount that will actually allow companies to get listed (and, yes, between zero and 100$/yr, zero is more flexibile to us in getting violators delisted without mucking with the legal system). If that doesn't convince you, then try this for size. If we do charge 10K/yr, Lingnu will not be listed there. It's simply not worth it for me. If ANYONE is going to be listed there, then, it will be some huge company, with very little actual Wine involvement. Being as it is that Wine would like the commercial vendors listed too, I think that's a lose-lose. Don't you? Or do you really think that Lingnu is going to hold back code from Wine? To bad this project will never have sponsoring like blender3d.. http://www.blender3d.org/cms/Sponsoring_prospectus.58.0.html As far as I know, blender was sponsored by it's clients, not by the people who sold services for it. That is what, I believe, most free software will eventually gravitate towards. Wine, however, is not there yet. In fact, many wine hackers hardly even run wine. Tom Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
Re: [DInput] Fix 'peek' code for mouse (S3 problem)
trace:dinput:SysMouseAImpl_SetCooperativeLevel (this=0x77c55f18,0x0008004c,0x0006) trace:dinput:SysMouseAImpl_SetCooperativeLevel cooperative level : DISCL_FOREGROUND DISCL_NONEXCLUSIVE ---^ And this means that the mouse cursor will NOT be hidden by DInput. So S3 really uses the standard GDI cursor at the same time than DInput. This means that one (hacky) way to fix your issue would be to disable mouse warping as soon as 'NONEXCLUSIVE' is given AND that the application did not hide the mouse cursor itself. After, one just needs to hope the application did not resort to setting an 'empty' mouse cursor :-) I wanted first to work on the real fix but as no-one answered my mail on the XOrg list yet, I will maybe do the 'hacky' patch described above waiting for things to move on the X11 side. Well, now we know at least what's going wrong. I don't know if this Demo works with Wine. The original S3 does a lot of checks on system dlls and such, which causes the game to refuse to run on Windows XP and Wine. Bluebyte has published a modified s3.exe which makes the game start on Windows 2K, Windows XP and (as a side effect) with Wine. I don't know how the demo behaves. Nope it does not work in Wine and neither does it on WinXP. But it works fine in Win98 + QEMU :-) Interesting. The full version didn't work for me.(Win95 + qemu and WinXP + Qemu). What qemu version do you use? Many thanks for your help so far. Stefan
Re: [DInput] Fix 'peek' code for mouse (S3 problem)
Am Samstag, 7. Mai 2005 19:30 schrieb Lionel Ulmer: It doesn't look like the normal X cursor. S3 changes the cursor the same way in Wine as it does on Windows, but I think, appart of it's look that it's the normal X cursor / the normal Windows GDI cursor. trace:dinput:SysMouseAImpl_SetCooperativeLevel (this=0x77c55f18,0x0008004c,0x0006) trace:dinput:SysMouseAImpl_SetCooperativeLevel cooperative level : DISCL_FOREGROUND DISCL_NONEXCLUSIVE ---^ And this means that the mouse cursor will NOT be hidden by DInput. So S3 really uses the standard GDI cursor at the same time than DInput. Just an update: I just noticed that S3 has a registry setting called GDIMouse. This setting is reflected by the use colored mouse pointer(if possible) / use monochrome mouse pointer settings. (Benutze farbigen Mauszeiger(wenn möglich) and Benutze monochrimen Mauszeiger in my German version). Changing this Setting has no effect on S3 in Wine. I suppose S3 fails to draw its own mouse pointer in Wine and falls back to the GDI one. I don't know why I didn't notice this earlier
Re: [DInput] Fix 'peek' code for mouse (S3 problem)
Interesting. The full version didn't work for me.(Win95 + qemu and WinXP + Qemu). What qemu version do you use? Well, I use a REALLY old QEMU version from CVS (my binary is from July 2004 :-) ). It works fine for my images so I never bothered to upgrade since then. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [DInput] Fix 'peek' code for mouse (S3 problem)
I just noticed that S3 has a registry setting called GDIMouse. This setting is reflected by the use colored mouse pointer(if possible) / use monochrome mouse pointer settings. (Benutze farbigen Mauszeiger(wenn möglich) and Benutze monochrimen Mauszeiger in my German version). Changing this Setting has no effect on S3 in Wine. I suppose S3 fails to draw its own mouse pointer in Wine and falls back to the GDI one. In that case, you need to do a +dinput,+cursor,+ddraw,+event trace to see if it puts DInput in 'EXCLUSIVE' mode and also if there are no cursor calls once the game starts (as there is no need to change the GDI cursor if the game is using its own). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: portability improvements for wineshelllink script
On Sun, 8 May 2005 03:30 am, Dustin Navea wrote: Francois Gouget wrote: This is true too but I think most Wine developers will agree with me that Wine should not depend on bash which means the above is not 'the right fix(tm)' which makes it 'the wrong fix'. Of course The Microsoft Fix(tm) would be to say ahh to hell with it. Lets make our own proprietary shell and require that everyone using our product use that :-D *ducks and runs for cover* I feel the heat of your flames already! Dustin yes, they should all be written using command.com or cmd.exe, honest thay should .-) Bob
Re: Solaris compatibility - libs/wine/loader.c
On Sat, 7 May 2005 11:47 pm, Alexandre Julliard wrote: Robert Lunnon [EMAIL PROTECTED] writes: Notes about patch: Solaris requires RTLD_FIRST flag to dlopen calls to resolve multiple path expansions properly This doesn't seem to be what RTLD_FIRST does. Could you explain a bit more exactly what the problem is? Originally the problem manifested itself on Solaris 10 with ld.so.1 emitting a diagnostic: potential multiple path expansion requires RTLD_FIRST when this happens, ld.so.1 fails the dlopen and wine usually falls over. RTLD_FIRST: The way I understand it (and I don't very well) the Solaris linker has an internal macro like capability, where the path to a group of libraries can be represented by a single symbol. The RTLD_FIRST flag makes ld.so.1 select the FIRST library which resolves a dependency when there are multiple possibilities as a result of such an expansion. According to docs.sun.com the flag seems to have the side-effect of hiding subsequent dependencies from a parent object, So for example wine, can't rely on say winmm.dll.so.1 importing the symbols from the driver so the wine executable can use them directly. In practise the limitation doesn't seem to be a problem, wine does import directly all the DSOs it needs correctly for this flag to work. I pondered this problem for quite a while, but this problem apparently doesn't come up much and even the sun engineers couldn't help much with how to identify the collision or how to resolve the problem. After a while investigating I decided I'd just do what the diagnostic said, which in fact did resolve the problem and doesn't have any undesirable side-effects that I have identified.
Re: Solaris Compatibility -dlls/wineps/driver.c
On Sat, 7 May 2005 11:46 pm, Alexandre Julliard wrote: Robert Lunnon [EMAIL PROTECTED] writes: Notes about patch: PAGESIZE is a risky name for a symbol since it an obvious candidate for use to define the page size of the OSes VM pages and in fact does Collide under Solaris We already have a #undef PAGESIZE to work around that problem. If it doesn't work you probably need to tweak the include files order. Hmm, I didn't look for this workaround when i reviewed the patches for submission. Since this is a fairly old patch, it's possible it was fixed with the #undef workaround after I applied this fix. I'll try deprecating the patch from my build system. Personally though, I think it'd be better for this symbol to be unambiguous than to #undef it. Bob
Bug 2905
Can someone take a look at the attached debug output and let me know what might be the problem? The game crashes under wine, regardless of the winver (could be an old wine version), and also under real Win2k, but not under real Win98.. I doubt there is much hope for getting this working, since it even crashes in Win2k, but since it's reported, I should go ahead and report it to you all anyways.
[patch] fix delete key on certain european keyboards
reposting this here, looking for someone to fix a long standing wine bug.
text [edited] again:
well, this is just this:
http://bugs.winehq.org/show_bug.cgi?id=2400
and should apply to today's cvs.
i AM NOT the author!
it IS kinda urgent, since a lot of european keyboards are affected...
like hungarian, croatian, slovenian... all have delete key producing
delete,
instead of delete. this patch is just a works here workaround,
see url for more details.
i got response from some people, so i fixed comments, but what needs to
be tuned, according to mr. Dmitry Timoshkov, is that it should use
symbolic key(sym) names instead of hardcoded numbers. seems like a
trivial task for a programmer (which i am not)
so, anybody up to it?
Changelog:
* dlls/x11drv/keyboard.c
Arpad Biro [EMAIL PROTECTED]
(modified to current cvs by Marin Glibic [EMAIL PROTECTED])
This fixes the problem is that when NumLock is active, both Del
keys perform a delete action _and_ insert a comma (the decimal character).
--- dlls/x11drv/keyboard.c.orig 2005-05-05 23:33:23.0 +0200
+++ dlls/x11drv/keyboard.c 2005-05-05 23:38:44.0 +0200
@@ -1067,11 +1067,14 @@
else
XLookupString(e, NULL, 0, keysym, NULL);
-if ((keysym = 0xFFAE) (keysym = 0xFFB9) (keysym != 0xFFAF)
-(e-state NumLockMask))
-/* Only the Keypad keys 0-9 and . send different keysyms
- * depending on the NumLock state */
-return nonchar_key_vkey[keysym 0xFF];
+if (e-state NumLockMask) /* NumLock is active */
+{if (keysym == 0xFFAC) /* Numeric Del pressed */
+ return keyc2vkey[0x3B];/* comma */
+ if ((keysym = 0xFFAE) (keysym = 0xFFB9) (keysym != 0xFFAF))
+ /* Only the Keypad keys 0-9 and . send different keysyms
+ * depending on the NumLock state */
+ return nonchar_key_vkey[keysym 0xFF];
+}
TRACE_(key)(e-keycode = %x\n, e-keycode);
Bug 2131 - 16-bit support?
I was wondering, since I have been away for so long, are we still implementing functionality for 16-bit programs? The reason I ask is because the freecell and solitaire from Win98/ME will not load in wine, while the ones from 2k/XP will. This is obviously due to the fact that our cards.dll is 32-bit only, whereas the cards.dll in Win98/ME is 16-bit. Of course, the Win98/ME versions of the games wont start on WinXP either for the same reason. Basically, I just need to know for the purposes of resolving this bug, should I leave it open and confirmed so that someone knows to implement the 16-bit functions (32 - 16 bit conversions?), or should I just go ahead and close it as WONTFIX? Dustin
Re: Bug 2131 - 16-bit support?
On 05/08/2005 03:09:39 AM, Dustin Navea wrote: Basically, I just need to know for the purposes of resolving this bug, should I leave it open and confirmed so that someone knows to implement the 16-bit functions (32 - 16 bit conversions?), or should I just go ahead and close it as WONTFIX? You got me wrong, I didn't mean WONTFIX because it's 16 bit code but because both the 32 bit and the 16 bit DLLs share the same name. (and so do the APIs) Fixing this would require hacking the NE loader, winemaker and probably some more code. (and I stopped there since it didn't seem to be worth the effort) Implementing the 16 bit routines by wrapping them around the 32 bit ones would be easy otherwise. -flx
Assertion fails in riched20; relay debug segfaults
The wine version of riched20 fails an assertion when starting
StreamboxVCR
$ wine .wine/drive_c/Program\
Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe
fixme:ole:CoRegisterMessageFilter stub
fixme:ole:CoCreateInstance no classfactory created for CLSID {4955dd33-
b159-11d0-8fcf-00aa006bcc59}, hres is 0x80040154
err:ole:ITypeInfo_fnInvoke did not find member id fdfa, flags 4!
err:ole:ITypeInfo_fnInvoke did not find member id fdfb, flags 4!
fixme:richedit:RichEditANSIWndProc WM_SETFONT: stub
wine-pthread: run.c:522: ME_CalcRunExtent: Assertion `size.cx' failed.
fixme:ole:ITypeInfo_fnRelease destroy child objects
Along with a popup dialogue box from the visual C++ runtime library
indicating abnormal program termination. The file run.c appears to be
part of riched20, and indeed overriding the load order to native only
for that DLL allows the program work.
All reasonably standard debugging so far, and I went for some more
logging to aid tracing the problem (or to log in bugzilla when it all
gets too hard for my skill level ;-) )
$ WINEDEBUG=+relay wine .wine/drive_c/Program\
Files/StreamboxVcrSuite2/StreamBoxVCR1Beta31/vcr_31turbo.exe
0009:Call kernel32.__wine_kernel_init() ret=55727d9e
Segmentation fault
Shortest relay trace I've ever had! But I'm not really sure where to go
from here... Running GDB on it gives me no useful results. I have an
AMD64 box running Fedora Core 3 and wine is the latest from CVS.
I'm going to try some other tracing to look at the riched problem, but
+relay crashing seems serious to me.
Adrian
