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

current cvs doesn't compile with freetype-2.0.3

by Ben Stanley

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. BTW, I'm not on the list atm. Ben.

Dec. 31, 2001

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

by Alexandre Julliard

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > Hmm, and different "winver" settings for testing of the behaviour of > different Wine --winver settings and adapting to different Windows versions > are possible with this framework, too ? In its current state it uses the default Wine config from ~/.wine so any config changes can be done this way (of course we will have to support -winver in the config file, but we need that anyway). We could provide a set of standardized configs to reduce variation, but it may in fact be preferable to let people run with the config they normally use, so that we have a wider coverage of the different options. > Oh, and what about Win16 support of the test suite ? Not supported yet, though this could be added. In fact since the Perl layer already needs to convert the arguments, making it support 16-bit should be relatively easy, and probably a lot more transparent than doing it in C. > Still, I think we should try to have a C "compatibility" layer, too, for > two reasons: > - people who aren't familiar with anything else > - supporting diversity (what if someday we find out that perl "sucks" ? :-) If it turns out Perl doesn't work, we can always convert the tests to C, this should be relatively easy. Most of the tests will simply be a bunch of function calls and result checks, which is simple to do in any language. Besides, unless you want to do elaborate tests, you really don't need to know much Perl to be able to write tests with winetest. -- Alexandre Julliard julliard(a)winehq.com

Dec. 31, 2001

Re: Wine Tasklist

by eric pouech

a few comments... > * Cross process messages > - used by many applications > - needed for DDE (bug 95) > - Alexandre, you worked on this recently, right? Is this working now? > - See bug 93 interprocess messages should be fine now (even if all the interprocess object sharing isn't over yet) DDE is being worked on, so I don't think you should keep the item > * 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) > * aRts support > * ESounD support I think it would be a too high task to implement all the drivers... there's quite some activity right now on linux audio to ease this a bit. let's see where stuff like JACK will go > * Move the winsock16 code to wsock32 more generally, it would be a good thing to be able to tear 16 bit code away from wine (with a configure switch). This would be a must-have for embedded wine. Not really fun to do. > > * Winedbg expression handling > - when modifying the contents of a variable there can be mixups where > the debugger modifies its own memory instead of that of the > debugged process. do you have a precise example for this one ? this is more a bug than a big thing to do. from the debugger stand point, you could add: - (re)implement function calls from interpreter - add 16 bit trap support - write a transformer to make MSVC .DBG files from wine's .so files (&stabs) so that standard windows debugger can handle native DLLs - implementing imagehlp (or debughlp) would also be appreciated > > * 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 > - Eric, you worked on this recently, do you know if this is a thing > of the past or is it possible that there are still problems (I did > not test recently) winedbg never had support for the C++ ABI (neither from GCC nor MSVC). So GCC 3.0 shouldn't be an exception regarding the debugging format, it seems more (but I didn't install nor looked closely at it) that gcc chooses which debug format to use instructing gcc with -gstabs (or -gstabs+) instead of -g should ease the issue some other items to look at: * make the server a linux kernel module (has been discontinued) but could provide some performance enhancements A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Dec. 30, 2001

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

by Andreas Mohr

[omitting comments about very nice "make test" framework] On Sun, Dec 30, 2001 at 12:34:06PM -0800, Alexandre Julliard wrote: > Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > > > 1) The discussion started from John Sturtz post, who > > created the Perl module for Win32 functions. > > Discussion what is better - C or Perl for unit testing > > started later as I understand there was no conclusion. > > Now I can assume that this topic was not "discussed to > > death" and we can do it now ;-) > > OK you are right, it was discussed to death inside CodeWeavers, but > not all of that was public. Basically the argument is that some sort Hmm right. I really should have remembered the extent of these discussions. > 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. That one goes to you, I guess. > 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. 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. ...at which point we already have a huge data collection of "known expected function behaviour" that's just waiting for us to port it easily to C then or so... Hmm, and different "winver" settings for testing of the behaviour of different Wine --winver settings and adapting to different Windows versions are possible with this framework, too ? (we'd very much want to have that, I guess) Oh, and what about Win16 support of the test suite ? This is why I started this in the first place. I'm very much afraid of losing HUGE amounts of Win16 compatibility due to everybody using more and more Win32 programs only... I haven't toyed with the "make test" environment yet (severe lack of time - exam time), so I don't know much about it. Unfortunately I'm afraid I won't have much time in the foreseeable future either. Still, I think we should try to have a C "compatibility" layer, too, for two reasons: - people who aren't familiar with anything else - supporting diversity (what if someday we find out that perl "sucks" ? :-) That's it for now, Andreas (who'd really like to be able to contribute more to this now)

