April 2002 - Wine-Devel - list.winehq.org

BUG in my patch series

by Martin Wilck

On Wed, 24 Apr 2002, Michael Cardenas wrote: > Attached is a patch that corrects martin wilck's previous patch. It just adds > an if flags before deref'ing the flags variable. Not sure if this is the most > correct, but it corrects the crash. OK, it was a really stupid bug resulting from the fact that File_GetUnixHandle would call File_GetUnixHandleType. Strange I didn't run into it myself yet. However I'd recommend the following patch instead of yours - please try if it also solves your problem. Cheers and thanks for spotting this, Martin --- files/file.c.orig Thu Apr 25 11:18:30 2002 +++ files/file.c Thu Apr 25 11:17:37 2002 @@ -361,7 +361,11 @@ */ int FILE_GetUnixHandle( HANDLE handle, DWORD access ) { - return FILE_GetUnixHandleType( handle, access, NULL, NULL ); + int ret, fd = -1; + + ret = wine_server_handle_to_fd( handle, access, &fd, NULL, NULL ); + if (ret) SetLastError( RtlNtStatusToDosError(ret) ); + return fd; } /*************************************************************************

April 25, 2002

Re: wine and aol7 [was: Re: New Winsock2 patch series - now tested]

by Martin Wilck

On Wed, 24 Apr 2002, Michael Cardenas wrote: > Attached is a patch that corrects martin wilck's previous patch. It just adds > an if flags before deref'ing the flags variable. Not sure if this is the most > correct, but it corrects the crash. So flags is really an invalid pointer - can you see from which routine FILE_GetUnixHandleType is called ? That is where we should fix the bug IMO. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 25, 2002

Re: wine and aol7 [was: Re: New Winsock2 patch series - now tested]

by Martin Wilck

On Wed, 24 Apr 2002, Michael Cardenas wrote: > If anyone wants to work on aol or just to see it working, I can provide a deb > package or a tarball that lets you install aol, so you don't have to worry > about the aol installer working. I submitted some patches a few weeks ago > that allow aol7 to launch. I'd like to test it, but I can't connect to AOL proxies from here (firewall). And I am not really interested in becoming an AOL member just to get this straight... However I shall help as much as I can without having AOL running on my machines. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 25, 2002

Re: wine and aol7 [was: Re: New Winsock2 patch series - now tested]

by Martin Wilck

Hi Michael, I wonder whether "flags" is an invalid pointer - but I cannot figure out why it should be, from the calls to FILE_GetUnixGandleType that exist. Please try to generate a trace with trace+winsock,trace+server,trace+file. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

April 25, 2002

Last patch for Mingw32 Warnings

by Steven Edwards

Once again if someone wants to help I only have one warning left to fix. Changelog: More Mingw32 warning fixes cvs diff -u winnls.h Index: winnls.h =================================================================== RCS file: /home/wine/wine/include/winnls.h,v retrieving revision 1.32 diff -u -r1.32 winnls.h --- winnls.h 10 Mar 2002 00:02:34 -0000 1.32 +++ winnls.h 25 Apr 2002 07:07:43 -0000 @@ -26,6 +26,13 @@ extern "C" { #endif +#ifdef __MINGW__ +#undef _MAX_PATH +#undef _MAX_DIR +#undef _MAX_EXT +#undef _MAX_DRIVE +#include "stdlib.h" +#endif #define MB_PRECOMPOSED 0x00000001 #define MB_COMPOSITE 0x00000002 "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

April 25, 2002

Send the first two mingw32 patches to /dev/null and use these instead

by Steven Edwards

Sorry about that. If you decide to apply them use this instead. I messed up and used CFLAGS=-D_MINGW_ instead of __MINGW__ cvs diff -u windef.h Index: windef.h =================================================================== RCS file: /home/wine/wine/include/windef.h,v retrieving revision 1.62 diff -u -r1.62 windef.h --- windef.h 10 Mar 2002 00:02:34 -0000 1.62 +++ windef.h 25 Apr 2002 02:09:36 -0000 @@ -157,8 +157,9 @@ #define _MAX_EXT _MAX_FNAME #define _MAX_PATH 260 #endif +#if ! defined (__MINGW__) #define MAX_PATH _MAX_PATH - +#endif #define HFILE_ERROR ((HFILE)-1) cvs diff -u makedep.c Index: makedep.c =================================================================== RCS file: /home/wine/wine/tools/makedep.c,v retrieving revision 1.10 diff -u -r1.10 makedep.c --- makedep.c 10 Mar 2002 00:24:22 -0000 1.10 +++ makedep.c 25 Apr 2002 02:11:38 -0000 @@ -24,6 +24,10 @@ #include <string.h> #include <unistd.h> +#ifdef __MINGW__ /* Taken from GLib */ +#define ftruncate(fd, size) +#endif + /* Max first-level includes per file */ #define MAX_INCLUDES 200 "Every revolution was once a thought in one man's mind" - Ralph Waldo Emerson

