- Wine-Devel - list.winehq.org

Re: Win XP installation support?
by Hetz Ben-Hamo Dec. 3, 2001

Dec. 3, 2001

Yes, that helps, could you commit it to the CVS please? Thanks, Hetz On Monday 03 December 2001 19:27 pm, you wrote: > At 05:57 PM 03/12/2001 +0200, you wrote: > >It doesn't patches currectly, got rejection (which is enclosed). > > Try with -l option > > Gerard

1 0

Re: Proposed solution for mouse capture problems
by Alexandre Julliard Dec. 3, 2001

Dec. 3, 2001

Jukka Heinonen <jhei(a)iki.fi> writes: > 1. Function process_raw_mouse_message should only determine which > window was under mouse and resend message to that window as > a cooked message. Everything else (especially separating normal > messages from nonclient messages and handling mouse captures) > should be moved to process_cooked_mouse_message. Actually, > I fail to see why raw messages are needed at all, since function > SendInput could do this as well. No, processing raw messages requires sending messages to the app (mainly WM_NCHITTEST) and you cannot do this from anywhere. Also if you separate the window determination from the rest you'll have to send two WM_NCHITTEST for every message which is clearly wrong. Maybe what we should do is when the cooked message is rejected by the message filter it should be queued back as a raw message and processed again next time around. > 3. Supporting multi-threaded capture is actually the easiest part, > although it might be quite useless (Does any application really > require it?). When mouse button is pressed in capturing window, > process_cooked_mouse_message sets process-wide flag that states > that global capture is in effect. After that, either > process_raw_mouse_message or SendInput sees that this flag is > set and resends all mouse messages to capturing window until > button release message is received, which clears the flag. I'm not sure what you are trying to fix here. This should already work fine, X takes care of sending messages to the right thread when mouse is captured. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Win XP installation support?
by Gerard Patel Dec. 3, 2001

Dec. 3, 2001

At 04:47 AM 03/12/2001 +0200, you wrote: >I thought about that too, but it's not - here is the line from my /etc/fstab > >/dev/hda5 /mnt/win vfat defaults 0 0 >/dev/hda3 /mnt/dosc vfat defaults 0 0 > Try to apply the following patch to wineconf : --- wineconf.orig Thu Jun 7 22:25:06 2001 +++ wineconf Mon Dec 3 08:40:42 2001 @@ -146,6 +146,7 @@ my(@FATD)=@::FatDrives; my(@wininis) = (); my ($winini); + my ($ThisDrive); if (!$::opt_windir && !$::opt_fast && !$::opt_thorough) { $::opt_thorough++; @@ -161,8 +162,7 @@ } elsif ($::opt_thorough) { if ($::opt_debug) { print STDERR "DEBUG: Num FATD = ", $#FATD+1, "\n"; } - foreach(@FATD) { - my $ThisDrive = shift(@FATD); + foreach $ThisDrive (@FATD) { my $MntPoint = $ThisDrive->[1]; push(@wininis, `find $MntPoint -iname win.ini -print`); }¨\ Gerard

1 0

Win XP installation support?
by Hetz Ben-Hamo Dec. 2, 2001

Dec. 2, 2001