Dec. 30, 2001

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

by David Elliott

On 2001.12.30 15:34 Alexandre Julliard wrote: > 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. > Well, if it helps any, I have recently built a linux-cross-mingw32 toolchain as RPMs. For those not running on an RPM distro the specfiles should be easy enough to understand and do manually. For those who are running RH7.2 (and probably 7.1 as well) you can have the binary packages. And for all other RPM distros the source RPMs should build without problems. I have the following RPMs built: i386-mingw32-binutils-2.11.2-0_biscuit_0 i386-mingw32-gcc-bootstrap-3.0.3-0_biscuit_0 (built from the same specfile as the normal gcc but only makes a C compiler good enough to build w32api and mingw-runtime properly). i386-mingw32-w32api-1.2-0_biscuit_0 i386-mingw32-mingw-runtime-1.2-0_biscuit_0 All the rest are part of the gcc build: i386-mingw32-gcc-3.0.3-0_biscuit_0 i386-mingw32-gcc-c++-3.0.3-0_biscuit_0 i386-mingw32-libstdc++-devel-3.0.3-0_biscuit_0 i386-mingw32-gcc-g77-3.0.3-0_biscuit_0 i386-mingw32-gcc-java-3.0.3-0_biscuit_0 (unfortunately it didn't compile the java runtime, so this one is useless until I figure that out) If anyone is interested in this I can probably put it in kernelrpm.sourceforge.net temporarily before I contact the MinGW team and see if they would be interested in hosting these files on their sourceforge site. Please note that this is not just a simple compile. I had to do quite a bit of patching (well, figuring out what to patch was the issue, the patches are tiny) to get it to build and work properly even including thread support. I also have compiled wxMSW with this compiler and successfully built and tested the minimal, mdi, and taskbar test programs. Of note is that the MDI program does not show any icons in the toolbar when run under Wine, but works perfectly under Windows (95osr2 in Win4Lin). Is anyone aware of this, might be related to IE5.5 displaying black squares instead of icons in its toolbar, and would be significantly easier to debug as I built all of this with debugging info (assuming winedbg can read it), plus you'd have the full sourcecode from wxwindows.org. -Dave

Dec. 30, 2001

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

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > 1) The discussion started from John Sturtz post, who > created the Perl module for Win32 functions. > Discussion what is better - C or Perl for unit testing > started later as I understand there was no conclusion. > Now I can assume that this topic was not "discussed to > death" and we can do it now ;-) OK you are right, it was discussed to death inside CodeWeavers, but not all of that was public. 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. 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. I started implementing a simple scripting language, but then John Sturtz showed that it was possible to leverage Perl to do the same thing, so I think it's the way to go. 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. 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. -- Alexandre Julliard julliard(a)winehq.com

Dec. 30, 2001

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

by Alexandre Julliard