April 24, 2002

Re: Installing MS Office gives error in installer

by Rizsanyi Zsolt

On Thursday 25 April 2002 03:45, Speeddymon wrote: > en it proceeds with the kde1 install, if you are running kde2 with the .kde > dir it proceeds with kde2 install and if you are running kde2 with .kde2 > dir it also proceeds with kde2 installi also figured out why things weren't > being added to the k menu in mandrake...if you use the mandrake-style the k > menu (as opposed to the default style) it stores the menu config files in > /usr/share/menu instead of ~/.menu so i fixed it so that the menu configs > are copied to both locations and everything seems to work well now. my > only concern is if the 1st part of the fix (the one mentioned in the > previous paragraph) will work on redhat or not, seeing as i dont know > whether the menu configs are stored in ~/.menu or /usr/share/menu. Anyone > that cares to test it out and let me know, feel free..> You should not make > that script to cope with every> possible setup. That would > be an > overkill.> You should just make it to work with all the major> distros.> > Other distros, and individuals with sp! ecial setup> should change the > > wineshelllink before installing or packaging.> see response above> At most > you could make tools/wineinstall ask for the> needed info and generate > > wineshellink according to it. I like this idea...that may or may not be > needed, depending on the outcome of a redhat tester> > Best regards> Zsolt > Rizsanyithanks, and you too :)the patch is in the next message I'm running redhat. (v7.2) Here the applinks (*.desktop files) are in /etc/X11/applnk/. Or if it is a kde specific one then in /usr/share/applnk/ But I think wine should go in /etc/X11/applnk Of course this only holds if the user who runs the installer in wine is root. If it is a simple user then you have to install to ~/.kde/share/applnk/ as it is already done in the wineshelllink... Zsolt Rizsanyi

April 24, 2002

Another warning fix for Mingw32

by Steven Edwards

Same as last, if someone wants to help write a conf check by all means. Changelog: If the platform isnt MingW32 then define MAX_PATH cvs diff -u windef.h Index: windef.h =================================================================== RCS file: /home/wine/wine/include/windef.h,v retrieving revision 1.62 diff -u -r1.62 windef.h --- windef.h 10 Mar 2002 00:02:34 -0000 1.62 +++ windef.h 25 Apr 2002 02:00:24 -0000 @@ -157,8 +157,9 @@ #define _MAX_EXT _MAX_FNAME #define _MAX_PATH 260 #endif +#if ! defined (_MINGW_) #define MAX_PATH _MAX_PATH - +#endif #define HFILE_ERROR ((HFILE)-1)

April 24, 2002

Another Minor Mingw32 Patch

by Steven Edwards

