January 2003 - Wine-Devel - list.winehq.org

Re: Explorer

by Dimitrie O. Paun

On January 31, 2003 01:44 pm, Steven Edwards wrote: > If the WINE project is going to start a implementation of explorer.exe then > we will work off of that. Having a Wine-explorer would be a useful addition I think. It would give us a nice browser (people coming from Windows will appreciate it), and a good test for our shell32 and listview stuff. Having just a wrapper around whatever we have now is not that useful. But again, this is more a project for Wine 1.0 or beyond, not 0.9. I'll add it to my Fun Projects page. -- Dimi.

Jan. 31, 2003

Re: Guess who's back, back again... :)

by Dimitrie O. Paun

On January 31, 2003 11:57 am, Shachar Shemesh wrote: > If your'e now a freelancer with less free time, does that not mean you > are now a freelancer making more money? That is, generally speaking, a > good thing. Well, yeah... :) > Good luck, either way. Same to you. It's really just a matter of obsession how much time you spend on Wine, irrespective of full-time or contract :) -- Dimi.

Jan. 31, 2003

Re: PATCH - wineserver sock.c porting fix

by Dan Kegel

Steven Edwards wrote: > Working on building wineserver on mingw Please batch your changes... one patch a day for all #ifdef HAVE_foo_H patches would be perfect. -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 31, 2003

Re: PATCH: Get rid of superfluous dup() and close() calls.

by Alexandre Julliard

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > The dup() in wine_server_handle_to_fd() requires dozens of close() > calls spread over the wine code. I think this is confusing and error-prone > (close() calls are easily forgotten, leading to rapid fd leak - actually, > when looking through the code, I found a number of functions where I > had expected a close(), but it was lacking). > Moreover, I can't see why that dup() is necessary (any more). I think it's cleaner to return a dup of the fd instead of relying on the fact that the fd is cached internally. This may not always be the case, and it's better to risk an fd leak than to risk invalidating the cached value in case someone closes the fd when they shouldn't. -- Alexandre Julliard julliard(a)winehq.com

Jan. 31, 2003

Re: Stdole2 / Stdole32 (RESEND)

by Alexandre Julliard

"Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> writes: > There are a couple of things to note about this patch. > The first is that this only really provides the stdole2.tlb resource data > since it is just an alias for oleaut32.dll and there can be only one > resource of each type for a given id, so I am not 100% sure at the moment > whether it will work properly for those apps wanting stdole32. Looks like it has to be made a separate dll then, since that's how Windows does it. Also we need a way to generate that file, I'm not going to put the compiled binary file into CVS. -- Alexandre Julliard julliard(a)winehq.com

Jan. 31, 2003

Started playing with Wineserver on mingw/cygwin again

by Steven Edwards

well I made it serial.c before I had to run to work. I'm having good luck getting alot of the objects to compile so far I've only had to kill file.c, ptrace.c, request.c and select.c. Getting this to build and run on Windows is going to be a bitch =) gettimeofday, fork and all of fd and networking is going to be the hard part. I've started a tempory header to see what will need to be implemented in libwine if we want to get wineserver up and running on Windows without cygwin. Cygwin still really needed get/setthreadcontext (hint, hint) Thanks Steven /* I kill'd file.c, ptrace.c, request.c, select.c * * get/set thread context still needs to be done for Mingw and Cygwin * * main.c needs a lot of work */ /* object.h and async.h */ struct timeval{ int tv_sec; int tv_usec; }; /* debugger.c */ #define SIGTRAP NULL /* file.c - doesnt work */ #define O_NONBLOCK 0 #define POLLIN 0 #define POLLOUT 0 #define POLLIN 0 #define POLLOUT 0 /* main.c */ #define SIGPIPE NULL #define SIGHUP NULL #define SIGQUIT NULL /* named_pipe.c */ #define PF_UNIX NULL #define SOCK_STREAM NULL /* object.c */ #define POLLERR 0 #define POLLHUP 0 __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Jan. 31, 2003