Andriy Palamarchuk <apa3a(a)yahoo.com> writes: > No, ability to call W32 API functions is not > considered a unit test infrastracture. I may say Wine > has such infrastructure for C since 1993 :-). From > this point of view Andreas test application provides > more support for unit tests than plain Perl module. Not really, because you need a lot more infrastructure to build C tests than to simply run Perl scripts. For Perl all you need is the winetest app that is in the tree, plus a bit of Makefile glue which is pretty trivial to do. In fact here's a 10-minute hack to add a make test target. With that all you have to do is create a test script in dlls/xxx/tests/foo.test, put the expected output in tests/foo.test.ref (presumably generated by running the test under Windows), add your script to the makefile and run make test. Index: Make.rules.in =================================================================== RCS file: /opt/cvs-commit/wine/Make.rules.in,v retrieving revision 1.95 diff -u -r1.95 Make.rules.in --- Make.rules.in 2001/12/14 23:14:22 1.95 +++ Make.rules.in 2001/12/30 18:00:41 @@ -47,6 +47,7 @@ RM = rm -f MV = mv MKDIR = mkdir -p +DIFF = diff -u C2MAN = @C2MAN@ MANSPECS = -w $(TOPSRCDIR)/dlls/gdi/gdi32.spec \ -w $(TOPSRCDIR)/dlls/user/user32.spec \ @@ -58,6 +59,8 @@ ALLLINTFLAGS = $(LINTFLAGS) $(DEFS) $(OPTIONS) $(DIVINCL) WINAPI_CHECK = $(TOPSRCDIR)/tools/winapi_check/winapi_check WINEBUILD = $(TOPOBJDIR)/tools/winebuild/winebuild +WINETEST = $(TOPOBJDIR)/programs/winetest/winetest +RUNTEST = $(TOPOBJDIR)/programs/winetest/runtest MAKEDEP = $(TOPOBJDIR)/tools/makedep WRC = $(TOPOBJDIR)/tools/wrc/wrc WMC = $(TOPOBJDIR)/tools/wmc/wmc @@ -95,7 +98,7 @@ # Implicit rules -.SUFFIXES: .mc .rc .mc.rc .res .spec .spec.c .glue.c +.SUFFIXES: .mc .rc .mc.rc .res .spec .spec.c .glue.c .test .test.out .test.ref .c.o: $(CC) -c $(ALLCFLAGS) -o $@ $< @@ -121,6 +124,12 @@ .c.ln: $(LINT) -c $(ALLLINTFLAGS) $< || ( $(RM) $@ && exit 1 ) +.test.test.out: + $(RUNTEST) $(TOPOBJDIR) $< > $@ + +.test.out.test.ref: + $(DIFF) $< $@ && touch $@ + .PHONY: all install uninstall clean distclean depend dummy # 'all' target first in case the enclosing Makefile didn't define any target @@ -216,7 +225,7 @@ -cd `dirname $@` && $(RM) $(CLEAN_FILES) clean:: $(SUBDIRS:%=%/__clean__) $(EXTRASUBDIRS:%=%/__clean__) - $(RM) $(CLEAN_FILES) $(GEN_C_SRCS) $(GEN_ASM_SRCS) $(RC_SRCS:.rc=.res) $(RC_SRCS16:.rc=.res) $(MC_SRCS:.mc=.mc.rc) $(PROGRAMS) + $(RM) $(CLEAN_FILES) $(GEN_C_SRCS) $(GEN_ASM_SRCS) $(RC_SRCS:.rc=.res) $(RC_SRCS16:.rc=.res) $(MC_SRCS:.mc=.mc.rc) $(TESTS:%=tests/%.out) $(PROGRAMS) # Rules for installing @@ -225,6 +234,13 @@ $(SUBDIRS:%=%/__uninstall__): dummy cd `dirname $@` && $(MAKE) uninstall + +# Rules for testing + +test:: $(WINETEST) $(TESTS:%=tests/%.out) $(TESTS:%=tests/%.ref) + +$(WINETEST): + cd $(TOPOBJDIR)/programs/winetest && $(MAKE) winetest # Misc. rules Index: Makefile.in =================================================================== RCS file: /opt/cvs-commit/wine/Makefile.in,v retrieving revision 1.103 diff -u -r1.103 Makefile.in --- Makefile.in 2001/11/23 23:04:58 1.103 +++ Makefile.in 2001/12/30 18:00:41 @@ -132,6 +132,9 @@ @cd dlls && $(MAKE) checklink @cd debugger && $(MAKE) checklink +test:: + @cd dlls && $(MAKE) test + TAGS etags: etags `find $(TOPSRCDIR) -name '*.[chS]' -print | grep -v dbgmain` Index: dlls/Makedll.rules.in =================================================================== RCS file: /opt/cvs-commit/wine/dlls/Makedll.rules.in,v retrieving revision 1.16 diff -u -r1.16 Makedll.rules.in --- dlls/Makedll.rules.in 2001/09/17 20:09:08 1.16 +++ dlls/Makedll.rules.in 2001/12/30 18:01:00 @@ -36,6 +36,10 @@ checklink:: lib$(MODULE).$(LIBEXT) $(CC) -o checklink $(TOPSRCDIR)/library/checklink.c -L. -l$(MODULE) $(ALL_LIBS) && $(RM) checklink +# Rules for testing + +$(TESTS:%=tests/%.out): lib$(MODULE).$(LIBEXT) + # Rules for debug channels debug_channels: dummy Index: dlls/Makefile.in =================================================================== RCS file: /opt/cvs-commit/wine/dlls/Makefile.in,v retrieving revision 1.109 diff -u -r1.109 Makefile.in --- dlls/Makefile.in 2001/11/06 17:52:37 1.109 +++ dlls/Makefile.in 2001/12/30 18:01:02 @@ -764,6 +764,9 @@ # Misc rules +$(SUBDIRS:%=%/__test__): dummy + @cd `dirname $@` && $(MAKE) test + $(SUBDIRS:%=%/__checklink__): dummy @cd `dirname $@` && $(MAKE) checklink @@ -773,6 +776,8 @@ install:: $(SUBDIRS:%=%/__install__) uninstall:: $(SUBDIRS:%=%/__uninstall__) + +test:: $(SUBDIRS:%=%/__test__) checklink:: $(SUBDIRS:%=%/__checklink__) --- /dev/null Fri Dec 7 20:45:56 2001 +++ programs/winetest/runtest Sat Dec 29 17:00:48 2001 @@ -0,0 +1,9 @@ +#!/bin/sh +topobjdir="$1" +shift +perldir="$topobjdir/programs/winetest" +LD_LIBRARY_PATH="$topobjdir/dlls:$topobjdir:$LD_LIBRARY_PATH" +export LD_LIBRARY_PATH +WINESERVER="$topobjdir/server/wineserver" +export WINESERVER +exec $perldir/winetest -debugmsg -all -- -I $perldir $@ -- Alexandre Julliard julliard(a)winehq.com