This one could have a configure check but I havent had the time to learn How to properly write one and mingw is the only platform I know of that doesn't have ftruncate support. If anyone has the time and wants to help I have about 4 or 5 things I need ./conf checks written for. Changlog: Added ftruncate support for makedep on MingW32 cvs diff -u makedep.c Index: makedep.c =================================================================== RCS file: /home/wine/wine/tools/makedep.c,v retrieving revision 1.10 diff -u -r1.10 makedep.c --- makedep.c 10 Mar 2002 00:24:22 -0000 1.10 +++ makedep.c 25 Apr 2002 01:42:50 -0000 @@ -24,6 +24,10 @@ #include <string.h> #include <unistd.h> +#ifdef _MINGW_ /* Taken from GLib */ +#define ftruncate(fd, size) +#endif + /* Max first-level includes per file */ #define MAX_INCLUDES 200

April 24, 2002

Re: Installing MS Office gives error in installer

by Speeddymon

> I dont think you should go by asking the user. You> cant be sure, if he knows > it right. The question is not only about its kde> version, but also the > directory of his config files...which config files would you be referring to?> > Besides, this script is not intended to ask for user> input.> > You will be better of, if you just fix my patch, to> not copy to .kde by > default, but check if there exists a .kde2 and in> that case to copy there.> Actually I decided not to ask for the user input after all, instead it runs kded -v (if kded exists since i wasn't sure if kde 1.x had it or not) and greps the output for KDE: and sed's that to remove the KDE: (so that just the version number is there) and then writes that to /tmp/kdeverif /tmp/kdever doesn't exist then it proceeds like it would have before my patchif it does, it sed's the number in there for the first part of that number (1 or 2) and uses that to determine if you are running kde1 or kde2if you are running kde1 then it proceeds with the kde1 install, if you are running kde2 with the .kde dir it proceeds with kde2 install and if you are running kde2 with .kde2 dir it also proceeds with kde2 installi also figured out why things weren't being added to the k menu in mandrake...if you use the mandrake-style the k menu (as opposed to the default style) it stores the menu config files in /usr/share/menu instead of ~/.menu so i fixed it so that the menu configs are copied to both locations and everything seems to work well now. my only concern is if the 1st part of the fix (the one mentioned in the previous paragraph) will work on redhat or not, seeing as i dont know whether the menu configs are stored in ~/.menu or /usr/share/menu. Anyone that cares to test it out and let me know, feel free..> You should not make that script to cope with every> possible setup. That would > be an overkill.> You should just make it to work with all the major> distros.> Other distros, and individuals with special setup> should change the > wineshelllink before installing or packaging.> see response above> At most you could make tools/wineinstall ask for the> needed info and generate > wineshellink according to it. I like this idea...that may or may not be needed, depending on the outcome of a redhat tester> > Best regards> Zsolt Rizsanyithanks, and you too :)the patch is in the next message --------------------------------- Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more

April 24, 2002

Re: minor regression testing patch

by Jakob Eriksson

On Wed, Apr 24, 2002 at 03:58:36PM -0700, Francois Gouget wrote: > On Wed, 24 Apr 2002, Geoffrey Hausheer wrote: [...] > Undocumented behavior should not be tested for unless an application > depends on that behavior. Our goal is not to make a clone of a specific > version of Windows but to be able to run Windows applications on Unix. Wine will be a version of Windows of its' own, then. > > I'm probably making a mountain out of a molehill, and I'll just try > > modifying my tests to work the way Alexandre proposes. I'm just afraid this > > is setting additonal obstacles for (non Wine) developers to write regression > > tests. The mountain/molehill might be this: an application checks for anomaly A. It now "knows" it runs under Win95 OSR2 and then expects also anomaly B present in Win95 OSR2. Wine might behave differently. But in practice this might not be a problem. So I guess you're right, we will deal with this stuff as it turns up. -- regards, Jakob Eriksson The wages of sin is debugging. -- Ron Jeffries

April 24, 2002

Re: Installing MS Office gives error in installer

by Rizsanyi Zsolt

On Wednesday 24 April 2002 19:31, Speeddymon wrote: > --- Rizsanyi Zsolt <rizsanyi(a)myrealbox.com> wrote: > > On Tuesday 23 April 2002 19:51, Speeddymon wrote: > > > what i was saying before though was that the > > > > windows > > > > > link files (.lnk extension) weren't being put into > > > > the > > > > > kde menu, i believe it is a bug/problem in > > > > 20020411 > > > > > wine mainly due to that fact that that wine > > > > wouldn't > > > > > install the icons but crossover office wine > > > would...who knows, all is well now on my computer > > > though. thanks for the help guys. > > > > The wineshelllink (the script responsible for > > installing the lnk files in the > > desktop menu) in the cvs wine assumes, that if you > > have a .kde directory in > > your home, then you have kde 1.x installed. > > And install kde 2.x files only if you have a .kde2 > > directory in your home > > folder. > > But on some systems (eg. RedHat), the kde config > > files are in .kde in home > > directory. That is the reason why the .desktop files > > are not installed on > > some systems. > > > > I have fixed wineshelllink in my cvs copy of wine, > > but never submitted it, > > because, I'm not really sure how to fix it to work > > on all the systems (I dont > > know how the other packagers do it). > > But if somebody needs, it I'm attaching the patch... > > > > Best regards > > Zsolt Rizsanyi > > hmm that has me wondering... i will take a look at > that tonight as i will have more time then (just gonna > run home to get my zip disk right now) and see what I > can come up with in terms of having wineshelllink > finding the correct version..... we may need to > remove the direcory checking stuff altogether... i > have a couple ideas... 1) explicitly ask them for > their kde version the first time wineshelllink is run > (but then they would have to manually change the > version number if they upgrade it) 2) always ask what > the version # is... 3) read a file created by kde that > has the version # in it (if one exists) 4) run some > kde command with the --version arg and use it's output > to get the kde version if possible > > 1 and 2 could be implemented directly in bash but then > you have the problem of what if it doesn't get run in > a terminal, so you could also have someone make a > gtk/tk program that asks and is called from > wineshelllink or you could do both and have 1 run if > $display is set and the other one run if it isn't... > > just some thoughts... I dont think you should go by asking the user. You cant be sure, if he knows it right. The question is not only about its kde version, but also the directory of his config files... Besides, this script is not intended to ask for user input. You will be better of, if you just fix my patch, to not copy to .kde by default, but check if there exists a .kde2 and in that case to copy there. You should not make that script to cope with every possible setup. That would be an overkill. You should just make it to work with all the major distros. Other distros, and individuals with special setup should change the wineshelllink before installing or packaging. At most you could make tools/wineinstall ask for the needed info and generate wineshellink according to it. I like this idea... Best regards Zsolt Rizsanyi

