December 2001 - Wine-Devel - list.winehq.org

Re: Include only needed headers in programs/winhelp

by James Juran

Francois Gouget wrote: > > 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. <unistd.h> is only included in lex.yy.c, which is generated by flex from macro.lex.l. Flex includes <unistd.h> to get the definition of isatty(). The original compilation error was in compiling lex.yy.c, which includes unistd.h and macro.h. macro.h included windows.h, which included winsock.h, which created the conflict on the gethostname() prototype. So it seems the real conflict is in using flex in Winelib applications that (directly or indirectly) include windows.h on systems with glibc >= 2.2.3. Since I would think that flex wouldn't be used to port a real Windows application to Wine, I would think this isn't a significant problem. Unless someone knows a way to keep flex from including unistd.h, I think this patch is still necessary. James -- James Juran jamesjuran(a)alumni.psu.edu

Dec. 2, 2001

Re: Include only needed headers in programs/winhelp

by Francois Gouget

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

Dec. 2, 2001

gethostname prototypes [was: Re: wine's winhelp doesn't compile]

by James Juran

[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

Dec. 2, 2001

Re: compatible DC/Bitmap fixes

by Ove Kaaven

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.

Dec. 2, 2001

DOS issue

by Johan Gill

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

Dec. 1, 2001

Re: Access Control Functions

by Mike McCormack

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

Dec. 1, 2001

Re: Access Control Functions

by Gregory Hicks

Does this mean wine has a new author working on it? cheers lawson_whitney(a)juno.com wrote: > On Fri, 30 Nov 2001, Karl Bielefeldt wrote: > > > 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). > > I contribute to wine so we can have windows without microsoft, and what > do people do with it? Try to get it to run microsoft apps, of course. > Don't mind me, I am only the oddest of wine's 300 odd authors. > > > > 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. > > Just do it as best you can, test it, and if it works for you, make up a > patch against the current cvs and offer it on wine-patches. It is up to > Alexandre Julliard if he will accept it without comment, ignore it > without comment, or tell you what he doesn't like. Patches without an > accompanying ChangeLog entry (to go into <wine>/ChangeLog) or patches > made by diff without -u tend to be silently ignored. If you think about > it, diff -u is the only reasonable format for an open-source project. > I make patches by making a shadow before and after wine direcrory tree > (with cp -Ppar from <wine>) and doing diff -urN before after; no doubt > this is obsoleted by cvs, but it still works. You can also offer your > patch for comments on wine-devel before offering it to wine-patches. > > AFAICT, the only doco on make_requests is the file itself (complete with > obsolete comments) and the generated comments in the files it generates. > All requests are defined in server/protocol.def, and make_requests > generates the headers and trace code to suit. AFAICT. > > > 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 > > Maybe somebody else will make a better answer. If not, I hope this > helps. > > Lawson > ---oof---

Dec. 1, 2001

Re: Access Control Functions

by lawson_whitney＠juno.com

On Fri, 30 Nov 2001, Karl Bielefeldt wrote: > 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). I contribute to wine so we can have windows without microsoft, and what do people do with it? Try to get it to run microsoft apps, of course. Don't mind me, I am only the oddest of wine's 300 odd authors. > > 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. Just do it as best you can, test it, and if it works for you, make up a patch against the current cvs and offer it on wine-patches. It is up to Alexandre Julliard if he will accept it without comment, ignore it without comment, or tell you what he doesn't like. Patches without an accompanying ChangeLog entry (to go into <wine>/ChangeLog) or patches made by diff without -u tend to be silently ignored. If you think about it, diff -u is the only reasonable format for an open-source project. I make patches by making a shadow before and after wine direcrory tree (with cp -Ppar from <wine>) and doing diff -urN before after; no doubt this is obsoleted by cvs, but it still works. You can also offer your patch for comments on wine-devel before offering it to wine-patches. AFAICT, the only doco on make_requests is the file itself (complete with obsolete comments) and the generated comments in the files it generates. All requests are defined in server/protocol.def, and make_requests generates the headers and trace code to suit. AFAICT. > 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 Maybe somebody else will make a better answer. If not, I hope this helps. Lawson ---oof---

Dec. 1, 2001

Access Control Functions

by Karl Bielefeldt

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

Dec. 1, 2001