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

Re: remove <wineconf> from sample config

by Ove Kaaven

On Fri, 31 Jan 2003, Tony Lambregts wrote: > In order to be able to simply include the sample config file in the > documnetation something has to be done about the lines # <wineconf> and > # </wineconf>. These are just comments and IFAICT can be safely removed. Not exactly, they're markers used by tools/wineconf to mark the parts that should be copied into the generated config file, in addition to the autogenerated drive config.

Feb. 1, 2003

Re: ReactOS cmd exe (was Re: Explorer)

by Shachar Shemesh

Tony Lambregts wrote: > Steven Edwards wrote: > >> Our cmd.exe is based off of freedos command.com which is GPL. >> > Dang! Can someone please explain to me why our winelib apps MUST be LGPL? What is the reason wcmd cannot be GPL? Where is the violation? > Well, we can at least ask. Do you know who to contact? > Wouldn't that mean that wcmd be a Dos program? Isn't that inferior to a "Win32" program that wcmd currently is? Shachar

Feb. 1, 2003

"Error: File table full" in VB app

by Dan Kegel

The next buglet in the property management VB app from http://www.yardi.com is right after I pick the datafile to open, it pops up with a dialog box titled "Database Exception", contents "Error: File table full. Op: Open. File: BANK.DAT [86:0:21]" Now, what file table might that be? I tried editing c:\config.sys, and adding FILES=128, but that didn't help :-) I'm attaching the output of ~/wine/wine --debugmsg +file,+dialog,+int21 --dll compobj,storage,ole2,ole32=n Y.EXE > y.log 2>&1 tar -cjvf y.tar.bz2 y.log Suggestions welcome. I'm more than happy to raise that file table size, if only I knew which one it was... - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Feb. 1, 2003

Re: "Error: File table full" in VB app

by Sylvain Petreolle

--- Dan Kegel <dank(a)kegel.com> a écrit : > The next buglet in the property management VB app from > http://www.yardi.com > is right after I pick the datafile to open, it pops up > with a dialog box titled "Database Exception", > contents "Error: File table full. Op: Open. File: BANK.DAT > [86:0:21]" [syl(a)snoop syl]$ grep -i BANK y.log [syl(a)snoop syl]$ this is the main thing I notice. ===== 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

Feb. 1, 2003

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

by Shachar Shemesh

Alexandre Julliard wrote: >... 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. > > I'm not sure I agree. When someone closes a fd they shouldn't, that would lead to program crashing, and attention being brought to the problem. When someone leaks a fd, noone will notice. Shachar

Feb. 1, 2003

Re: [DDRAW] Fix bug 1246

by Lionel Ulmer

> Changelog : > Add support for 24 bpp to _Blt_ColorFill. > Fix endianness issue in DIB_DirectDrawSurface_Blt. While I agree with the patch, the easiest way would still be to completely remove support for the evil 24 / 24 screen configuration everywhere in Wine and only support 24 / 32. For example, in GetSysMetrics we report bpp as 24 (even in 24 / 32 mode) whereas Windows would return 32 and that breaks some apps (do not remember which though). And as I do not know of any modern graphic card supporting this (maybe Matrox because I did not test it), it should not hurt anyone. The other way would be : if ANYONE here uses (or can use) his card in 24 / 24 mode, please contact me so that I can do experiments on your X display to detect 24 / 24 from 24 / 32 :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Feb. 1, 2003

Avoiding tempnam (in favor of mkstemp)

by Gerald Pfeifer

We have had some (security-relevant) warning regressions for the following two programs in tools: winegcc.o: In function `get_temp_file': /test/wine/tools/winegcc.c:119: warning: tempnam() possibly used unsafely; consider using mkstemp() winewrap.o: In function `main': /test/wine/tools/winewrap.c(.text+0x7fe): warning: tempnam() possibly used unsafely; consider using mkstemp() Would you mind using mkstemp() instead of tempnam()? Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

Feb. 1, 2003

Re: Explorer

by Dan Kegel

Dimitrie O. Paun wrote: > 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. I agree. The placeholder I wrote still has some value, and I'd like to see it in the tree so programs that expect to be able to launch an explorer do launch the closest thing we have to one, but it should be junked as soon as we have a real explorer. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Feb. 1, 2003

Re: Started playing with Wineserver on mingw/cygwin again

by David Fraser

Steven Edwards wrote: >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) > OK, as far as I understand it this means we need to implement a cygwin version of get_thread_context and set_thread_context in server/context_i386.c. What I'm not sure about is, when running wineserver on cygwin, would the threads created in Wine have a one-to-one correspondence to Windows threads? Or would they be strange, different, unix-style threads which cygwin then maps down to Windows threads? Could we go straight down to the underlying win32 api and do a GetThreadContext there? Is that cheating? David

Feb. 1, 2003

Re: RPC marshalling patch

by Tom Wickline

Dimitrie O. Paun wrote: > On Fri, 31 Jan 2003, Gregory M. Turner wrote: > > >>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 :) ) > > > The DCE package is like $400USD. Not that bad. Maybe we can put some money > togther (what about the Party Fund, that would be a good use of that money), > and buy the DCE docs for the Wine project. > > I contribute $40USD, if other contribute to make the 400. > I will contribute $50.00 I was going to put $50.00 into the fund anyway. And this seems to be a good time to do it . Tom

Feb. 1, 2003