Re: Winelib's role in converting Windows applications

2005-05-07 Thread Shachar Shemesh
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

2005-05-07 Thread Shachar Shemesh
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)

2005-05-07 Thread Paul van Schayck
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

2005-05-07 Thread Robert Lunnon
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

2005-05-07 Thread Robert Lunnon
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

2005-05-07 Thread Stefan Dösinger

 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

2005-05-07 Thread Joris Huizer
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)

2005-05-07 Thread Andreas Mohr
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

2005-05-07 Thread Rein Klazes
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

2005-05-07 Thread Dmitry Timoshkov
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

2005-05-07 Thread Francois Gouget
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

2005-05-07 Thread David Gümbel
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

2005-05-07 Thread Mike Hearn
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

2005-05-07 Thread Mike Hearn
On Sat, 07 May 2005 18:13:41 +1000, Robert Lunnon wrote:
 Comments anyone ?





Re: Stack size allocations

2005-05-07 Thread Robert Lunnon
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

2005-05-07 Thread Alexandre Julliard
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

2005-05-07 Thread Mike Hearn
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

2005-05-07 Thread Robert Lunnon
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

2005-05-07 Thread Alexandre Julliard
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

2005-05-07 Thread Tom Wickline
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

2005-05-07 Thread MediaHost (TM)




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

2005-05-07 Thread Brian Vincent
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

2005-05-07 Thread Alexandre Julliard
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)

2005-05-07 Thread Paul van Schayck
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)

2005-05-07 Thread J. Grant
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)

2005-05-07 Thread J. Grant
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)

2005-05-07 Thread J. Grant
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)

2005-05-07 Thread J. Grant
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)

2005-05-07 Thread J. Grant
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)

2005-05-07 Thread Paul van Schayck
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

2005-05-07 Thread Francois Gouget
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

2005-05-07 Thread Tom Wickline
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)

2005-05-07 Thread Michael Stefaniuc
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

2005-05-07 Thread Tom Wickline
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

2005-05-07 Thread Rein Klazes
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

2005-05-07 Thread Rein Klazes
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

2005-05-07 Thread Dustin Navea
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)

2005-05-07 Thread Michael Stefaniuc
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)

2005-05-07 Thread J. Grant

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)

2005-05-07 Thread J. Grant

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)

2005-05-07 Thread J. Grant
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)

2005-05-07 Thread Vincent Béron
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

2005-05-07 Thread Jeremy White
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)

2005-05-07 Thread 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.

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

2005-05-07 Thread Shachar Shemesh
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)

2005-05-07 Thread Stefan Dösinger

 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)

2005-05-07 Thread Stefan Dösinger
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)

2005-05-07 Thread Lionel Ulmer
 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)

2005-05-07 Thread Lionel Ulmer
 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

2005-05-07 Thread Robert Lunnon
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

2005-05-07 Thread Robert Lunnon
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

2005-05-07 Thread Robert Lunnon
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

2005-05-07 Thread Dustin Navea
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

2005-05-07 Thread zhilla
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?

2005-05-07 Thread Dustin Navea
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?

2005-05-07 Thread Felix Nawothnig
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

2005-05-07 Thread Adrian Harvey
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