September 2003 - Wine-devel

Re: FAQ: Update the ports section
by Ivan Leo Murray-Smith 14 Sep '03

14 Sep '03

>On Thu, 11 Sep 2003, Ivan Leo Murray-Smith wrote: > >> The original sentence that started this is >> >The following list are the x86 operating systems supported by >[...] >> "The list is current as of XX/XX/XXXX" is a solution that should make everybody >> happy. > >Not really because as the above clearly illustrates, this is not what >the original sentence said or meant to say. I really don't know why >everyone focused on this 'up-to-date' thing. > >*Sigh* This is just getting so boring, just use "The following lists the x86 operating systems supported by" and that can be the end of that (Hoping nobody starts discussing again about there great knowledge of slang and ignorance of english...)

2 1

Kernel pipe test segfaults?
by Rolf Kalbermatter 13 Sep '03

13 Sep '03

Mike Hearn <mike(a)theoretic.com> wrote: >Maybe this is a known issue, I haven't really followed the test case >work up until now, but does the kernel32 pipe test segfault for anybody >else? I have problems, too. It used to crash somewhere in kernel32 with processes and now with pipes, where the test hangs for several minutes and then is aborted with returning an error 139. This is with Suse 8.2 and an Athlon optimized 2.4.20 Standard Suse kernel. Rolf Kalbermatter CIT Engineering Nederland BV tel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijk http://www.citengineering.com Netherlands mailto:rolf.kalbermatter(a)citeng.com

1 0

Really slow named pipes
by Duane Clark 13 Sep '03

13 Sep '03

This is a bit old, from May, but anyhow... The patch to implement anonymous pipes on top of named pipes: http://www.winehq.com/hypermail/wine-cvs/2003/05/0305.html along with a corresponding bug fix: http://www.winehq.com/hypermail/wine-cvs/2003/06/0123.html causes Xilinx ISE to run really, really slow. It has a window to which messages are sent via a pipe, and what I see now is that one line comes out every 2/3 of a second or so, as regular as a clock at least by eye. I can revert those two patches, and it goes back to spitting out the messages very fast. Since there are a lot of messages being sent, the current version slows the app down to a crawl. It does not look like the patch itself is the problem; I am guessing that it is the underlying named pipe implementation that is the problem, which was exposed by the patch. Also, reverting to the full CVS 5/20, just after the pipe patches, has the same problem. So it appears that whatever is wrong with named pipes (if that really is the problem) was already there on 5/20, rather than it being something introduced since then. Any hints on what I could look for would be welcome.

4 10

Re: kernel32.GetProcessIoCounters basic implementation
by Eric Pouech 13 Sep '03

13 Sep '03