April 24, 2002

Compiling the latest version of wine ...

by Fabrizio Regalli

Hello, I'm trying to compile the latest version of wine, but I see some problem: ./configure && make dep && make , works fine. After that I see this: root(a)bizio:/home/rizla/wine-20020411# ./tools/wineinstall WINE Installer v0.72 You are running wineinstall as root, this is not advisable. Please rerun as a user. Aborting. Ok, I switch user from root to rizla rizla(a)bizio:~/wine-20020411$ ./tools/wineinstall ..and It' works.. WINE Installer v0.72 Warning !! wine binary (still) found, which may indicate a (conflicting) previous installation. You might want to abort and uninstall Wine first. I see that WINE has already been configured, so I'll skip that. We need to install wine as root user, do you want us to 'su root' and install Wine? Enter 'no' to continue without installing (yes/no) -I ANSWER YES-Wine build complete. Performing 'make install' as root to install binaries, enter root password Password: (I put my EXACT password, casesensitive too but I see this)/bin/bash: - : unrecognized option Either you entered an incorrect password or we failed to run 'make install' correctly. If you didn't enter an incorrect password then please report this error to wine-devel(a)winehq.com. Installation failed, aborting. How to solve this problem ? If i answer NO at the question of su - root , it seems work as user but, when it try to configure something, it has stopped. We need to install wine as root user, do you want us to build wine, 'su root' and install Wine? Enter 'no' to continue without installing (yes/no) no NOTE! To run Wine without installing, you must set the environment variable LD_LIBRARY_PATH to /home/rizla/wine-20020411:/home/rizla/wine-20020411/dlls in your logon scripts. Create local config file ~/.wine/config? (yes/no) yes Searching for an existing Windows installation... found. Created /home/rizla/.wine/config using your existing Windows installation. You probably want to review the file, though. ..and it has stopped without the prompt... I'm using slack 8 with kernel 2.4.18 Bye and thanks

