June 2004 - Wine-Devel - list.winehq.org

Re: wine/include ddeml.h
by andrejoh＠c2i.net June 14, 2004

June 14, 2004

* Alexandre Julliard (Mon, 14 Jun 2004 11:58:02 -0500) wrote: | Dmitry Timoshkov <dmitry(a)codeweavers.com> | Fix CBR_BLOCK definition. | | Patch: http://cvs.winehq.org/patch.py?id=12591 | | Old revision New revision Changes Path | 1.29 1.30 +1 -1 wine/include/ddeml.h This one causes a compile failure: dde/server.c: In function `WDML_ServerHandleRequest': dde/server.c:580: error: pointers are not permitted as case values switch ((ULONG_PTR)hDdeData) [...] case CBR_BLOCK: The patch below fixes it by casting to an ULONG_PTR, which is what the switch variable is casted to. Index: dlls/user/dde/server.c =================================================================== RCS file: /home/wine/wine/dlls/user/dde/server.c,v retrieving revision 1.16 diff -u -w -p -r1.16 server.c --- dlls/user/dde/server.c 26 Apr 2004 23:29:44 -0000 1.16 +++ dlls/user/dde/server.c 14 Jun 2004 19:18:52 -0000 @@ -577,7 +577,7 @@ static WDML_QUEUE_STATE WDML_ServerHandl WDML_PostAck(pConv, WDML_SERVER_SIDE, 0, FALSE, FALSE, pXAct->atom, pXAct->lParam, WM_DDE_REQUEST); break; - case CBR_BLOCK: + case (ULONG_PTR)CBR_BLOCK: ret = WDML_QS_BLOCK; break; default: -- Try Anarchy Online http://www.anarchy-online.com/content/downloads/tryout/ Netiquette guidelines ftp://ftp.rfc-editor.org/in-notes/rfc1855.txt How to quote properly http://www.i-hate-computers.demon.co.uk/ Hvordan sitere riktig http://home.online.no/~vidaandr/news/OBSquoting.html

1 0

Re: wine/dlls/user/dde client.c
by Ivan June 14, 2004

June 14, 2004

This patch http://www.winehq.com/hypermail/wine-cvs/2004/06/0085.html breaks the build on Mandrake 10.0 using gcc 3.3.2 and make 3.8, with the following error: dde/server.c: In function `WDML_ServerHandleRequest': dde/server.c:580: error: pointers are not permitted as case values make[2]: *** [dde/server.o] Error 1 make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls/user' make[1]: *** [user] Error 2 make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls' make: *** [dlls] Error 2 Ivan.

1 0

Re: revised winmm GetDevCaps better pointer check patch
by Alexandre Julliard June 14, 2004

June 14, 2004

Robert Reif <reif(a)earthlink.net> writes: > +/* Use the first version for strict compatibility with Microsoft */ > +/* #define WINMM_IsBadWritePtr(x,y) IsBadWritePtr((x), (y)) */ > +#define WINMM_IsBadWritePtr(x,y) ((x)==NULL) This is very confusing, if we don't check the pointer we shouldn't have a macro that looks like we do. The proper way is to add exception handlers in functions where an app explicitly relies on the pointer check, and not add checks otherwise; using the IsBad*Ptr functions is always wrong since they are not thread-safe. -- Alexandre Julliard julliard(a)winehq.org

1 0

General serial communications issues
by David Purucker June 14, 2004

June 14, 2004

Hello, I have tried several terminal programs (Hyperterm and TeraTerm) under several builds of Wine including Wine-20040505 and they seem to have the same generic problem. They all exhibit the same situation, DATA seems to go OUT, but never seems to come IN. Several other people have experienced the same thing, as seen in this bug report: http://bugs.winehq.org/show_bug.cgi?id=2115 By the way, TeraTerm does work fine in TCP/IP mode, so it's definitely a serial problem. It's freeware available here: http://hp.vector.co.jp/authors/VA002416/teraterm.html It appears to be a fundamental problem in the serial/file code, which I understand is now under the ntdll tree. Obviously, I don't know much about it, but there is definitely something wrong. I was wondering if any developers were aware of this problem, as the decreased general usage of serial communications may have caused this to slip under the carpet, so to speak. I look forward to hearing any ideas, work-arounds, or patches. Thanks _________________________________________________________________ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.click-url.com/go/onm00200362ave/direct/01/

