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

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 25, 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 25, 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 25, 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 25, 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 25, 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 25, 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 25, 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 25, 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 25, 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