Dec. 30, 2001

Re: Mixed-mode CD Labels

by Chris Green

Ok -I'm just about ready to submit a patch :) What I've done is to check for the pre-iso signature, and if it occurs, to increase the offset by 8. This puts the offset in a position that makes the get label function find the correct entry. I've tested it with both 'normal' iso9660 cds, and with pre-iso cds (e.g. MS Multimedia Beethoven, and MS Cinemania 92) and it works flawlessly in both cases. Any comments by anyone before I send in the patch? regards Chris Green

Dec. 30, 2001

Re: Mixed-mode CD Labels

by David Elliott

On 2001.12.30 05:10 Chris Green wrote: > On Sunday 30 December 2001 20:04, you wrote: > > > got about 8 of them so far, just use 'dd if=/dev/scd0 of=cd.dmp > bs=65536 > > > count=1' and compress the result before emailing it to me :) > > > > hmm, wouldn't dd if=/dev/cdrom of=cd.dmp bs=2048 count=32 be better? > > > > Maybe it doesn't make a damn bit of difference, but as the blocksize on > > cds is 2048 bytes I think it makes more sense to say gimme the first 32 > > 2048-byte sectors. > > > > six of one, half-a-dozen of the other :) they give the same data, I just > often go for large block sizes and smaller counts - some read-ahead type > operations run faster, I find, if you do that. I don't mind either way :) > Duh! For some reason I was thinking the other way around... i.e. If you specify the blocksize as less than what the blocksize is (or not on an integer multiple of it) then you run into issues. You are correct, specifying it as 64kiB (gotta love the new SI standards, hehe) would actually increase the reading performance, not decrease it. -Dave

Dec. 30, 2001

Re: Mixed-mode CD Labels

by Chris Green

On Sunday 30 December 2001 20:04, you wrote: > > got about 8 of them so far, just use 'dd if=/dev/scd0 of=cd.dmp bs=65536 > > count=1' and compress the result before emailing it to me :) > > hmm, wouldn't dd if=/dev/cdrom of=cd.dmp bs=2048 count=32 be better? > > Maybe it doesn't make a damn bit of difference, but as the blocksize on > cds is 2048 bytes I think it makes more sense to say gimme the first 32 > 2048-byte sectors. > six of one, half-a-dozen of the other :) they give the same data, I just often go for large block sizes and smaller counts - some read-ahead type operations run faster, I find, if you do that. I don't mind either way :) Chris

Dec. 30, 2001

Re: Mixed-mode CD Labels

by David Elliott

On 2001.12.30 03:34 Chris Green wrote: > If anyone has an odd CD lying around, they can email me the first 65536 > bytes > of the CD (hopefully no vendor will care about copyright on their volume > descriptors!) so I can compare the structure of the volume descriptors - > I've > got about 8 of them so far, just use 'dd if=/dev/scd0 of=cd.dmp bs=65536 > count=1' and compress the result before emailing it to me :) > hmm, wouldn't dd if=/dev/cdrom of=cd.dmp bs=2048 count=32 be better? Maybe it doesn't make a damn bit of difference, but as the blocksize on cds is 2048 bytes I think it makes more sense to say gimme the first 32 2048-byte sectors. -Dave

Dec. 30, 2001

Re: Mixed-mode CD Labels

by Chris Green

On Friday 28 December 2001 21:38, Andreas Mohr wrote: > On Fri, Dec 28, 2001 at 09:24:14PM +1000, Chris Green wrote: > > On Friday 28 December 2001 20:24, Andreas Mohr wrote: > I think what should be done is to find out which mixed-mode CDs exactly are > "special" and which ones aren't. > > I guess it might be music CDs with builtin biography data/programs often > that are problematic. > > If you get hold of such CDs, then you need to experiment with > CDROMREADMODE2, CDROMREADMODE1 and/or CDROMREADRAW ioctl()s > (in /usr/include/linux/cdrom.h) to get back sector data. > I already verified once that you can get the CD label of "problematic" > mixed-mode CDs this way. > I couldn't figure out the mechanism that e.g. Windows uses to calculate > the serial number of these CDs, though. > > You might probably want to figure out a way to have misc/cdrom.c > also support label and serial reading of problematic mixed-mode CDs, in a > modular way (i.e. one that doesn't look too awful code-wise ;) Ok - I've been doing some serious experimenting here, including reading the iso 9660 spec :) I've found some interesting things too. First, it seems that some CD's don't just store the 'best' data in higher-numbered volume descriptors. Some seem to store 'everything' in the type 1 (primary) descriptor, and only store the modified info in the type 2 (secondary) descriptor. So the routine CDROM_Data_FindBestVoldesc (it returns the highest-numbered descriptor) might need some rethinking... Secondly, I found a real curiosity in one particular CD: Microsoft's Multimedia Beethoven (about 1992) isn't ISO9660 at all. It's a mixed mode CD, and is readable in Windows, as well as Wine, but the label is screwy (Windows XP gets it wrong too). Instead of using the specification identifier 'CD001' (ISO9660) it uses 'CDROM' and has two dwords stored at the start of the volume descriptor, as well as having a few other discrepancies. I have no conclusive proof as to what specification it's written, but I'm guessing its possibly the original High Sierra format, or perhaps an even earlier, semi-proprietary, spec. Either way, it makes me wonder whether some of the 'strange' mixed-mode CDs are of a similar nature. Anyway, what I'm thinking is to rewrite the code that deals with CD labels to take into account what I've found so far - I'll also include support to get the label from the 'CDROM' type I've found, so we'll have the right label for that CD too. Quite possibly, that'll fix the 'strange' mixed mode CD's too. If anyone has an odd CD lying around, they can email me the first 65536 bytes of the CD (hopefully no vendor will care about copyright on their volume descriptors!) so I can compare the structure of the volume descriptors - I've got about 8 of them so far, just use 'dd if=/dev/scd0 of=cd.dmp bs=65536 count=1' and compress the result before emailing it to me :) regards Chris Green