Winelib and <io.h>

by Hans Christian Studt

Using (pached) winemaker I still have problems with <io.h> sed -e 's,@bindir\@,/usr/local/bin,g' -e 's,@winelibdir\@,.,g' ./wineapploader.in >wineapploader || rm -f wineapploader make[1]: Entering directory `/user/home/hcs/Wine/winelib/compile/bb4win/blackbox' LD_LIBRARY_PATH=":$LD_LIBRARY_PATH" /usr/local/bin/wrc -J -m -I. -I/usr/local/include/wine/windows -o Blackbox.res Blackbox.rc /usr/local/bin/wineg++ -c -I. -I/usr/local/include/wine/windows -g -O2 -fpermissive -fno-for-scope -D_REENTRANT -o BBApi.o BBApi.cpp In file included from BBApi.cpp:34: Menu/MenuMaker.h:53:16: io.h: Ingen sådan fil eller filkatalog There was a discussion on a subject related to io.h started on this list 9. january 2003. What exactly were the outcome ??? Is there a resolution or a workaround ??? I can still try out Ming/Cygwin but how would that change the <io.h> problem ??? -- Hans Christian Studt : http://hc.studt.dk mailto:hc(a)studt.dk .dk og W3C standarder : http://w3c.studt.dk

Jan. 31, 2003

Re: RPC marshalling patch

by Sylvain Petreolle

notice that the most common anonftp passwords are mozillauser@, IE4USER@ and joe(a). what a useful log :) > In any case they wanted a log of who was downloading stuff, but they > said at the time that the email addresses wouldn't be used for other > purposes. I've certainly never received junk mail from them. > > I suspect the log (like the ones from anon ftp passwords) is of > little use to anyone. ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 31, 2003

Re: Winelib project

by Hans Christian Studt

Dimitrie O. Paun wrote: > On Fri, 31 Jan 2003, Hans Christian Studt wrote: > >>The question is should we support source-three >>or >>should we get rid of >>:$WINE_ROOT/tools/wrc:$WINE_ROOT/tools/winebuild >>from WINE_TOOL_PATH > > Getting winegcc and winewrap work off of the source > tree is not supported at the moment, as I said in an > earlier email. It will take a lot more than pointing > an environment variable, and it will not happen any > time soon. Only after it stabilizes a bit should we > consider modifying it to work from the tree. > > So for now, if you want to play with Winelib, you > have to make install it, and use it like it's meant > to be used. Fine -- Hans Christian Studt : http://hc.studt.dk mailto:hc(a)studt.dk .dk og W3C standarder : http://w3c.studt.dk

Jan. 31, 2003

Re: Winelib project

by Hans Christian Studt

Hans Christian Studt wrote: > Hans Christian Studt wrote: > >> Dimitrie O. Paun wrote: >> >>> Yes, it's just a symbolic link: >> >> Be sure someone fix that in the CVS. > > No fix needed - It is correct in /usr/local/bin - sorry I the current winemaker perl script the variable is used WINE_TOOL_PATH="$WINE_ROOT:$WINE_ROOT/bin:$WINE_ROOT/tools/wrc:$WINE_ROOT/tools/winebuild" which support running of the source-three where tools/wrc exists as well as off the /usr/local/bin-three as long as gcc is used. Now when we want to use the winegcc and wineg++ the source-three will not work. In order to make it work we need to add $WINE_ROOT/tools to WINE_TOOL_PATH and to create a symbolic link between winegcc and wineg++ in the source-three. The question is should we support source-three or should we get rid of :$WINE_ROOT/tools/wrc:$WINE_ROOT/tools/winebuild from WINE_TOOL_PATH -- Hans Christian Studt : http://hc.studt.dk mailto:hc(a)studt.dk .dk og W3C standarder : http://w3c.studt.dk

Jan. 31, 2003

Re: [RFC] The Wine UI page

by Eric Pouech

> Whether such a matrix is usable (may be too big) is not clear to me. > But it's an interesting idea. However, the hard part is the content, > and that's difficult to get. Once I finish this page, maybe we can > create a unifing matrix, see how it looks. my idea was not necessary to use the matrix for display, but more for info gathering. afterwards, it would be easier to extract by rows and or columns. in any case, filling in the cells is the hardest task and the UI row is still empty... so, keep on filling it ;-) (or is it a column ? ;-) >>another piece, I forgot about some other control(s) (and here it's more >>than a simple control): >>- MCIWndClass in msvideo/msvfw32 the real official name seems to be MciWnd according to MS docs > Can you please help me complete the entry: > -- URL to MS docs http://msdn.microsoft.com/library/default.asp?url=/library/en-us/multimed/m… > -- status (% completion, what it's missing) I'd say 20 to 30% completion. Very limited core implementation. All bells & whistles are missing including extended styles, notification, MCIWNDM_ messages > -- maybe to an audit against the latest MS docs, see _exactly_ > what we're missing. A+ -- Eric Pouech

Jan. 31, 2003

Explorer

by Steven Edwards

I've been reading all of the traffic regarding getting explorer to work under WINE or writing a replacement for WINE and thought this would be a good time to chime in. ReactOS is about to release version 0.1.0 this weekend and is starting to include support for basic Windowing and CDrom installing. There has been much discussion on when/if we will reimplement explorer.exe also so maybe we can work together on this as ReactOS is using WINE for large parts of the shell support. If the WINE project is going to start a implementation of explorer.exe then we will work off of that. Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Jan. 31, 2003

Re: Why is IOCTL_CDROM_READ_TOC so slow?

by Eric Pouech

Waldeck Schutzer wrote: > Here is something interesting. When I turn the drive back into a plain > ide (by removing the ide-scsi option from the kernel options), it speeds > up considerably. Now it rocks! This makes me wonder what the heck is > going on with the kernel. dunno maybe either some non caching being used in scsi, or request queueing with timers... should find some time reading the kernel source though A+ -- Eric Pouech

Jan. 31, 2003

Re: Winelib project

by Hans Christian Studt

Hans Christian Studt wrote: > Dimitrie O. Paun wrote: >> Yes, it's just a symbolic link: > Be sure someone fix that in the CVS. No fix needed - It is correct in /usr/local/bin - sorry -- Hans Christian Studt : http://hc.studt.dk mailto:hc(a)studt.dk .dk og W3C standarder : http://w3c.studt.dk

Jan. 31, 2003

Re: Winelib project

by Hans Christian Studt

Dimitrie O. Paun wrote: > On Fri, 31 Jan 2003, Hans Christian Studt wrote: > >>I just build from the CVS and I now have >>/usr/local/wine/tools/winegcc >>but I canot find >>wineg++ >> >>Should there be a symbolic link to winegcc or what ??? > > Yes, it's just a symbolic link: > > [dimi(a)dimi dimi]$ ls -l /usr/local/bin/wine* > -rwxr-xr-x 1 root root 242956 Jan 15 21:09 /usr/local/bin/wine > -rwxr-xr-x 13 root root 1594 Jan 15 21:09 /usr/local/bin/wineboot > -rwxr-xr-x 1 root root 396533 Jan 30 13:08 /usr/local/bin/winebuild > -rwxr-xr-x 1 root root 66714 Jan 15 21:09 /usr/local/bin/wineclipsrv > -rwxr-xr-x 13 root root 1594 Jan 15 21:09 /usr/local/bin/wineconsole > -rwxr-xr-x 13 root root 1594 Jan 15 21:09 /usr/local/bin/winedbg > -rwxr-xr-x 1 root root 287808 Jan 30 13:08 /usr/local/bin/winedump > -rwxr-xr-x 13 root root 1594 Jan 15 21:09 /usr/local/bin/winefile > lrwxrwxrwx 1 root root 7 Jan 30 13:08 /usr/local/bin/wineg++ -> winegcc > -rwxr-xr-x 1 root root 51173 Jan 30 13:08 /usr/local/bin/winegcc > -rwxr-xr-x 1 root root 19864 Jan 15 21:09 /usr/local/bin/winelauncher > -rwxr-xr-x 1 root root 97085 Jan 30 13:08 /usr/local/bin/winemaker > -rwxr-xr-x 13 root root 1594 Jan 15 21:09 /usr/local/bin/winemine > -rwxr-xr-x 13 root root 1594 Jan 15 21:09 /usr/local/bin/winepath > -rwxr-xr-x 1 root root 1372162 Jan 15 21:09 /usr/local/bin/wineserver > -rwxr-xr-x 1 root root 5726 Jan 15 21:09 /usr/local/bin/wineshelllink > -rwxr-xr-x 1 root root 62872 Jan 30 13:08 /usr/local/bin/winewrap > [dimi(a)dimi dimi]$ Thanks Be sure someone fix that in the CVS. -- Hans Christian Studt : http://hc.studt.dk mailto:hc(a)studt.dk .dk og W3C standarder : http://w3c.studt.dk

Jan. 31, 2003

Re: Winelib project

by Jeff Smith

Yes. BTW, when 'make install'ed, wine should create the appropriate link in the same directory it installs winegcc. -- Jeff S >From: Hans Christian Studt <hcstudt(a)post10.tele.dk> > >I just build from the CVS and I now have >/usr/local/wine/tools/winegcc >but I canot find >wineg++ > >Should there be a symbolic link to winegcc or what ??? >-- >Hans Christian Studt : http://hc.studt.dk mailto:hc(a)studt.dk >.dk og W3C standarder : http://w3c.studt.dk _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail

Jan. 31, 2003

Re: PATCH - wineserver named_pipe.c porting fix

by Dimitrie O. Paun

On Fri, 31 Jan 2003, Steven Edwards wrote: > Working on building wineserver on mingw > > Changelog: check for sys/socket.h Dude, Just bundle all these patches together, under such a ChangeLog: Check for missing headers in mingw. I think it's simpler for everybody: you (to submit), us (to review), Alexandre (to apply), and it's in fact a logical change that shouldn't be split. -- Dimi.

Jan. 31, 2003

Re: Winelib and <io.h>

by Dimitrie O. Paun

On Fri, 31 Jan 2003, Hans Christian Studt wrote: > I can still try out Ming/Cygwin but how would that change the > <io.h> problem ??? It will not, but it will make it much more easy for us to fix. Basically, if it works under MinGW, it should work under Wine. Thing is, you don't want to have to fix _all_ the porting problems at once. MinGW provides an _ideal_ midstep in the process, and it comes almost for free, because it doesn't imply a detour to take it. Essentially you have to pass through the point where the app builds under MinGW, you might as well try and see that it does. This removes a _lot_ of the uncertainties in later stages, making them so much easier to debug and fix. That being said, try to compile using the MSVCRT headers. To do that, just pass -mno-cygwin to winegcc, see if that works. -- Dimi.

Jan. 31, 2003

Re: Winelib project

by Hans Christian Studt

Dimitrie O. Paun wrote: > On Wed, 29 Jan 2003, Hans Christian Studt wrote: >>Hi, >> >>I am trying to compile some sourceforge windows projects under >>winelib and need some guidance regarding how to fix these errors. >> >>bb4win >>=========================================== >>g++ -c -I. -I/usr/local/wine/include -g -O2 -fpermissive >>-fno-for-scope -D_REENTRANT -o BB >>Api.o BBApi.cpp > > Please use wineg++ instead of g++, and winegcc instead of gcc. > Do the apps you are trying to compile build under MinGW? If so, > all you have to do to the makefiles (in theory) is this: > > -CC=gcc > -CXX=g++ > -RC=windres > +CC=winegcc > +CXX=wineg++ > +RC=wrc > > If it does not work like this, please report back on the list. > > On the other hand if they don't build under MinGW currently, > your best bet is to get them to build & run under MinGW first, > and try to port them to winelib after that. > >>I you are busy I will try to look at it :-) > > If you are, let me know, I'll give you a braindump of > what I think needs to happen. I just build from the CVS and I now have /usr/local/wine/tools/winegcc but I canot find wineg++ Should there be a symbolic link to winegcc or what ??? -- Hans Christian Studt : http://hc.studt.dk mailto:hc(a)studt.dk .dk og W3C standarder : http://w3c.studt.dk

Jan. 31, 2003

Re: RPC marshalling patch

by David Laight

> > > and here is some free-as-in-beer RPC 1.1 stuff: > > > > http://www.opengroup.org/products/publications/catalog/c706.htm > > And on there, they just want to borg the email addresses of every reader, > but not their souls or firstborns, as far as I can see. When they set up this 'free' access to the documents it was rather a change of direction for (what was then) X/Open. After all they had a business model that assumed they would be making money from selling the books, rather than just taking money from the contributing companies and giving away a 'free' copy of each book to each company. In any case they wanted a log of who was downloading stuff, but they said at the time that the email addresses wouldn't be used for other purposes. I've certainly never received junk mail from them. I suspect the log (like the ones from anon ftp passwords) is of little use to anyone. David -- David Laight: david(a)l8s.co.uk

Jan. 31, 2003

Re: Winelib project

by Dimitrie O. Paun

On Fri, 31 Jan 2003, Hans Christian Studt wrote: > The question is should we support source-three > or > should we get rid of > :$WINE_ROOT/tools/wrc:$WINE_ROOT/tools/winebuild > from WINE_TOOL_PATH Getting winegcc and winewrap work off of the source tree is not supported at the moment, as I said in an earlier email. It will take a lot more than pointing an environment variable, and it will not happen any time soon. Only after it stabilizes a bit should we consider modifying it to work from the tree. So for now, if you want to play with Winelib, you have to make install it, and use it like it's meant to be used. -- Dimi.

Jan. 31, 2003

Re: Guess who's back, back again... :)

by Shachar Shemesh

Dimitrie O. Paun wrote: >I wish I got paid :) No, I don't. In fact, I haven't made a dime >working on Wine. It would be nice to, so I can put more time in it, >but that's another story. I am a freelancer, and I had a bit more >time on my hands last year, but starting Jan 2003, things changed, >and I will not have as much time available (in fact, if I get 2h/day >to work on Wine I'll be happy). > If your'e now a freelancer with less free time, does that not mean you are now a freelancer making more money? That is, generally speaking, a good thing. > In other words, things will progress >a lot slower from now on. :( > > As someone who has just made the jump myself (quite my daytime job and became a freelancer, effective this Thursday), seeing someone else who has been a freelancer and has succeeded in both working on wine for a year AND finding a fuller time job is a very encouraging. Good luck, either way. Shachar

Jan. 31, 2003

Re: RPC marshalling patch

by Gregory M. Turner

On Friday 31 January 2003 02:22 am, Ove Kaaven wrote: > > http://www.opengroup.org/products/publications/catalog/t151x.htm > > I can't find any legalese there to the effect of signing away my > firstborn, they seem to just want purchase details. Care to elaborate? > (And is it still okay for me to code on Wine even if my firstborn can't?) > > > and here is some free-as-in-beer RPC 1.1 stuff: > > > > http://www.opengroup.org/products/publications/catalog/c706.htm > > And on there, they just want to borg the email addresses of every reader, > but not their souls or firstborns, as far as I can see. hehe, you are correct, they are more like, say, the Borland Community site than Rumplestiltskin. Of course, I was kidding about signing away your firstborn, although you do at least sign away any redistribution rights by downloading the free stuff. AFAIK OpenGroup/DCE controls the RPC spec -- expecting consumers to sign an NDA or something would kind of defeat their stated purpose of enhancing interoperability. There is one really significant open question left by their documentation: what is the gap between "MSRPC" and DCE RPC? I still can't decide whether this difference is just an API-level difference, or a full-blown wire-protocol incompatibility.... Luckily, we probably don't care too much -- ultimately, if we can make something that interoperates with Windows, we win, regardless of how well MS complied with the spec. The other thing I can't stand about their spec is the rediculous protocol state diagram style they use. Could they have /possibly/ made it more confusing and obscure? (Surely, the answer is yes, but it's pretty darn confusing). But, it helps. I shouldn't complain, considering what I paid for it. Combined with the pseudo-documentation of the format strings from MSDN, the Microsoft headers and MIDL output, the DCERPC source, tcpdump, etc., there's enough comprehensible clues out there to actually accomplish something -- it still feels pretty sparse to me, but I guess there's nothing I can do about that but forge ahead (or maybe shell out for the DCE package :) ) --gmt

Jan. 31, 2003

Re: Winelib project

by Dimitrie O. Paun

On Fri, 31 Jan 2003, Hans Christian Studt wrote: > Be sure someone fix that in the CVS. There's nothing to fix in CVS. make install creates that link. Did you run make install? -- Dimi.

Jan. 31, 2003

Re: Winelib project

by Dimitrie O. Paun

On Fri, 31 Jan 2003, Hans Christian Studt wrote: > I just build from the CVS and I now have > /usr/local/wine/tools/winegcc > but I canot find > wineg++ > > Should there be a symbolic link to winegcc or what ??? Yes, it's just a symbolic link: [dimi(a)dimi dimi]$ ls -l /usr/local/bin/wine* -rwxr-xr-x 1 root root 242956 Jan 15 21:09 /usr/local/bin/wine -rwxr-xr-x 13 root root 1594 Jan 15 21:09 /usr/local/bin/wineboot -rwxr-xr-x 1 root root 396533 Jan 30 13:08 /usr/local/bin/winebuild -rwxr-xr-x 1 root root 66714 Jan 15 21:09 /usr/local/bin/wineclipsrv -rwxr-xr-x 13 root root 1594 Jan 15 21:09 /usr/local/bin/wineconsole -rwxr-xr-x 13 root root 1594 Jan 15 21:09 /usr/local/bin/winedbg -rwxr-xr-x 1 root root 287808 Jan 30 13:08 /usr/local/bin/winedump -rwxr-xr-x 13 root root 1594 Jan 15 21:09 /usr/local/bin/winefile lrwxrwxrwx 1 root root 7 Jan 30 13:08 /usr/local/bin/wineg++ -> winegcc -rwxr-xr-x 1 root root 51173 Jan 30 13:08 /usr/local/bin/winegcc -rwxr-xr-x 1 root root 19864 Jan 15 21:09 /usr/local/bin/winelauncher -rwxr-xr-x 1 root root 97085 Jan 30 13:08 /usr/local/bin/winemaker -rwxr-xr-x 13 root root 1594 Jan 15 21:09 /usr/local/bin/winemine -rwxr-xr-x 13 root root 1594 Jan 15 21:09 /usr/local/bin/winepath -rwxr-xr-x 1 root root 1372162 Jan 15 21:09 /usr/local/bin/wineserver -rwxr-xr-x 1 root root 5726 Jan 15 21:09 /usr/local/bin/wineshelllink -rwxr-xr-x 1 root root 62872 Jan 30 13:08 /usr/local/bin/winewrap [dimi(a)dimi dimi]$ -- Dimi.

Jan. 31, 2003