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

Re: CVS Update: reactos

by Steven Edwards

Hello All, Just wanted to let everyone know that we've hit our first major milestone with ReactOS. I dont have the changelog in front of me but to some it up here it the list that I know off the top of my head. Self-hosted builds now works CD-booting/Installing Simple Windowing (User32 Code adapted from WINE) More MS_VC applicaton/driver support Started implementing support for WINE dlls Better Networking support (TCP still broken) Once WINE hits 1.x we will again take a snapshot of your tree so we have standard debugging interfaces. Right now in or tree we dont use libwine but have our own dll that implements the debug channels. We also still need to adapt alot of the controls from WINE for our user32. Thanks for all the help Steven --- Jason Filby <jfilby(a)mok.lvcm.com> wrote: > CVSROOT: /CVS/ReactOS > Module name: reactos > Repository: reactos/include/reactos/ > Changes by: jfilby(a)mok.lvcm.com 03/02/01 07:34:35 > > Modified files: > reactos/include/reactos/: version.h > > Log message: > ReactOS 0.1.0 > __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Feb. 1, 2003

Re: Started playing with Wineserver on mingw/cygwin again

by Steven Edwards

> 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 I'm not sure if it is cheating or not. I tried to write a little wrapper that just forwards our implementation to the Windows kernel32 GetThreadContext a while back but in the current Wine Windows.h you can't include it internaly so I never did much more with it. Everyone already knows I dont write good code so I have never tried to do more with it untill now. Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Feb. 1, 2003

Re: half-life

by Mike Hearn

Those lines aren't errors, they're logging each API call. If you know a bit about programming, you can probably examine the end of the trace and see what happened just before it went wrong. That's when you start debugging :) On Sat, 2003-02-01 at 17:42, Scott Jackson wrote: > ok, did the relay trace, but I came up with about 700,000 lines of error... > I could give you the bottom or attach it (but it's 48 MEGS)... > is there any way I can relay trace to where it won't send me 700,000 lines?? > thanks > > On Fri, 31 Jan 2003 21:45:23 -0700 > Tony Lambregts <tony_lambregts(a)telusplanet.net> wrote: > > > Thats some pretty old documentation your looking at. No the following > > should work > > > > wine -debugmsg +relay "C:\where ever\the\program\is" > > > > -- > > > > Tony Lambregts > > > > > > >

Feb. 1, 2003

Re: remove <wineconf> from sample config

by Tony Lambregts

Ove Kaaven wrote: > > 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. > > > OK. But as place holders they can be anything so how about this. Change Log: Modify the wineconf tags so that the sample config can be included in the documentation. Files Changed: documentation/config tools/wineconf -- Tony Lambregts Index: documentation/samples/config =================================================================== RCS file: /home/wine/wine/documentation/samples/config,v retrieving revision 1.38 diff -u -u -r1.38 config --- documentation/samples/config 21 Jan 2003 00:28:48 -0000 1.38 +++ documentation/samples/config 1 Feb 2003 05:11:45 -0000 @@ -67,7 +67,7 @@ ;"ShowDotFiles" = "1" "ShellLinker" = "wineshelllink" -# <wineconf> +# [wineconf] [Version] ; Windows version to imitate (win95,win98,winme,nt351,nt40,win2k,winxp,win20,win30,win31) @@ -313,4 +313,5 @@ ;[AppDefaults\\pickygame.exe\\dsound] ;"EmulDriver" = "N" -# </wineconf> +# [/wineconf] + Index: tools/wineconf =================================================================== RCS file: /home/wine/wine/tools/wineconf,v retrieving revision 1.14 diff -u -r1.14 wineconf --- tools/wineconf 1 Jun 2002 02:55:52 -0000 1.14 +++ tools/wineconf 1 Feb 2003 17:42:21 -0000 @@ -437,9 +437,9 @@ if (open(DEFFILE, "$fileName")) { while (<DEFFILE>) { - $state = 0 if ($state == 1 && $_ =~ /^[ \t]*\#/o && index($_, "</$tag>") >= 0); + $state = 0 if ($state == 1 && $_ =~ /^[ \t]*\#/o && index($_, "[/$tag]") >= 0); print $_ if ($state == 1); - $state = 1 if ($state == 0 && $_ =~ /^[ \t]*\#/o && index($_, "<$tag>" ) >= 0); + $state = 1 if ($state == 0 && $_ =~ /^[ \t]*\#/o && index($_, "[$tag]" ) >= 0); } close(DEFFILE); } else {

Feb. 1, 2003

Re: half-life

by Scott Jackson

ok, did the relay trace, but I came up with about 700,000 lines of error... I could give you the bottom or attach it (but it's 48 MEGS)... is there any way I can relay trace to where it won't send me 700,000 lines?? thanks On Fri, 31 Jan 2003 21:45:23 -0700 Tony Lambregts <tony_lambregts(a)telusplanet.net> wrote: > Thats some pretty old documentation your looking at. No the following > should work > > wine -debugmsg +relay "C:\where ever\the\program\is" > > -- > > Tony Lambregts > > > -- "De-fault! The two sweetest words in the English language." -- Homer Simpson Get Gaim for unix or win32 systems! gaim.sourceforge.net Scott "Action" Jackson - scott_j(a)ajackson.org

Feb. 1, 2003

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

by David Laight

> What happens under Windows with such circumstances? Who knows, I've never used windows (well almost never), people don't seem to mind windows locking solid :-) David -- David Laight: david(a)l8s.co.uk

Feb. 1, 2003

Re: ReactOS cmd exe (was Re: Explorer)

by Eric Pouech

> 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? there's is no violation, but it's easier to ship Wine as being license-uniform, than having different license depending on the directory >> 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? wcmd (and ReactOS cmd) are Win32 CUI programs, not DOS (aka 16 bit MZ) programs A+ -- Eric Pouech

Feb. 1, 2003

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

by Dan Kegel

Dan Kegel wrote: > 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? D'oh. It's Btrieve's file table. That's Btrieve error #86. (Notice the reference to the BTRVERR filename in the log; that's where the "File table full" message comes from.) Looking around on the web for that message, the corrective action is supposedly "The Btrieve file table is full. Use the Setup utility to specify a higher value in the Open Files option." Um, setup utility? Ok... hmm... got it! The BTRIEVE6 subdirectory of the product has an app called W32MKSET.EXE that indeed lets you set the file table size! It has some UI glitches under Wine, but it works just well enough to let you set that parameter. Now Yardi has some other problem, but hey, I learned something! - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Feb. 1, 2003

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

by David Laight

> 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. No, it causes horrid corruptions that are particularly difficult to find. What happens is that someone else does an open() and is given the number of the (incorrectly) closed fd. The owener of the fd will then write into the newly opened file. This can happen if a 'normal' program does close(0), close(1), close(2) then much later accidentally calls printf() instead of sprintf(). When the stdio buffer is eventually flushed data is written to what has been reopened as fd0. (This was a real bug in software that got released...) David -- David Laight: david(a)l8s.co.uk

Feb. 1, 2003

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

by Shachar Shemesh

David Laight wrote: >>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. >> >> > >No, it causes horrid corruptions that are particularly difficult >to find. > >What happens is that someone else does an open() and is given >the number of the (incorrectly) closed fd. The owener of the fd >will then write into the newly opened file. > >This can happen if a 'normal' program does close(0), close(1), >close(2) then much later accidentally calls printf() instead >of sprintf(). When the stdio buffer is eventually flushed data >is written to what has been reopened as fd0. >(This was a real bug in software that got released...) > > David > > > What happens under Windows with such circumstances? Sh.

Feb. 1, 2003