Hi, I have installed wine cvs and I have here on this machine Windows XP pro installed.. now - the partition is fat32 and I can access it with /mnt/win without any problem. However, the tools/wineinstall script simply doesn't recognize my windows partition: windows]$ ls -l win* -rwxrwxrwx 1 root root 256192 Aug 23 13:00 winhelp.exe -rwxrwxrwx 1 root root 266752 Aug 23 13:00 winhlp32.exe -rwxrwxrwx 1 root root 504 Dec 1 22:25 win.ini -rwxrwxrwx 1 root root 48680 Aug 23 15:00 winnt256.bmp -rwxrwxrwx 1 root root 48680 Aug 23 15:00 winnt.bmp [hetz(a)witch windows]$ pwd /mnt/win/windows Now - running tools/wineinstall gives me this: wine]$ tools/wineinstall WINE Installer v0.7 Warning !! wine binary (still) found, which may indicate a (conflicting) previous installation. You might want to abort and uninstall Wine first. I see that WINE has already been configured, so I'll skip that. Hmm, looks like WINE is already compiled. I'll skip that too, I guess. You aren't root, so I'll skip the make install. NOTE! To run Wine without installing, you must set the environment variable LD_LIBRARY_PATH to /home/hetz/wine:/home/hetz/wine/dlls in your logon scripts. Create local config file ~/.wine/config? (yes/no) yes Found existing /home/hetz/.wine/config, if you continue this file will be overwritten. Continue running wineinstall? (yes/no) yes Searching for an existing Windows installation... not found. (no matching /etc/fstab mount entry found) Windows was not found on your system, so I assume you want a Wine-only installation. Am I correct? (yes/no) No, it's not correct. Any suggestions? (sorry if the email doesn't belong to this list) Thanks, -- Hetz Ben Hamo

2 3

Re: Include only needed headers in programs/winhelp
by Francois Gouget Dec. 2, 2001

Dec. 2, 2001

On Sun, 2 Dec 2001, James Juran wrote: > James Juran <jamesjuran(a)alumni.psu.edu> > Only include the necessary files to avoid conflicts in gethostname > prototypes between winsock.h and unistd.h 'unistd.h' does not exist on Windows. Since this is a Winelib application it would be good to try to make it compile on Windows too. So I would rather be in favor of removing the 'unistd.h' #include directive unless something prevents that. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy

2 4

gethostname prototypes [was: Re: wine's winhelp doesn't compile]
by James Juran Dec. 2, 2001

Dec. 2, 2001

[taken to wine-devel, thread originally started in newsgroup] gerard patel wrote: > > >james[1]%rpm -qf /usr/include/unistd.h > >glibc-devel-2.2.4-19 > > glibc-devel-2.2.2-4mdk > > >james[2]%grep gethostname /usr/include/unistd.h > >extern int gethostname (char *__name, size_t __len) __THROW; > > extern int gethostname (char *__name, socklen_t __len) __THROW; > > ./include/bits/types.h:typedef unsigned int __socklen_t; This could be a problem. According to the glibc CVS, http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/include/unistd.h.diff?r1=…, the type of the 2nd argument changed from int to size_t on 2001/3/21. According to the CVS tags, this change was first released in glibc-2.2.3. We were able to work around this problem in programs/winhelp by not including winsock.h, but could this problem crop up anyplace else? It seems that it is currently impossible to include unistd.h and winsock.h on a machine with glibc >= 2.2.3. -- James Juran jamesjuran(a)alumni.psu.edu

2 1

Re: compatible DC/Bitmap fixes
by Ove Kaaven Dec. 2, 2001

Dec. 2, 2001

On Sat, 1 Dec 2001, eric pouech wrote: > as Marcus reported, the console was only working in black & white > the cause of the error comes from the following flow > > 1/ GetDC (physical and/or display) > 2/ CreateCompatibleDC (on DC gotten from 1/) > 3/ CreateCompatibleBitmap (on DC gotten from 2/) What you *should* do is to call CreateCompatibleBitmap on the DC you got from GetDC. That's what all the Windows code I know of does. > the trouble is as follows : > - when a mem DC is created, its bits per pixel is always set to 1 Yes, that's documented Windows behaviour. You need to select a bitmap into it to change it. No Windows code expects otherwise.

1 0

DOS issue
by Johan Gill Dec. 1, 2001

Dec. 1, 2001

Trying Monkey Island 1 & 2 with wine, I get very slow animation and a lot of err:module:DOSVM_Wait dosvm wait error=5. It seems to be wineserver related, so I'd rather not dig too deep without some feedback. There is a brief trace without any special flags at http://www.lysator.liu.se/~johane/monkey2_brief.txt. I ended the execution with Ctrl-C. A trace with +server,+module,+relay is available as http://www.lysator.liu.se/~johane/monkey2_zoom.txt. I've cut everything after the second occurence of the error. /Johan Gill, johane(a)lysator.liu.se

1 0

Re: Access Control Functions
by Mike McCormack Dec. 1, 2001

Dec. 1, 2001

Hi Karl, > Everything works okay until we get to the access control functions. > advapi32.OpenProcessToken calls ntdll.OpenProcessToken, which is just a > stub. Did you try different -winver flags? it OpenProcessToken shouldn't be used in Win98.... That being said, it would be a very good thing to have a better security framework. Maybe we can even use it to integrate with samba-tng one day. i think you'd be looking to make a "token" object in the server. > I also am having trouble finding documentation on the make_requests tool. Well, run it after modifying server/protocol.def to propagate you changes to server/trace.c and include/wine/server.h. The format of the protocol.def file should be self explanatory... if i remember correctly, there are some small quirks like "void* xxx" works, but "void *xxx" doesn't. Mike ------------------------------------------ mailto:Mike_McCormack(a)start.com.au ph +82 16 430 0425 __________________________________________________________________ Get your free Australian email account at http://www.Looksmart.com.au

1 0

Access Control Functions
by Karl Bielefeldt Nov. 30, 2001

Nov. 30, 2001

I am new to open source development and to the wine project so please forgive me for sounding like a newbie. I think wine is great and the key to the growth of Linux in the desktop market. I decided to begin my efforts by debugging the installation of MS Money 2001 (my wife's must-have MS program) on a completely non-windows box. This led to needing to install the msiexec installer (instmsia.exe, available from MS website). Everything works okay until we get to the access control functions. advapi32.OpenProcessToken calls ntdll.OpenProcessToken, which is just a stub. Now, as far as I can tell, the stubs default to the least restrictive set of permissions, which I believe is fine for our purposes. The problem comes when the program calls kernel32.CloseHandle on the non-existent handle that was returned by the OpenProcessToken stub. Somebody please stop me if there is an easier way of solving this problem. It looks like we at least need to create some sort of dummy handle that can be removed by kernel32.CloseHandle without causing an error. To do this we would need to add an open_process_token request handler to the wineserver (perhaps in a new file server/access.c). Another alternative would be to create an open_dummy_handle request handler in server/handle.c that could be used for any generic dummy handle. The advantage of the first method is that if someone decides to implement all the access control functions properly, the framework is already in place. Probably some combination of the two is best. I am willing to do the coding myself, but I'm unsure of the procedures for open source development. How do you decide what changes are to be made, how do you submit your changes, how do you make sure you don't undo what someone else did, and things like that? I also am having trouble finding documentation on the make_requests tool. Thanks for tolerating my newbieness. I'm looking forward to being able to start contributing to this great project. --Karl Bielefeldt kbielefe(a)hotmail.com _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

3 2