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

Re: What have I done to my debugger?

by Bill Medland

"eric pouech" <eric.pouech(a)wanadoo.fr> wrote in message news:3C30A8E4.5ABE4F3D(a)wanadoo.fr... > > > When I right click on the window I get offered a menu including a > > "defaults". When I select that I get a dialog with three groups of > > controls; a cursor size, a history and a "conf" something. I see no > > suggestion of font. > the dialog box should have three property sheets. the first one if the > one > you see, the second one is font related > do you have similar issues with other dialog boxes ? No, but I wouldn't worry about it if it is working on other people's. (It looks like some sort of problem with the Tab sheets) Bill p.s. Happy New Year

Dec. 31, 2001

Re: Wine Tasklist

by eric pouech

> The TransGaming subscribers have voted for us to do something to > fix this. I'd like to put one of our people on it, but we can't > spare them right now from their DX8 tasks. So: we are willing to > sponsor the development of an ALSA back-end sound driver for Wine, > if anyone is willing to work on it. If you're interested in doing > the work, let me know and we can discuss details. I have this on my (rather long) todo list, and don't need sponsoring so you might get it for free. > Why would you want to use Winedbg for a Winelib application, instead > of gdb? multi-threading, native DLL symbol support A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Dec. 31, 2001

Re: What have I done to my debugger?

by eric pouech

> When I right click on the window I get offered a menu including a > "defaults". When I select that I get a dialog with three groups of > controls; a cursor size, a history and a "conf" something. I see no > suggestion of font. the dialog box should have three property sheets. the first one if the one you see, the second one is font related do you have similar issues with other dialog boxes ? A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Dec. 31, 2001

Re: We *really* need a development model change !

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > It seems the problem is not so big. It will be sufficient to run the > binary, compiled under Windows not more often than once a month. But it won't compile. Once we have a simple environment in Wine where you run make test and everything happens automatically, people will use that. They won't bother to update all the makefiles etc. that you need in order to build on Windows. Then every time someone tries to build the tests under Windows they will have to fix a ton of problems before it works. We simply cannot expect people to constantly dual-boot to run their tests in both environments, so we need a way to make sure that when code works on one platform it also works on the other without extra work. We could certainly build a Windows infrastructure that does everything automatically for C tests, but this is a massive amount of work. > BTW, tests in Perl address only execution of applications, not compilation. Compilation is not an interesting case. 99% of it is tested by compiling Wine itself, and the remaining occasional problem is trivial to locate and fix. There's simply no need for regression testing of the compilation environment. -- Alexandre Julliard julliard(a)winehq.com

Dec. 31, 2001

Re: Wine Tasklist

by Gavriel State