Eric Pouech wrote: > TSIA > A+ oops, wrong file... use this one instead :-( A+ -- Eric Pouech Name: iocnt ChangeLog: Implemented GetIoProcessCounters License: X11 GenDate: 2003/09/13 12:50:39 UTC ModifiedFiles: dlls/kernel/kernel32.spec dlls/kernel/process.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/kernel/kernel32.spec,v retrieving revision 1.106 diff -u -u -r1.106 kernel32.spec --- dlls/kernel/kernel32.spec 11 Sep 2003 03:00:11 -0000 1.106 +++ dlls/kernel/kernel32.spec 13 Sep 2003 07:18:18 -0000 @@ -452,7 +452,7 @@ @ stdcall GetProcessFlags(long) @ stdcall GetProcessHeap() @ stdcall GetProcessHeaps(long ptr) -@ stub GetProcessIoCounters +@ stdcall GetProcessIoCounters(long ptr) @ stdcall GetProcessShutdownParameters(ptr ptr) @ stdcall GetProcessTimes(long ptr ptr ptr ptr) @ stdcall GetProcessVersion(long) Index: dlls/kernel/process.c =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/dlls/kernel/process.c,v retrieving revision 1.4 diff -u -u -r1.4 process.c --- dlls/kernel/process.c 5 Sep 2003 23:08:37 -0000 1.4 +++ dlls/kernel/process.c 13 Sep 2003 07:17:56 -0000 @@ -424,6 +424,16 @@ return !status; } +/****************************************************************** + * GetProcessIoCounters (KERNEL32.@) + * + * + */ +BOOL WINAPI GetProcessIoCounters(HANDLE hProcess, PIO_COUNTERS ioc) +{ + memset(ioc, 0, sizeof(ioc)); + return TRUE; +} /*********************************************************************** * RegisterServiceProcess (KERNEL.491)

1 0

Here is one - Linux on Cygwin on Linux
by Steven Edwards 13 Sep '03

13 Sep '03

Here is a good one for someone to test. The User Mode Linux people have done it. They are working on a port of User Mode Linux to Win32. This has been something I have been wanting to see for a while so we can use Linux as our Posix subystem in ReactOS by moving parts of UMLwin32 in to back to kernel mode. Right now you still need cygwin but if someone wants to try running it under Cygwin on WINE here is the url: http://umlwin32.sourceforge.net Thanks Steven __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

3 2

Re: Word-splitting in the FAQ
by Dan Kegel 13 Sep '03

13 Sep '03

On the general subject of spellchecking, there are a few typo lists and spellcheckers at http://www.kegel.com/kerspell/ which specialize in typos in C program comments... might be of some interest. One of them was contributed by Francois and has already been run on the Wine tree, I think... -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

2 1

Re: FAQ: Update the ports section
by Ivan Leo Murray-Smith 13 Sep '03

13 Sep '03

The original sentence that started this is >The following list are the x86 operating systems supported by from twickline_at_skybest.com http://www.winehq.org/hypermail/wine-devel/2003/09/0356.html He claims he knows 3 types of slang, and is from west virginia, but he never claimed to be "A native english speaker", so you don't have (Such a big) reason to be bothered. I was the first to claim a native english speaker (As far as I know) and I have tried explaining to Tom that there is a thing called grammar, but he had a few problems understanding that. "The list is current as of XX/XX/XXXX" is a solution that should make everybody happy.

2 1

ikernel.exe error still not fix in 11_9_03.tar.gz
by lineric＠qwest.net 12 Sep '03

12 Sep '03

1 0

Re: [ros-kernel] an interesting idea
by Steven Edwards 12 Sep '03

12 Sep '03

This is what I have been thinking. We can move parts of UML back to a subsytem mode and them implement a Xsever in to Win32k.sys/GDI32. You wouldnt even need to recompile X applications provided we implement X properly. All that would be needed is a modded Xserver and X libs. The client libs should still work using X protocal and Xtenstions. This type of hybrid system could then run any application Windows or Linux and would not suffer from the same problems WINE does because it would be a real Linux Kerenl and GLIBC running. Thanks Steven --- Jonathan Wilson <jonwil(a)tpgi.com.au> wrote: > Something we could do (once we get UML going without cygwin and down into > the kernel) is to build a Linux subsystem (mabie even with ports of > GTK/QT/X/etc on top of GDI) that could run linux apps just as easily as it > can run windows apps. > > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com

2 1

Re: [winecfg 8] Complete drive edit dialog, warn on lack of C drive, implement drive delete, code cleanups
by Dimitrie O. Paun 12 Sep '03

12 Sep '03

On 11 Sep 2003, Mike Hearn wrote: > ChangeLog: > - All settings in the drive edit dialog are now instant apply This is a cool feature, but we should keep it optional. Our primary audience are Windows users, and they are not used to that. Heck, even I am not used to it, I am used to be able to play around with stuff in dialogs, and than press CANCEL. In fact, KDE is not instant apply, so I would argue that even most Linux users are used to that. I'd argue that we need to support instant apply to integrate with GNOME, but to default to the classic OK/CANCEL for now, until we can figure how and when to enable one or the other behaviour. -- Dimi.

5 8