wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Re: revised winmm GetDevCaps better pointer check patch
by Alexandre Julliard 14 Jun '04

14 Jun '04

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 14 Jun '04

14 Jun '04

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 14 Jun '04

14 Jun '04

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 14 Jun '04

14 Jun '04

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 14 Jun '04

14 Jun '04

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 14 Jun '04

14 Jun '04

> 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 14 Jun '04

14 Jun '04

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 14 Jun '04

14 Jun '04

1 0

Forum notify
by Johane 14 Jun '04

14 Jun '04

1 0

Re: Yahoo!
by Twickline 14 Jun '04

14 Jun '04

1 0

Versioning and internal APIs
by Mike Hearn 13 Jun '04

13 Jun '04

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 13 Jun '04

13 Jun '04

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 13 Jun '04

13 Jun '04

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 13 Jun '04

13 Jun '04

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 13 Jun '04

13 Jun '04

-----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 13 Jun '04

13 Jun '04

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 12 Jun '04

12 Jun '04

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 12 Jun '04

12 Jun '04

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 12 Jun '04

12 Jun '04

1 0

wingcc and -Wb option
by Jon Griffiths 12 Jun '04

12 Jun '04

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 12 Jun '04

12 Jun '04

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 12 Jun '04

12 Jun '04

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 11 Jun '04

11 Jun '04

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

Re: wine-devel -- confirmation of subscription -- request 127551
by root 11 Jun '04

11 Jun '04

confirm 127551

1 0

RE: How to determine if an application is running in Wine environ ment?
by Ivan 11 Jun '04

11 Jun '04

> It would be trivial for MS to say, "Thank you for > buying Microsift WOW! 2006, you are not authorized to > copy the program from the CD-ROM to a WINE environment > and doing so will constitute a violation of copyright, > punishable by a maximum term of five years in prison > and a $250,000 fine. Click here to exit the install > program" They can't do that, it would be an illegal violation of anti-trust laws. If they could have done it, you probably couldn't run office on crossover. Ivan.

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