eric pouech wrote: > > > * Native Alsa support > > - Could it offer capabilities that OSS does not offer? > [snip] > > - Anti-rational: Alsa includes an OSS compatibilty mode that seems to > > work pretty well > ALSA is needed when you need proper full duplex capabilities > however, only ALSA 1.0 should be supported (0.5 and 0.9 shouldn't, > except > if 0.9 interface turns out to stay the one for 1.0) One of the most annoying problems we've seen with Alsa OSS emulation is that it doesn't properly support directly mmap-ing the sound buffer. It kind of claims to do it, but on most of the machines we've tried alsa on, actually doing the mmap fails. This means that to build a single Wine binary that supports doing dsound on most different hardware, we have to disable direct sound buffer access, and use the dsound HEL mode instead. This, in turn, results in either latency problems, or cracking, depending on how we tune dsound, even on OSS systems. And problems are magnified on ALSA cards, since the driver is doing yet another layer of conversion before sending the data out to the sound chip. The TransGaming subscribers have voted for us to do something to fix this. I'd like to put one of our people on it, but we can't spare them right now from their DX8 tasks. So: we are willing to sponsor the development of an ALSA back-end sound driver for Wine, if anyone is willing to work on it. If you're interested in doing the work, let me know and we can discuss details. > > * Winedbg g++ 3.0 support > > - The debugging format and the ABI changed in g++ 3.0 and winedbg > > does not support the new ABI. > > - This prevents debugging of C++ Winelib applications > > - This is especially troublesome for MFC Winelib applications Why would you want to use Winedbg for a Winelib application, instead of gdb? > some other items to look at: > * make the server a linux kernel module (has been discontinued) but > could > provide some performance enhancements We did some more examination of this question, and came up with some notes and code for doing a server-accellerator kernel module that would move some functionality into the kernel, but keep the current architecture mostly intact. If I recall, the architecture centered around the creation of a /proc like virtual file-system for managing NT kernel objects. Our own resources for continuing this effort directly are limited, but again, we would consider sponsoring further development along these lines: WineServer overhead is one of the nastier performance blocks for several games we've looked at. I'll try to see if we can put the notes and code we've done so far into better shape to be picked up by someone else. -Gav -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com

Dec. 31, 2001

Re: What have I done to my debugger?

by Bill Medland

"eric pouech" <eric.pouech(a)wanadoo.fr> wrote in message news:3C24D122.90D3ED88(a)wanadoo.fr... > Bill Medland wrote: > > > > I'm getting the wrong sort of terminal. Why? > > > > I vaguely remember doing something to the registry settings for the debugger > > about a month ago but I can't remebber what. Since then I have not been > > tripping it anyway. However I am now investigating a problem that does trip > > the debugger. However it now comes up with an enormous terminal of some > > sort with terrible font and bad agreement between font and cursor > > positioning, so that important data disappears off the right of the screen > > before wrapping. However in the old days it used to use an xterm. I'd like > > to go back to that. > you can change the size of the font it doesn't suit you. right click in > the > console window, then choose the default settings.. here, set up the font > you'd like. it'll be saved into the registry and used at next > wineconsole > invocation Impressive. It's a long time since I discovered a way to lock up the Linux box solidly but that does the job nicely. :-( When I right click on the window I get offered a menu including a "defaults". When I select that I get a dialog with three groups of controls; a cursor size, a history and a "conf" something. I see no suggestion of font. Also the three buttons look to be poorly placed and do not appear to be selectable. The only choice I appear to have is to remove the dialog with the x in the top right, which is when the machine hangs. (No mouse, no keyboard). I think I'll just go with redirecting. Bill

Dec. 31, 2001

Re: We *really* need a development model change !

by Andriy Palamarchuk

One more point in favour of C-based tests. They will be very useful in porting Wine to non-Intel platforms. C tests will help to test both - execution of Windows applications under processor emulator and compilation of Windows applications with Winelib. > 1. It is much easier to install under Windows than a full development > environment, and we don't have to worry about supporting a dozen > different compilers. We can simply provide a zip file containing the > compiled script interpreter, and people can be up and running in seconds. We can create MinGW toolchain distribution, customized for the test application. Besides original MinGW tools (about 32Mb) this distribution can include command-line, GUI CVS clients, GUI test application launcher. Can you suggest any other tools? The launcher will have functionality to run Wine test application, update it from CVS, build, create patch. Such distribution is mostly newbie-oriented. With script-based tool it is still necessary to install CVS separately or we need to create our own distribution. Another advantage of C-based tests is that they provide smooth path from tests creation to contributing to core Wine project. Thanks, Andriy Palamarchuk __________________________________________________ Do You Yahoo!? Send your FREE holiday greetings online! http://greetings.yahoo.com

Dec. 31, 2001

mvcrt.ungetc and stdio buffering

by Waldek Hebisch

Recently I tried to run g77 compiled Fortran program under Wine. It seems that to do any input g77 uses `ungetc'. Currently, Wine msvcrt has unbufferd stdio. I would like to add buffering and implement `ungetc'. Are there any traps (thread safety ??) or will strightforward implementation work ? -- Waldek Hebisch hebisch(a)math.uni.wroc.pl or hebisch(a)hera.math.uni.wroc.pl

Dec. 31, 2001

Re: current cvs doesn't compile with freetype-2.0.3

by James Juran

Ben Stanley wrote: > > Hi, > > I tried compiling current cvs wine on RH 7.2, and it fails... > > gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 > -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT > -I/usr/X11R6/include -o freetype.o freetype.c > freetype.c:43:31: freetype/ftnames.h: No such file or directory > make[2]: *** [freetype.o] Error 1 > make[2]: Leaving directory `/share/building/wine/wine/dlls/gdi' > > It seems that the autoconf test for freetype/ftnames.h doesn't work > properly. The file is not present in the RH package, and is not included > in the freetype-2.0.3 tarball either. It works fine for me with RH 7.2 and freetype-2.0.3. Try rm config.* ./configure make depend make James Juran

Dec. 31, 2001

Re: We *really* need a development model change !

by Andriy Palamarchuk

Responding to Alexandre and Jeremy. Alexandre Julliard wrote: > Basically the argument is that some sort > of scripting language is better than plain C for two reasons: > > 1. It is much easier to install under Windows than a full development > environment, and we don't have to worry about supporting a dozen > different compilers. We can simply provide a zip file containing the > compiled script interpreter, and people can be up and running in > seconds. Completely agree with this one. > 2. The scripts are independent from the compilation environment, which > allows testing binary compatibility. In C you have to compile the > tests under Wine using the Wine headers, which means you can't spot > wrong definitions in the headers since the test will see the same > definition as Wine itself. The only way around is to build tests > under Windows and run them under Wine but this is a major pain. > With a script you are guaranteed to run the exact same thing in both > environments. It seems the problem is not so big. It will be sufficient to run the binary, compiled under Windows not more often than once a month. > There are probably a number of things you cannot do from Perl, like > threads or exception handling, and for that we will want some kind of > C framework too. But I believe we can already go a long way with the > Perl stuff we have today. Some technical challenges we can overcome by improving our Perl framework, other we will be handled with C. > Maybe I'm wrong, maybe it's really unusable > and we need to scrap it and redo a C environment from scratch; but we > won't know that until we try to use it seriously. Whether Perl in convenient enough language in comparison with C remains to be decided. I see following biggest problems with Perl: 1) as I mentioned before the first problem is in capturing audience of test creators. Even be Perl the best programming language ever: a) existing Wine developers are experts in C. Even those who knows Perl are more experienced in C. b) attracting new developers. We want to target developers who already knows or want to know Win32 API, right? Usually these people are not those who program in scripting languages. I'm not sure if we will be able to justify before them learning new language. 2) Wine targets problem "Compilation and execution of Win32 applications". C is the native language of this problem. All the problems and solutions can be easy expressed in C and require translation when converted to other languages. All the documentation, learning materials are C-oriented. BTW, tests in Perl address only execution of applications, not compilation. The biggest advantage of scripting language in this application is easiness of installation. Most people who know or want to learn Win32 API already have to use some kind C development environment. I'd prefer to lose 10 developers who don't want to learn C instead of losing one expert in Win32 API who thinks that Perl sucks ;-) Andriy Palamarchuk

Dec. 31, 2001