April 24, 2002

Re: Unit testing

by Francois Gouget

On Wed, 24 Apr 2002, Michael Cardenas wrote: > > If that's the bug, maybe we can come up with a better error message. Looking a little bit more in detail at the error message: ld -r ../../programs/winetest/wtmain.o tests/testlist.o tests/alloc.o tests/directory.o tests/path.o tests/process.o tests/thread.o tests/file.o -o tests/kernel32_test.tmp.o tests/file.o: In function `func_alloc': /home/jakov/src/WINE/wine/dlls/kernel/tests/file.c(.text+0x7c): multiple definition of `func_alloc' tests/alloc.o(.text+0xe80):/home/jakov/src/WINE/wine/dlls/kernel/tests/alloc.c: first defined here ld: Warning: size of symbol `func_alloc' changed from 39 to 24 in tests/file.o It appears that the file.c test file was copied from the alloc.c test file but START_TEST(alloc) was not changed accordingly. Sure it would be nice to have a better error message. I will let you do the required change in the linker though. Unless you had something else in mind? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.

April 24, 2002

RE: minor regression testing patch

by Francois Gouget

On Wed, 24 Apr 2002, Geoffrey Hausheer wrote: [...] > One answer is not to test this, since it is not documented what the result > will be, but the OSes certainly behave differently, and it is possible that > some program takes advantage of this. I'm sure there are other similar > cases, and I'd like to know (in general) what the right solution will be. Undocumented behavior should not be tested for unless an application depends on that behavior. Our goal is not to make a clone of a specific version of Windows but to be able to run Windows applications on Unix. Testing undocumented behavior should only be done if you know of an application that depends on this behavior, and then that application should be mentioned in the test. > I'm probably making a mountain out of a molehill, and I'll just try > modifying my tests to work the way Alexandre proposes. I'm just afraid this > is setting additonal obstacles for (non Wine) developers to write regression > tests. I don't think it does. If you only have access to Win98, the only way to write a test that is sure to work on all Windows platforms is to do: if (version==win98) { do_test(); } As you pointed out, because Win98 behaves a given (possibly documented) way does not mean that Win95 / NT4 / Win XP are going to behave the exact same way. But if you write tests in this fashion,~ it will be pretty much impossible to detect cases where different Windows versions diverge. So the best way to deal with that is to just do the test on all platforms, and rely on people who have access to platforms to which you don't have access, to come and fix the test so that it also works on their platform. This is, after all, the open-source way. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux

April 24, 2002

RE: minor regression testing patch

by Geoffrey Hausheer

