wine-devel

wine-devel@winehq.org

11 participants
84440 discussions

Re: wine and aol7 [was: Re: New Winsock2 patch series - now tested]
by Martin Wilck 25 Apr '02

25 Apr '02

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@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Re: wine and aol7 [was: Re: New Winsock2 patch series - now tested]
by Martin Wilck 25 Apr '02

25 Apr '02

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@Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

1 0

Last patch for Mingw32 Warnings
by Steven Edwards 25 Apr '02

25 Apr '02

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

1 0

Send the first two mingw32 patches to /dev/null and use these instead
by Steven Edwards 25 Apr '02

25 Apr '02

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

1 0

Re: Installing MS Office gives error in installer
by Speeddymon 25 Apr '02

25 Apr '02

actually i did manage to get it work work from the cd, you have to explicitly specify the -o unhide command when you run mount or put the unhide command in your /etc/fstab... as for the files not getting written, i had the same problem, it is the .lnk files (that i assume go in the start menu on windows)...i am thinking that they aren't being properly converted to .desktop files or something. I will try installing with crossover office tonight and post the results tomorrow -Dustin --- Rizsanyi Zsolt <rizsanyi(a)myrealbox.com> wrote: On Wednesday 17 April 2002 21:42, Speeddymon wrote: > > I just recently installed wine-20020411 (as you > > may > > have noticed from my patch) > > I haven't tried installing Office 2000 on previous > > versions, but heard that it worked, so I decided > to > > try it. First I tried it in Crossover Office > (since i > > just recently got that also) and the Office 2000 > > installer complained that it couldnt find a > package to > > install on the installation media. So I tried it > in > > wine and it did the same thing... There were no > debug > > messages or anything (in the console). > > > > If anyone knows of a way around this, please let > me > > know... If it has been mentioned before please > point > > me to the right wine-devel archive so I can find > it... > > I have also dared to try to install office2k, and > had the same problem. > But I have found a workaround... > When the installation fails, the MSI installer is > already copied to your > windows directory (I think its name is > installmsi.exe or something like that > - I dont have it at hand). So I have tried to invoke > it with the msi file in > the root of the CD (the data1.msi or something like > that - the other msi is > something else). > This way the installation started. The configuration > of what programs to > install worked perfectly, but when copying the files > the installer broke, and > said that it can't write a file. I dont know what > was the problem. I had > enough space, the persmissions were ok, and so on. > > I have tried again, and the installer broke again > but now with a different > file. So I give up, since I don't really need it to > install, just I wanted to > see what the people are talking about... But if you > find a solution (or > submit a patch :), then I will be interested... > > Best regards, > Zsolt Rizsanyi > __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/

3 9

Another warning fix for Mingw32
by Steven Edwards 25 Apr '02

25 Apr '02

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)

1 0

Another Minor Mingw32 Patch
by Steven Edwards 25 Apr '02

25 Apr '02

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

1 0

RE: minor regression testing patch
by Geoffrey Hausheer 25 Apr '02

25 Apr '02

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

3 2

Re: C/L utility to translate unix and dos paths
by Michael Wetherell 24 Apr '02

24 Apr '02

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

1 0

err:ntdll:RtlpWaitForCriticalSection
by Insyde 24 Apr '02

24 Apr '02

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.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel