Joysiick under Wine
I've seen a couple of messages about getting USB joysticks working under Wine, but do regular (i.e. gameport) sticks work? I've confirmed that my stick is being read by Linux, and that it is reporting events correctly. Now, how do I get Wine to pass them along? I've confirmed: 1) that I have read/write permissions to /dev/js0 2) that Wine tries to read /dev/js0 3) that Wine indeed does read from /dev/js0, but that 4) Wine shortly thereafter closes /dev/js0, never to read it again. Do I need to have the X Window system joystick driver loaded? Or do I need to add something to the system.ini or .wine/config files. This is a Windowless install, under RH6.1, with 2.4.6, and a CVS pull of Wine from a few days ago. I'm trying to get HalfLife running under Wine. I have the GL working, I have sound working, but I am one of those strange fellows that likes to move with a stick, and look with a mouse. Are there any Windows/Wine tools that I can run to try to troubleshoot this?
Mixed mode CD's and volume label
I was trying to get Half-Life running under Wine last night, and ran into a problem with getting the CD label under Wine. Since the HL CD is a mixed mode data/audio disk (as are most game disks nowadays) Wine complained with a We don't have a way of determining the label of a mixed mode CD - Linux doesn't allow raw access ! However, Xcdroast was easily able to access the data. As an experiment, I disabled this check in misc/cdrom.c, and it worked quite happily. Perhaps this check is out of date. Perhaps it is my system setup: 2.4.6-pre7, Samsung CD-Writer/DVD reader on IDE, ide-scsi module loaded, Wine configured to use the /dev/scd0 link. Now, if I could just work out why the OpenGL is flashing...
server:truncated to 32768
With a fresh build of last night's CVS pull, when I attempt to run Delorme's AAA MapNGo V4.0, I get the following error condition: server:truncated to 32768 server:truncated to 32768 At this point the main window of the application is up. However, if I try to do anything non-trivial with the app, it coughs up this error: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 1 (X_CreateWindow) Serial number of failed request: 1663 Current serial number in output stream: 1668 and one of the app threads dies. However, the main app window is still up, and four of its threads (plus the wineserver) are still alive. The app stops responding to the system, however. Where do I start on debugging this? What should I trace?
Re: some unimplemented COM stuff
> Because all I have is an IDispatch pointer and a vtable offset to the method.
> Calling Invoke itself is not a problem at all. The method to be called by
> Invoke isn't known at compile time.
> -Malte
>
It sounds to me like you have an impedance mismatch: you have a system
that wants to call a C linkage function, and you want to tie it into a
C++ object.
What you'll have to do is something like this:
class Base_class
{
...
virtual RETTYPE Real_func(arg1, arg2, ) = 0;
static RETTYPE Entry_func_stub(void *dis, arg1, arg2, )
{
Base_class *ptr = (Base_class *)dis;
return dis->Real_func(arg1,arg2,);
}
void Hook_up_function(void)
{
Set_some_func_ptr(Entry_func_stub,(void *)this);
}
};
class Child1: public Base_class
{
RETTYPE Real_func(arg1,arg2,);
};
Class Child2: public Base_class
{
RETTYPE Real_func(arg1,arg2,);
};
The stub function in the base class can be coorced into having non-C++
linkage with an appropriate declaration, and will call the appropriate
vtable entry and offset the this pointer correctly.
While I've not done this under Wine or Windows, I have done this sort of
thing in several RTOSs with great success.
Enabling backing store
Has any thought been given to enabling backing store on Wine's windows? As it stands now, when you obscure a Wine window, it forces the Windows app to redraw the screen. Many times this is not needed. Perhaps a configuration option to allow certain apps to have backing store on would be useful. I know that up until a few months ago, it was possible to go into wnd.c and change the default from NotUseful to WhenMapped and things seemed to work well. However, the structure of the X driver has changed, and a simple patch is no longer possible.
SPAM [Fwd: GlobalHandle]
Is this list moderated at all? I keep getting spams bounced off the list server. [EMAIL PROTECTED] writes: > What I want here is sort of an INTERNAL_IsBadReadPointer that doesn't > generate a fault, but I haven't found one. I think the API is faulty > enough that we don't need to add any extra faults to it. I guess I > could invent one if it seems to be a good idea, but I thought I'd like > to ask first before I reinvent the wheel. I'm not sure why you don't want to generate a fault (or how you would do it for that matter). What's wrong with wrapping the whole function inside an exception handler? -- Alexandre Julliard [EMAIL PROTECTED]
Wine stack size, and EBP
I have several purchased Windows programs that all exhibit the same sort of problem: in the main they work, but double clicking on items causes an exception with EBP set to 0. I was trying the lastest QuickTime player, and it would die with a stack overflow error. My question is: is there a limited size stack used at some point in Wine, and if so, is it possible to adjust the size. I'd like to crank it up on my local build and see what happens. Also, is the backingstore=WhenMapped patch ever going to make it into Wine? I've done it to my local copy and it seems to have no ill effects, and it speeds up the program when moving the windows around under Gnome/Sawfish.
Exception handler w/ EBP==0
I'm trying to get Delorme's AAA MapNGo V4.0 running under Wine, with a fair degree of sucess, but one thing keeps me from being able to use the program. The program is a trip planning package, wherein you enter your desired stops, and it computes the route (US highways, state roads, etc.) to take. It also has a database of hotels, attractions, etc. that can be searched. Quite a nice program, and I wish Delorme (www.delorme.com) would port it natively to Linux. However, under Wine, once the route has been computed, it is displayed as a list of text items (roads to take) and a map (2000_07_30_214120.png). You are supposed to be able to double-click on a road, and the map will zoom in on that segment of the trip. Unfortunately, what does happen is a unhandled exception 0xc005 within the application. When I try to debug it, I'm inside an exception handler in the application, with EBP == 0, thus preventing me from doing a back trace to try to get an idea of what went wrong. So, I'm looking for tips. Any good ideas? I'm more of an embedded programmer than a Windows programmer, but I have *shudder* done some NT device drivers. This is with a fresh copy of CVS circa this morning, on RH6.2, XFree 4.01 (from the dri.sourceforge.net CVS), and sawfish, on a Celeron 350. The machine has a Win95 install on it that Wine is pointing to. Any other info I can give, just ask. Any good tips on tracing through the morass that is a Windows app, I'll take.
Test apps for Wine 1.0
I'd like to suggest the Delorme MapNGo/Street Atlas family of applications: first because I use them ;^) but also they use sound, basic graphics (no 3D), and some Internet connectivity functions. Seems to me they'd be a good broad test case.