> -----Original Message----- > From: Alexandre Julliard julliard(a)winehq.com {WineHQ-devel} > Version checks are a bad idea because this is not how Wine is > implemented. For instance GetLongPathName under Wine doesn't try to > fail if you are running with -winver win95, it just works. Adding > version checks in the tests just means that some functions won't get > tested if you run with the wrong version. > > The right way is to always call the function no matter the version, > and check that the call either succeeds as expected, or fails in the > way that it's supposed to fail on a platform that doesn't support it. The problem I forsee with this is that it makes writing tests a bit tricky for functions that behave differently on different platforms (i.e. defining the failure conditions correctly). Otherwise, it is a good thing to strive for. I'll try to modify the tests I've written to behave in this manner, and see how much work it is. Unfortunately, it is somewhat difficult, since I don't (in general) have access to the platforms which don't support the functions. So I can write tests that pass on Win2k, Win98, and wine, but as soon as someone runs it on win95 or nt4.0, it will likely fail (since I have no idea what the failure mechanism will be on these platforms, and thus can't gaurd against it) until someone can provide enough feedback to allow the test to be fixed. My assumption has always been: Make the function work correctly on Windows, and then add todo's to support wine. Thus I've put the effort in upfront to catch errors when the application runs on an MS OS. It sounds to me that you are proposing a more wine-centric testing base (make the tests work in Wine, and fix problems encountered in Windows as they pop up...or be a lot more knowledgeable than me at how Windows is supposed to behave). So far I have written all my tests based purely on the MSDN spec, and then tweaked them when an OS behaves differently than documented. If I don't use OS-specific checks, I just feel like I'm leaving a known whole in my test if I don't account for the the cases which are documented not to work (and which I don't know how they will behave). For instance the thread.c test that I wrote makes (some) checks for access control, which only work on win2k+. The way I wrote the test, it just worked in win98 when I finally got around to testing it. Had I just executed the checks, I would have had no idea how Win98 would behave (hopefully with a nice SetError, but god only knows), and the test would certainly have failed on win98 until I was able to try it and figure out how it dealt with this unsupported functionality. Lastly, what is the recomendation for dealing with cases like this: lstrcpyA(tmpstr,"aaaaaaaa"); len1=GetTempPathA(len,tmpstr); /*this should fail because len is too small */ ok(len1==len+1, "GetTempPathA should return string length %d instead of %d",len+1,len1); if(WIN2K_PLUS(version)) { /* in Win2k, the path won't be modified, but in win98, wine it is */ todo_wine { ok(lstrcmpiA(tmpstr,"aaaaaaaa")==0, "GetTempPathA should not have modified the buffer"); } } One answer is not to test this, since it is not documented what the result will be, but the OSes certainly behave differently, and it is possible that some program takes advantage of this. I'm sure there are other similar cases, and I'd like to know (in general) what the right solution will be. I'm probably making a mountain out of a molehill, and I'll just try modifying my tests to work the way Alexandre proposes. I'm just afraid this is setting additonal obstacles for (non Wine) developers to write regression tests. Thanks, .Geoff

April 24, 2002

Wine[X] and Grand Prix 3 (Microprose)

by Rene Rebe

Hi all. I just turned my last 10 hours into configuring Wine to run Formula One Grand Prix 3 from Microprose. After several tries using the latest Wine and WineX (making many mistakes with the registry files ...) I got it to run using the last-night WineX cvs soruce ;-) I only have trhee graphic problems: a) the menus (where you configure several game options/details) do not appear in the right colors. Like a 8bit image displayed with the wrong color-pallete. b) in the race with very perfect weather (0% rain risk) - where the sky should be completely blue - the sky doesn't get painted at all -> resulting in "tearing" textures, because this area doesn't get refresh. (when some clouds show up the graphic is perfect) and c) Direct3D is not recognized at all -> resulting that the game runs in software-rendered mode. For a) I guess it migth be a wrong 16bit mode (or even an 8 bit mode) - my XFree-4.2.0 is running in 16bit mode normally. 24bit XFree results in the same mess and 8bit X results in a slighty worser images. About b) I guess some bitblt or clear function is nor working properly. I also tested the PerferctGraphics and DoubleBuffer option of Wine yielding the same results ... For c) OpenGL on my Matrox G450 is configured and runs fine - I have no clue whatever Wine[X] needs to provide Direct3D ... ? I can provide whatever trace output is needed - and would also offer to write some code if someone points me to the place in the souce where something is missing (I know C and C++ ...). I could also provide trace output to get (generic) Wine run the game. (It seems to be a problem that more DirectDraw is missing?). The rest of the game runs just fine, including Sound and Joystick support. Configuration: - Linux 2.4.19-pre7 - glibc-2.2.6 - gcc-2.95.3 - XFree-4.2.0 - AMD Athlon 1700XP; Matrox MGA 450 (OpenSouce driver) [- ROCK Linux (http://www.rocklinux.org) k33p h4ck1n6 René -- René Rebe (Registered Linux user: #248718 <http://counter.li.org>) eMail: rene.rebe(a)gmx.net rene(a)rocklinux.org Homepage: http://drocklinux.dyndns.org/rene/ Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms.

April 24, 2002

Re: Unit testing

by Michael Cardenas

If that's the bug, maybe we can come up with a better error message. On Wednesday 24 April 2002 04:30 pm, Francois Gouget wrote: > On Wed, 24 Apr 2002, Jakob Eriksson wrote: > [...] > > > START_TEST(alloc) > > ^^^^^ > > The above means that your file is called 'alloc.c'. Reciprocally, > the above should match the name of the C file in which the test is > otherwise you will get the 'func_alloc' error that you had. -- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi

April 24, 2002

cups support apparently broken

by Michael Cardenas

Hello all. Apparently wine's cups support is broken. With our old version of wine, wine would correctly detect the current cups printer, but it couldn't actually print to it. So, you would see the print dialog, but when you hit the print button nothing happened. Now, I have cups installed and a build of yesterday's cvs and when I try to print wine tells me that there are no printers installed and I should "point to settings on the windows start menu, click printers" and add a printer. Anyone have any ideas on how this broke? thank you michael -- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi

April 24, 2002

word can't open documents...

by Michael Cardenas

With yesterday's cvs, opening a document causes it to crash with this output on the console: fixme:listview:LISTVIEW_UnsupportedStyles LVS_SHAREIMAGELISTS fixme:listview:LISTVIEW_SetItemCount flags LVSICF_NOINVALIDATEALL LVSICF_NOSCROLL not implemented fixme:file:FindFirstChangeNotificationA this is not supported yet (non-trivial). fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents\\Lkdjs ldkjsdlkj sdlkj s.doc", 0x00000001, 0x40552218, 0x4055263c): stub fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents", 0x00000001, 0x40553d68, 0x4055418c): stub fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents\\Lkdjs ldkjsdlkj sdlkj s.doc", 0x00000001, 0x4055435c, 0x40554780): stub fixme:mpr:WNetGetUniversalNameW (L"Z:\\DOS\\My Documents\\Lkdjs ldkjsdlkj sdlkj s.doc", 0x00000001, 0x405532b0, 0x405536d4): stub X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 1 (X_CreateWindow) Value in failed request: 0x0 Serial number of failed request: 30392 Current serial number in output stream: 30395 -- michael cardenas lead windows compatibility engineer lindows.com "Be the change you want to see in the world" -Mahatma Gandhi

April 24, 2002

Re: Unit testing

by Francois Gouget

On Wed, 24 Apr 2002, Jakob Eriksson wrote: [...] > START_TEST(alloc) ^^^^^ The above means that your file is called 'alloc.c'. Reciprocally, the above should match the name of the C file in which the test is otherwise you will get the 'func_alloc' error that you had. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Computers are like airconditioners They stop working properly if you open WINDOWS

April 24, 2002

Re: C/L utility to translate unix and dos paths

by Michael Wetherell

On Wednesday 24 Apr 2002 7:51 pm, you wrote: > --- Michael Wetherell <mike.wetherell(a)ntlworld.com> > > wrote: > > Yes I know cygpath, winepath is intended to be a > > kind of Wine version of the > > same thing. > > > > The programs aren't interchangeable though, cygpath > > knows about Cygwin's > > mount points while winepath knows about Wine's DOS > > drives. > > Agree. Thought you may not know about cygpath and this > information will be interesting for you. > > Andiry > Yes thanks, it was interesting, many options. Mike

April 24, 2002

Re: Unit testing

by Jakob Eriksson

#include "winbase.h" #include "winerror.h" #include "wine/test.h" static void test__hread(void) { LPCSTR lpPathName = "testfile.txt"; HFILE filehandle; filehandle = _lcreat(lpPathName, 0); ok(filehandle != HFILE_ERROR, "_lcreat failed."); /* _hwrite();*/ ok(DeleteFileA(lpPathName) != 0, "DeleteFile failed."); } START_TEST(alloc) { test__hread(); } this is my, of course very incomplete test for _hread(). But it doesn't even compile and I don't understand why. I get this error: ----------------- ../../programs/winetest/runtest -q -P wine -M kernel32.dll -T ../.. tests/atom.pl && touch tests/atom.ok Could not stat /mnt/fd0 (No such file or directory), ignoring drive A: gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REEN TRANT -I/usr/X11R6/include -o tests/file.o tests/file.c ld -r ../../programs/winetest/wtmain.o tests/testlist.o tests/alloc.o tests/directory.o tests/path.o tests/process. o tests/thread.o tests/file.o -o tests/kernel32_test.tmp.o tests/file.o: In function `func_alloc': /home/jakov/src/WINE/wine/dlls/kernel/tests/file.c(.text+0x7c): multiple definition of `func_alloc' tests/alloc.o(.text+0xe80):/home/jakov/src/WINE/wine/dlls/kernel/tests/alloc.c: first defined here ld: Warning: size of symbol `func_alloc' changed from 39 to 24 in tests/file.o make: *** [tests/kernel32_test.tmp.o] Error 1 ----------------- What's func_alloc got to do with anything? What is it? -- regards, Jakob Eriksson The wages of sin is debugging. -- Ron Jeffries

April 24, 2002

Re: wine and aol7 [was: Re: New Winsock2 patch series - now tested]

by Michael Cardenas

Attached is a patch that corrects martin wilck's previous patch. It just adds an if flags before deref'ing the flags variable. Not sure if this is the most correct, but it corrects the crash. Files affected: wine/files/file.c Patch against cvs from 04232002 with martin wilck's 4th in his last series of patch applied. Fixes a crash for aol7 and internet explorer (the only two apps I tested, probably for lots of other apps also) On Wednesday 24 April 2002 02:20 pm, Michael Cardenas wrote: > Hello Martin. > > I tested your new series of patches with aol7 and I get a crash. Attached

April 24, 2002

err:ntdll:RtlpWaitForCriticalSection

by Insyde

Hi, Starting a program with: wine --winver win2k --debugmsg -relay,+x11drv,+snoop+dll iyp022.exe (the same error occurs with --winver win98/win95) gives me the folowing error: x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file fixme:dialog:MSGBOX_OnInit task modal msgbox ! Not modal yet. err:ntdll:RtlpWaitForCriticalSection section 0x400f164c "module.c: loader_section" wait timed out, retrying (60 sec) fs=021f wine: Unhandled exception, starting debugger... x11drv: Warning: $DISPLAY variable ignored, using ':0.0' specified in config file err:ntdll:RtlpWaitForCriticalSection section 0x400f164c "module.c: loader_section" wait timed out, retrying (60 sec) fs=021f err:win:WIN_FindWndPtr window 30021 belongs to other process err:win:WIN_FindWndPtr window 30021 belongs to other process In the debbuger windows I have some debug msgs that the debbuger is trying to load and at the end it shows this message: Unhandled exception: wait failed on critical section 0x400f164c (loader_section in libntdll.dll.so) First chance exception: wait failed on critical section 0x400f164c (loader_section in libntdll.dll.so) and this message keeps repeating. How can I solve this? Already tryed with native ntdll.dll and it doesn't work. The program runs OK under Windows. Another problem I'm having is that if I don't specify --winver it doesn't work at all. Is it right? Thanks, Ricardo.

April 24, 2002