7 20

Re: Fix 3 bugs in locale handling
by Alexandre Julliard June 14, 2004

June 14, 2004

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > 1. If the locale has changed current code never refreshes win.ini > and registry values due to the following test done in GetLocaleInfoW: > > /* first check for overrides in the registry */ > > if (!(lcflags & LOCALE_NOUSEROVERRIDE) && lcid == GetUserDefaultLCID()) > { > > lcid is always pointing to current user locale returned by GetUserDefaultLCID() > and therefore cached (old) values get returned. > > I modified code to get data directly from kernel resources in that case. It seems to me that this is what we are doing already since we pass LOCALE_NOUSEROVERRIDE in that case, I don't see how your patch would make any difference (and win.ini definitely gets refreshed with the current code). Could you please give more details on the problem you are seeing? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: SHELL32:RunFileDlg
by Alexandre Julliard June 14, 2004

June 14, 2004

Filip Navara <xnavara(a)volny.cz> writes: > + if (!(hRes = FindResourceW(shell32_hInstance, L"SHELL_RUN_DLG", (LPWSTR)RT_DIALOG))) You cannot use wide char string constants in Wine. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Fix Private Profile Functions for .INI in Current Directory
by Alexandre Julliard June 14, 2004

June 14, 2004

Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > As per MSDN (1), if a relative path to a file is passed in to the > {Get,Write}PrivateProfile* functions then the current directory is tried > first, and then if that fails the Windows directory is used (for both > the opening and creating cases). I don't see any evidence that this is true, and MSDN says "If the lpFileName parameter does not contain a full path and file name for the file, WritePrivateProfileString searches the Windows directory for the file". Do you have a test case showing that the current behavior is wrong? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Do we still need wineinstall?
by Ivan June 14, 2004

June 14, 2004

> So - do we still need it? Can we use the registry (BTW then will winecfg be working?) to set up all the stuff we can do in the config file? Stuff such as winver, UseDGA, UseXVidMode, Managed or desktop more, and DllOverrides? If we can, IMHO wineinstall can go. Ivan.

1 0

text input focus problem
by Richard Gobeille June 14, 2004

June 14, 2004

Recently I upgraded a piece of software on my system called Synergy. This software allows one keyboard and mouse to control input on two or more machines via a network connection -- not dissimilar to VNC, except that only the keyboard and mouse input is forwarded, nothing with video, et cetera, and that it lets you mouse back and forth as if you were using a dualhead configuration on one box. Anyhow, the problem is as follows: when using Synergy, I'm no longer able to use text input in wine at all. This applies to both winehq and crossover, winex appears to be unaffected. Originally, I thought this was a problem with Synergy itself, but upon asking the developer about it, I received notification that it was an X11 bug that wine wasn't working around. The technical details are as follows: "the X11 bug is subtle: if client A creates two windows X and Y where Y is a child of X and selects for key events on window X, it expects to receive key events that occur in either X or Y (the events in Y propagate up to the nearest ancestor that has selected for the event). if another client B (synergy) comes along and selects for key events in Y then not only will B receive key events from Y (as expected) but key events in A will no longer propagate from Y to X and A won't see the events. that is, when B selects for events on window Y it changes the behavior of client A. this is just wrong." One of the guys in #winehq on freenode (TD) said to send this to wine-devel, so here it is. I'm not sure if any more information is required. The site for Synergy is http://synergy2.sourceforge.net. Any 1.1.x release should demonstrate the problem for you. I'm hopeful that this will be an easy problem to work around as winex is working around it, but I'm not sure how similar or dissimilar the trees are in this area. -- *Richard Gobeille* Chief Technical Officer Envision7, LLC Internet Services http://www.envision7.com rich(a)envision7.com

1 0

Re: Yahoo!
by Johane June 14, 2004

June 14, 2004

1 0

Forum notify
by Johane June 14, 2004

June 14, 2004

1 0

Re: Yahoo!
by Twickline June 14, 2004

June 14, 2004

1 0

Versioning and internal APIs
by Mike Hearn June 13, 2004

June 13, 2004

Hi Alexandre, Paul Davis of Ardour has raised a good point: currently despite the fact that the symbols in libwine are versioned, we change them at will and don't change the symbol version, for instance in the patch that made environ passed through to wine_init from main to hack around the general suckage of MacOS X. Unless this versioning system is meant to be dormant until Wine 1.0 is out (and we should definitely document this if so), perhaps we should be changing the symbol versions? Also, there is no easy way to find out the version of Wine you got from dlopen at runtime. Should we export a wine_version symbol? Finally, apparently Paul has had to duplicate a fair amount of Wine code inside his libfst (library for loading Cubase VST plugins) because the relevant functions are declared static in Wine. Paul, could you post a list of exactly what you use? It might be worth extending and starting to freeze some of these semi-internal interfaces. thanks -mike

3 5

[MSVCRT] Separate internal definitions from the public headers
by Dimitrie O. Paun June 13, 2004

June 13, 2004

Hi Alexandre, Welcome back! I did this last Friday, but I didn't want to continue before running it by you. I'm sending here just the first cut of the definitions I needed to duplicate in msvcrt.h, to compile the entire msvcrt DLL without the MSVCRT() define in the public headers. Looking at the changes it seems to me: 1. There aren't that many 2. We can easily add a test file to check for consistency with the public headers (ideally, this file would be automatically generated by a script) 3. We should be able to actually drop some of them, this is just the first cut, and I've tried to keep the number of changes to the source code to a minimum. Should I carry on? -- Dimi. Index: dlls/msvcrt/msvcrt.h =================================================================== RCS file: /var/cvs/wine/dlls/msvcrt/msvcrt.h,v retrieving revision 1.25 diff -u -r1.25 msvcrt.h --- dlls/msvcrt/msvcrt.h 16 Mar 2004 19:17:11 -0000 1.25 +++ dlls/msvcrt/msvcrt.h 4 Jun 2004 23:05:05 -0000 @@ -28,8 +28,27 @@ #include "winerror.h" #include "winnls.h" -#include "msvcrt/string.h" -#include "msvcrt/eh.h" +typedef unsigned short MSVCRT_wchar_t; +typedef unsigned short MSVCRT_wint_t; +typedef unsigned short MSVCRT_wctype_t; +typedef unsigned short MSVCRT__ino_t; +typedef unsigned long MSVCRT__fsize_t; +typedef unsigned int MSVCRT_size_t; +typedef unsigned int MSVCRT__dev_t; +typedef int MSVCRT__off_t; +typedef long MSVCRT_clock_t; +typedef long MSVCRT_time_t; +typedef long MSVCRT_fpos_t; + +typedef void (*terminate_handler)(); +typedef void (*terminate_function)(); +typedef void (*unexpected_handler)(); +typedef void (*unexpected_function)(); +typedef void (*_se_translator_function)(unsigned int code, struct _EXCEPTION_POINTERS *info); +typedef void (*_beginthread_start_routine_t)(void *); +typedef unsigned int (__stdcall *_beginthreadex_start_routine_t)(void *); +typedef int (*MSVCRT__onexit_t)(void); + /* TLS data */ extern DWORD MSVCRT_tls_index; @@ -123,4 +142,363 @@ #define _RT_CRNL 252 #define _RT_BANNER 255 +struct MSVCRT_tm { + int tm_sec; + int tm_min; + int tm_hour; + int tm_mday; + int tm_mon; + int tm_year; + int tm_wday; + int tm_yday; + int tm_isdst; +}; + +struct _timeb +{ + MSVCRT_time_t time; + unsigned short millitm; + short timezone; + short dstflag; +}; + +typedef struct MSVCRT_iobuf +{ + char* _ptr; + int _cnt; + char* _base; + int _flag; + int _file; + int _charbuf; + int _bufsiz; + char* _tmpfname; +} MSVCRT_FILE; + +struct MSVCRT_lconv +{ + char* decimal_point; + char* thousands_sep; + char* grouping; + char* int_curr_symbol; + char* currency_symbol; + char* mon_decimal_point; + char* mon_thousands_sep; + char* mon_grouping; + char* positive_sign; + char* negative_sign; + char int_frac_digits; + char frac_digits; + char p_cs_precedes; + char p_sep_by_space; + char n_cs_precedes; + char n_sep_by_space; + char p_sign_posn; + char n_sign_posn; +}; + +struct MSVCRT__exception +{ + int type; + char *name; + double arg1; + double arg2; + double retval; +}; + +struct MSVCRT__complex +{ + double x; /* Real part */ + double y; /* Imaginary part */ +}; + +typedef struct _heapinfo +{ + int* _pentry; + MSVCRT_size_t _size; + int _useflag; +} _HEAPINFO; + +#ifdef __i386__ +typedef struct __JUMP_BUFFER +{ + unsigned long Ebp; + unsigned long Ebx; + unsigned long Edi; + unsigned long Esi; + unsigned long Esp; + unsigned long Eip; + unsigned long Registration; + unsigned long TryLevel; + /* Start of new struct members */ + unsigned long Cookie; + unsigned long UnwindFunc; + unsigned long UnwindData[6]; +} _JUMP_BUFFER; +#endif /* __i386__ */ + +struct MSVCRT__diskfree_t { + unsigned int total_clusters; + unsigned int avail_clusters; + unsigned int sectors_per_cluster; + unsigned int bytes_per_sector; +}; + +struct MSVCRT__finddata_t +{ + unsigned attrib; + MSVCRT_time_t time_create; + MSVCRT_time_t time_access; + MSVCRT_time_t time_write; + MSVCRT__fsize_t size; + char name[260]; +}; + +struct MSVCRT__finddatai64_t +{ + unsigned attrib; + MSVCRT_time_t time_create; + MSVCRT_time_t time_access; + MSVCRT_time_t time_write; + __int64 size; + char name[260]; +}; + +struct MSVCRT__wfinddata_t { + unsigned attrib; + MSVCRT_time_t time_create; + MSVCRT_time_t time_access; + MSVCRT_time_t time_write; + MSVCRT__fsize_t size; + MSVCRT_wchar_t name[260]; +}; + +struct MSVCRT__wfinddatai64_t { + unsigned attrib; + MSVCRT_time_t time_create; + MSVCRT_time_t time_access; + MSVCRT_time_t time_write; + __int64 size; + MSVCRT_wchar_t name[260]; +}; + +struct _utimbuf +{ + MSVCRT_time_t actime; + MSVCRT_time_t modtime; +}; + +/* for FreeBSD */ +#undef st_atime +#undef st_ctime +#undef st_mtime + +struct MSVCRT__stat { + MSVCRT__dev_t st_dev; + MSVCRT__ino_t st_ino; + unsigned short st_mode; + short st_nlink; + short st_uid; + short st_gid; + MSVCRT__dev_t st_rdev; + MSVCRT__off_t st_size; + MSVCRT_time_t st_atime; + MSVCRT_time_t st_mtime; + MSVCRT_time_t st_ctime; +}; + +struct MSVCRT_stat { + MSVCRT__dev_t st_dev; + MSVCRT__ino_t st_ino; + unsigned short st_mode; + short st_nlink; + short st_uid; + short st_gid; + MSVCRT__dev_t st_rdev; + MSVCRT__off_t st_size; + MSVCRT_time_t st_atime; + MSVCRT_time_t st_mtime; + MSVCRT_time_t st_ctime; +}; + +struct MSVCRT__stati64 { + MSVCRT__dev_t st_dev; + MSVCRT__ino_t st_ino; + unsigned short st_mode; + short st_nlink; + short st_uid; + short st_gid; + MSVCRT__dev_t st_rdev; + __int64 st_size; + MSVCRT_time_t st_atime; + MSVCRT_time_t st_mtime; + MSVCRT_time_t st_ctime; +}; + +#define MSVCRT_WEOF (MSVCRT_wint_t)(0xFFFF) +#define MSVCRT_EOF (-1) +#define MSVCRT_TMP_MAX 0x7fff +#define MSVCRT_BUFSIZ 512 + +#define MSVCRT_STDIN_FILENO 0 +#define MSVCRT_STDOUT_FILENO 1 +#define MSVCRT_STDERR_FILENO 2 + +/* more file._flag flags, but these conflict with Unix */ +#define MSVCRT__IOFBF 0x0000 +#define MSVCRT__IONBF 0x0004 +#define MSVCRT__IOLBF 0x0040 + +#define MSVCRT_FILENAME_MAX 260 +#define MSVCRT_stdin (MSVCRT__iob+MSVCRT_STDIN_FILENO) +#define MSVCRT_stdout (MSVCRT__iob+MSVCRT_STDOUT_FILENO) +#define MSVCRT_stderr (MSVCRT__iob+MSVCRT_STDERR_FILENO) + +#define _P_WAIT 0 +#define _P_NOWAIT 1 +#define _P_OVERLAY 2 +#define _P_NOWAITO 3 +#define _P_DETACH 4 + +#define MSVCRT_EPERM 1 +#define MSVCRT_ENOENT 2 +#define MSVCRT_ESRCH 3 +#define MSVCRT_EINTR 4 +#define MSVCRT_EIO 5 +#define MSVCRT_ENXIO 6 +#define MSVCRT_E2BIG 7 +#define MSVCRT_ENOEXEC 8 +#define MSVCRT_EBADF 9 +#define MSVCRT_ECHILD 10 +#define MSVCRT_EAGAIN 11 +#define MSVCRT_ENOMEM 12 +#define MSVCRT_EACCES 13 +#define MSVCRT_EFAULT 14 +#define MSVCRT_EBUSY 16 +#define MSVCRT_EEXIST 17 +#define MSVCRT_EXDEV 18 +#define MSVCRT_ENODEV 19 +#define MSVCRT_ENOTDIR 20 +#define MSVCRT_EISDIR 21 +#define MSVCRT_EINVAL 22 +#define MSVCRT_ENFILE 23 +#define MSVCRT_EMFILE 24 +#define MSVCRT_ENOTTY 25 +#define MSVCRT_EFBIG 27 +#define MSVCRT_ENOSPC 28 +#define MSVCRT_ESPIPE 29 +#define MSVCRT_EROFS 30 +#define MSVCRT_EMLINK 31 +#define MSVCRT_EPIPE 32 +#define MSVCRT_EDOM 33 +#define MSVCRT_ERANGE 34 +#define MSVCRT_EDEADLK 36 +#define MSVCRT_EDEADLOCK MSVCRT_EDEADLK +#define MSVCRT_ENAMETOOLONG 38 +#define MSVCRT_ENOLCK 39 +#define MSVCRT_ENOSYS 40 +#define MSVCRT_ENOTEMPTY 41 + +#define MSVCRT_LC_ALL 0 +#define MSVCRT_LC_COLLATE 1 +#define MSVCRT_LC_CTYPE 2 +#define MSVCRT_LC_MONETARY 3 +#define MSVCRT_LC_NUMERIC 4 +#define MSVCRT_LC_TIME 5 +#define MSVCRT_LC_MIN MSVCRT_LC_ALL +#define MSVCRT_LC_MAX MSVCRT_LC_TIME + +#define _HEAPEMPTY -1 +#define _HEAPOK -2 +#define _HEAPBADBEGIN -3 +#define _HEAPBADNODE -4 +#define _HEAPEND -5 +#define _HEAPBADPTR -6 + +#define _FREEENTRY 0 +#define _USEDENTRY 1 + +#define _OUT_TO_DEFAULT 0 +#define _REPORT_ERRMODE 3 + +/* ASCII char classification table - binary compatible */ +#define _UPPER 0x0001 /* C1_UPPER */ +#define _LOWER 0x0002 /* C1_LOWER */ +#define _DIGIT 0x0004 /* C1_DIGIT */ +#define _SPACE 0x0008 /* C1_SPACE */ +#define _PUNCT 0x0010 /* C1_PUNCT */ +#define _CONTROL 0x0020 /* C1_CNTRL */ +#define _BLANK 0x0040 /* C1_BLANK */ +#define _HEX 0x0080 /* C1_XDIGIT */ +#define _LEADBYTE 0x8000 +#define _ALPHA (0x0100|_UPPER|_LOWER) /* (C1_ALPHA|_UPPER|_LOWER) */ + +#define MSVCRT__IOREAD 0x0001 +#define MSVCRT__IOWRT 0x0002 +#define MSVCRT__IOMYBUF 0x0008 +#define MSVCRT__IOEOF 0x0010 +#define MSVCRT__IOERR 0x0020 +#define MSVCRT__IOSTRG 0x0040 +#define MSVCRT__IORW 0x0080 + +#define _S_IEXEC 0x0040 +#define _S_IWRITE 0x0080 +#define _S_IREAD 0x0100 +#define _S_IFIFO 0x1000 +#define _S_IFCHR 0x2000 +#define _S_IFDIR 0x4000 +#define _S_IFREG 0x8000 +#define _S_IFMT 0xF000 + +void MSVCRT_free(void*); +void* MSVCRT_malloc(MSVCRT_size_t); +void* MSVCRT_calloc(MSVCRT_size_t,MSVCRT_size_t); +void* MSVCRT_realloc(void*,MSVCRT_size_t); + +int MSVCRT_iswalpha(MSVCRT_wint_t); +int MSVCRT_iswspace(MSVCRT_wint_t); +int MSVCRT_iswdigit(MSVCRT_wint_t); +int MSVCRT_isleadbyte(int); + +int MSVCRT_fgetc(MSVCRT_FILE*); +int MSVCRT_ungetc(int,MSVCRT_FILE*); +MSVCRT_wint_t MSVCRT_fgetwc(MSVCRT_FILE*); +MSVCRT_wint_t MSVCRT_ungetwc(MSVCRT_wint_t,MSVCRT_FILE*); +void MSVCRT__exit(int); +void MSVCRT_abort(); +unsigned long* MSVCRT___doserrno(void); +int* MSVCRT__errno(void); +char* MSVCRT_getenv(const char*); +char* MSVCRT_setlocale(int,const char*); +int MSVCRT_fclose(MSVCRT_FILE*); +void MSVCRT_terminate(); +MSVCRT_FILE* MSVCRT__p__iob(void); +MSVCRT_time_t MSVCRT_time(MSVCRT_time_t*); + +MSVCRT_wchar_t* _wcsdup(const MSVCRT_wchar_t*); +MSVCRT_wchar_t*** __p__wenviron(void); + +int _write(int,const void*,unsigned int); +int _vsnwprintf(MSVCRT_wchar_t*,MSVCRT_size_t,const MSVCRT_wchar_t*,va_list); +void _splitpath(const char*,char*,char*,char*,char*); +int _ismbstrail(const unsigned char* start, const unsigned char* str); +int _spawnve(int,const char*,const char* const *,const char* const *); +void _searchenv(const char*,const char*,char*); +void _sleep(unsigned long); +int _getdrive(void); +int _futime(int,struct _utimbuf*); +char* _strdup(const char*); +char* _strlwr(char*); +char* _strupr(char*); +char* _strnset(char*,int,MSVCRT_size_t); +char* _strset(char*,int); +int _getch(void); +int _ungetch(int); +int _cputs(const char*); +int _cprintf(const char*,...); +int _snprintf(char*,MSVCRT_size_t,const char*,...); + +char*** __p__environ(void); +int* __p___mb_cur_max(void); +unsigned int* __p__fmode(void); + #endif /* __WINE_MSVCRT_H */

2 1

Re: FindClose crash fix.
by Mike Hearn June 13, 2004

June 13, 2004

On Sat, 2004-06-12 at 20:34 +0200, Rein Klazes wrote: > BTW. I thought Crossover Office supports this application? It does (well, not the NL version specifically ...) so I checked and the CrossOver version of FindClose is the same as the WineHQ version. I seem to recall some talk of double closing find handles, but I guess either we have a hack elsewhere, or for some reason the bug doesn't appear in the builds we support? thanks -mike

2 1

Windows are unmaxmized when closing other window
by Gerhard W. Gruber June 13, 2004

June 13, 2004

Some time ago I noticed a strange behviour in Agent. When the windows are maxmized and you close any other window (doesn't matter if it is a dialog or any other normal window) the remaining windows are unmaximized. They arr not minimized, but they are getting smaller. Don't know if this is the same for all types but it seems at least for multiple document windows it is true. I just downloaded the current CVS version and there this behaviour is also. -- Gerhard Gruber Maintainer of SoftICE for Linux - http://pice.sourceforge.net/ Fast application launcher - http://sourceforge.net/projects/launchmenu

3 3

[REGRESSION] Photoshop 7.0 works before wine-cvs-20040130 16:??:?? CST (bug #2017)
by Luca Capello June 13, 2004

June 13, 2004

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, as reported on bug #2017 [1], Adobe Photoshop 7.0 stops working after wine-20031212 (in the majority of cases). This happens on Debian unstable (where I am) as well as on other distro. As suggested by Tony Lambregts, I made a regression testing to find the patch that broke this. The problem is between cvs-20040130-165720 and cvs-20040130-165721. The 'cvs -d ...' command gives me updates for only 3 files: ===== U dlls/kernel/Makefile.in U dlls/kernel/actctx.c U dlls/kernel/kernel32.spec ===== so I think the problem should be in these files, am I right? If it's so, well, the patch that broke Photoshop 7.0 working is the following [2] - - Jon Griffiths <jon_p_griffiths(a)yahoo.com> Add stubs for the Activation Context API (XP+). Please fix this problem, now that you know the cause. Thx, bye, Gismo / Luca [1] http://bugs.winehq.org/show_bug.cgi?id=2017 [2] http://www.winehq.org/hypermail/wine-cvs/2004/01/0394.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFAu1FuVAp7Xm10JmkRAgWIAJ90THCdqfIu6/uLGyurqrLfNNWEkACeIAze ALi4ZeOtMTEEDp8ETWu4G4c= =/pZb -----END PGP SIGNATURE-----

6 25

A bug in symbol loading in winedbg
by Shachar Shemesh June 13, 2004

June 13, 2004

Hi all, Bug Report: If winedbg is asked to load an external PDB file, and that file does not match the executable being run, the debugger does not warn about it. Instead, bad things (tm) happen when actually trying to run the executable. Shachar

2 8

Re: Implement a --backtrace-all mode for winedbg
by Eric Pouech June 12, 2004

June 12, 2004

I'm not sure I understand the purpose of the --backtrace-all. There's no way you can ensure a complete synchro between all threads & processes to get a global picture of the whole system, so the option is likely not very useful (except for the threads which are in a wait operation), but you will miss some other information for that (ie an event (entering/leaving CS...) tracker tool would be better). More over, I don't like either adding options to winedbg. So, I'd prefer adding an option to actually process the commands from a file (or even a string from command line) would be better. And, finally, you leak the handle for the snapshot. A+

3 4

Re: [USER] 'Fix' SetWindowsHookEx
by Shachar Shemesh June 12, 2004

June 12, 2004

Lionel Ulmer wrote: >I have no idea if it's correct >though (as I do not know if what GetModuleHandle returns is really the same >thing as what SetWindowsHookEx expects as an HINSTANCE input). > > Yes, it is. It's just used to grab the procedure address to call when the hook is activated. >Index: dlls/user/hook.c >=================================================================== >RCS file: /home/wine/wine/dlls/user/hook.c,v >retrieving revision 1.12 >diff -u -r1.12 hook.c >--- dlls/user/hook.c 19 May 2004 03:22:55 -0000 1.12 >+++ dlls/user/hook.c 12 Jun 2004 15:27:01 -0000 >@@ -141,11 +141,15 @@ > else /* system-global hook */ > { > if (id == WH_KEYBOARD_LL || id == WH_MOUSE_LL) inst = 0; >- else if (!inst || !(len = GetModuleFileNameW( inst, module, MAX_PATH )) || len >= MAX_PATH) >- { >- SetLastError( ERROR_INVALID_PARAMETER ); >- return 0; >- } > > If you just remove the "!inst" test, does the game work? I think that would be simpler. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

1 0

Re: Investigating a crash at startup
by Filip Navara June 12, 2004

June 12, 2004

1 0

wingcc and -Wb option
by Jon Griffiths June 12, 2004

June 12, 2004

Hi, The -Wb argument to winegcc currently expects a comma separated list of arguments which it then splits up and passes to winebuild. This conflicts with the --ignore=x,y,z syntax of winebuilds ignore argument, since it also uses a comma to delimit the list to ignore. The easiest way to fix this is to change the delimiting character in either option, i.e.: winebuild: --ignore=x,y,z => --ignore=x;y;z winegcc: -Wb,--ignore=x,y,z,<opts> => -Wb;--ignore=x,y,z;<opts> Does anyone care which one it is? Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

2 2

(Still) problem on AMD64 with wine CVS
by Maurizio Monge June 12, 2004

June 12, 2004

Hello, i have retried to compile wine CVS on amd64 (gcc 3.4 with -m32, etc + kernel 2.6.4-rc2), where i was thinking the 0xc0000000 problem was solved. but i get: wine: failed to initialize: /opt/wine/lib/wine/ntdll.dll.so: failed to map segment from shared object: Cannot allocate memory attach to this mail the output of "strace32 wine" one of the last lines is (i have 512Mb of ram) old_mmap(NULL, 482376, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = -1 ENOMEM (Cannot allocate memory) It looks like my kernel absolutly wants to allocate memory > 0xc0000000 :-) Any idea? Thanx Maurizio Please CC answers to monge(at)sns(dot)it, since i'm not subscribed.

4 5

Game Testing Update - 20040505
by Mike Kost June 12, 2004

June 12, 2004

Here a continuation of my game testing efforts. Same rules still apply in my efforts: All games tested are freely available as demos or F/OSS games on the Internet and they don't work right. I know 20040505 is showing its age, but there isn't a 200406xx yet. Since my last report: - Bugzlla bugs #2128 & #2129 have closed. The problems were self-correcting - 2 More Bugs Filed - - #2276 - Screen refresh/redraw errors in Austerlitz demo - - #2277 - Redraw/refresh errors for Remote Assault demo - Stopped testing The War Engine. I don't want to juggle more than 4 programs at a time and I want to pick up Galactic Civilization. Austerlitz Summary ------------------ Bug #2276 is newly filed and the unhandled exception error is no longer present. There is still a screen redraw error Full report: http://www.tashcorp.net/Wine/Austerlitz/austerlitz-20040505.html Dominions II ------------ No noticable change. Dominions II still has screen redraw errors and mouse errors. Full report: http://www.tashcorp.net/Wine/DominionsII/dominionsII-20040505.html Remote Assault -------------- Remote Assault has started running but has several refresh/redraw errors. There are several new 'err:ddraw' messages: err:ddraw:set_render_state Unhandled dwRenderStateType ... and err:ddraw:Main_DirectDrawSurface_Lock Invalid values in LPRECT !!! Full report: http://www.tashcorp.net/Wine/RemoteAssault/remoteassault-20040505.html

1 0

Winrash update
by Chris Morgan June 11, 2004

June 11, 2004

Just released a new version of winrash. I'm sending this email because after asking people who are running Winrash to send an email to the list or myself , I didn't receive any emails. This isn't usually a problem except when there is an issue with Winrash. I get error reports that have the IDs people put in but no way to contact them. So I added a field in the installer for a contact email. This will be sent along with the clientID when an error report is generated by winrash. In case anyone is curious the web archive for the error reports is here: http://www.winehq.org/hypermail/wine-tests-results/ I'd like to ask that anyone who installed winrash please run the installer again so they can enter a valid contact email. If you are one of those people wondering why your results aren't found at http://test.winehq.org/data/ this will help both of us by letting me get a hold of you ;-) The one change I should mention is the addition of proxy support in the 0008 release. There are a handful of people running behind proxies, I can tell by squid html in what should be the script part of the error reports. This version of the client *should* fix things for you. Thanks to Florian Steinel for the code change. Here is the SF link to the latest client: http://osdn.dl.sourceforge.net/sourceforge/winrash/winrash-0008-chris-msvc.… Thanks to anyone running the testing suite and for the feedback on winrash changes, I appreciate it. Thanks, Chris

2 2