Dec. 30, 2001

Re: Using windows dlls in unix shared libraries

by lawson_whitney＠juno.com

On Fri, 28 Dec 2001, Robert Jonsson wrote: > Hi all, > > I just subscribed to this list, I hope my questions aren't evidently > answered elsewhere, I tried to do some homework browsing the docs and > parts of the mailing list, but then again I'm no pro so I might have > missed it. > > The background story: > There is a plugin system for professional audio applications in Windows > called VST. I suppose it does pretty much the same job as a multimedia > codec. With the exception that they have internally generated GUIs! > Perhaps a winamp plugin would be the closest match. > There is a similar format in Linux called LADSPA (www.ladspa.org) > Basically what I seek to do is try and wrap a VST plugin in a LADSPA plugin. > > The question: > I don't know that much about Wine internals, but all the example > applications I've looked at use the wine executable as boot loader. Does I thought to quibble with that, but it is a pretty fair analogy after all. Wine (including wineserver and wine builtin dlls) is a *NIX application, but it does provide "OS" services. It sort of needs an address space or two to kick around if it is going to be able to load native dlls that are not relocatable, FI. > that mean that this is the only way to start a wine application? Well, something has to be sure the wineserver is started. > The way I'd like to use it is like this: > Linuxhost (dlopen ladspaplug) - LADSPAplugin (LoadLibrary vstplugin) - > VSTplugin Can your ladspaplug not fork and exec wine to run your vst wrapper? > > A possible solution would be to startup the VSTplugin in another > application and do IPC between the LADSPAplugin and the > VSTplugin-proxyhost. > Like this: > Linuxhost (dlopen ladspaplug) - LADSPAplugin <----ipc----> > winebased_VSThost (LoadLibrary vstplugin) - VSTplugin > This does however seem akward... Is it possible to do it in an easier way? There isn't all that much to the wine executable these days. Most of Wine is in the builtin dlls and the wineserver. Have a look at <wine>/miscemu/main.c. If you think you can get that to run inside your plugin, maybe you can. Codeweavers did a crossover plugin whosis for linux browsers, I think, that would have had to address the problems. Lawson

Dec. 29, 2001

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

by Jeremy White

Andriy (and all), I think you have dismissed winetest much too quickly. We spent a considerable amount of energy thinking about a test harness (largely because one of our investors felt passionately that it was vital), so not only did we have the public conversations you saw on wine-devel, we here at CodeWeavers also had some lengthy private conversations. I entered that process feeling much as you do: that 'C' based tests were the way and the truth and the light. I was persuaded that a Perl based test was, in fact, a viable alternative, if not a better alternative. Several points: 1. John Sturtz worked very hard to make the Perl code able to take callbacks. AFAIK, it does that. 2. The Perl code makes it easy to do pattern matching, hex dumps, and general text manipulation, which is a good thing. 3. Perl is really easy to install and use in Windows; writing these tests in Windows is a total snap, and, I would argue, Windows is exactly where the tests should be written. All that aside, I think the most important tasks are a simple set: 1. Modify the makefiles so that 'make test' (or make regress, or pick your poison) does something interesting, and does so without much hassle. 2. Define a standard for how tests should work. For example, if I wanted to write a test for FunctionFoo(), I should be able to create wine/programs/winetest/tests/foo.pl, add 'foo.pl' to winetest/tests/Makefile.in, and my test should automatically become part of the regression suite. (Note that adding tests/foo.c is just as trivial). I believe that the defacto standard chosen at this point is that a test prints 'OK' if all went well, and it doesn't on error, and prints some clue as to what went wrong. 3. Add a section to the documentation on how to do the same. In my not so humble opinion, that is a very straightforward task, that shouldn't take very long, and would be an excellent beginning for shifting the development model. Once we have in place the concept of a 'make regress', we can start expanding on that to roll in new testing tools; I just think it's a mistake to arbitrarily discard a perfectly useful tool. Jer Andriy Palamarchuk wrote: > Simplicity is one of the goals of the testing > framework, but besides being simple the framework > should be powerful enough for such big project. > > I'm looking for existing library which would suit our > needs. > > Unit test framework "Check" looks promising. It > provides many features which I'd love to use for our > tests, including: > - protection of the test address space - tests crashed > do not put down the whole test suite and are reported. > At the same time you can request to run tests in the > same address space what is good for debugging. > - grouping tests in suites, tree-like grouping of the > test suites. You can choose to run only subset of the > tests > - having "set up" and "tear down" sections which can > be used to set up tests and free resourses after. > - a few forms of output - from silent to detailed > > Individual test looks like (section from manual): > > START_TEST(test_create) > { > fail_unless (money_amount(five_dollars) == 5, > "Amount not set correctly on creation"); > fail_unless > (strcmp(money_currency(five_dollars),"USD") == 0, > "Currency not set correctly on creation"); > } > END_TEST > > They also give information how to configure the tests > with autoconf. > > The issues which need to be resolved: > 1) License - GPL. Is it Ok to have the test suite > under GPL? > 2) Environment - POSIX. The library uses POSIX calls > to manage processes, in particular functions fork, > _exit, write, read, close, getppid, getpid, pipe. > Calls "fork" , "_exit" and "getppid" are used only > when test runs in FORK mode. We don't need to have > address space protection under Windows - tests there > should not crash. > The rest of functions are used for communication > between the test launcher and tests and can be > implemented with using corresponding Win32 calls. > After implementing these changes the framework can be > used in pure Win32 environment, without Cygwin. > > Let me know if you are interested. I'll start to work > on the port. Meantime we can start to use the > framework under Wine and on Windows with Cygwin. > > More information about Check you can find here: > http://check.sourceforge.net/ - home page > http://sourceforge.net/project/showfiles.php?group_id=28255 > - tutorial > > Thanks, > Andriy Palamarchuk > > __________________________________________________ > Do You Yahoo!? > Send your FREE holiday greetings online! > http://greetings.yahoo.com > >

Dec. 29, 2001

Re: Getting "Practice Exam" software working

by Andreas Mohr

On Fri, Dec 28, 2001 at 04:44:17PM -0700, Dax Kelson wrote: > > We have a training room full of students who are taking a cisco networking > design class. The class is basically all lecture so they don't normally > use a computer, but tomorrow the students need to take a practice exam. > > The student workstations are running Red Hat Linux 7.2. > > Their student books come with a CDROM with a practice exam program that > is, of course, a windows app. > > I've tried with the Wine that shipped with RH7.2, todays CVS snapshot, and > Codeweaver's preview 5 all with the same results. > > It *almost* works. I would rather get it working so we don't have install > windows just for them to run this one app. www.winehq.com/Trouble/ "how to get stuff working" or so should help. -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/

Dec. 29, 2001