wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Latest iteration of the systray patch
by Mike Hearn 15 Jun '04

15 Jun '04

This version is resynced against CVS HEAD, and now does a ShowWindow in the right place (just after the embed notification not in some random WM message). This won't be merged so I'm sending it to wine-devel not wine-patches. Getting it merged is blocking on either somebody giving me example code for [un]marshaling an HICON into a block of memory or (best fix) images being moved into the wineserver. This is on Ulrichs todo list but if anybody wants to beat him to it, go ahead, it's still some time off yet. thanks -mike

1 0

Re: Incoming Message
by Twickline 15 Jun '04

15 Jun '04

1 0

(no subject)
by Gerald Pfeifer 15 Jun '04

15 Jun '04

The following patch to dlls/shell32/shlexec.c revision 1.50 date: 2004/06/15 00:44:14; author: julliard; state: Exp; lines: +11 -3 Dmitry Timoshkov <dmitry(a)codeweavers.com> Restore default "open" functionality of ShellExecute. introduced the following warning regressions: shlexec.c:722: warning: format argument is not a pointer (arg 11) shlexec.c:722: warning: format argument is not a pointer (arg 12) Would you mind fixing this? Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

1 0

Re: Incoming Message
by Twickline 15 Jun '04

15 Jun '04

1 0

Re: Yahoo!
by Johane 15 Jun '04

15 Jun '04

1 0

Do we still need wineinstall?
by Mike Hearn 15 Jun '04

15 Jun '04

Hi, I've been running without a config file for a while now, and have fixed various misc bugs related to that as I go - I'm sure there are some more in there, but as the config file is destined for eventual doom anyway I am wondering if we still need wineinstall at all? Currently, it's possible to use Wine quite succesfully just by doing a standard ./configure, make, make install. When you run wine for the first time wineprefixcreate will be used to setup ~/.wine, merge the registry, create the fake windows drive and so on. The only piece you don't get is the default config file, but that doesn't seem to make much difference any more. At least, the defaults should be in the code not the config file as people never upgrade that bit anyway :) So - do we still need it?

2 1

Re: winetest: move to resources (take n) (resend)
by Alexandre Julliard 14 Jun '04

14 Jun '04

Ferenc Wagner <wferi(a)afavant.elte.hu> writes: > This is a resend to elicit some feedback on your objections > against this patch. What did I miss again? It's much better this time. The only thing I would suggest changing is that the build info text formatting should be done in the code, not in the makefile. Also I think it would be cleaner to use a different rc file for the dist case instead of using #ifdefs. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Create DIALOGINFO On Demand When Calling DIALOG_get_info
by Alexandre Julliard 14 Jun '04

14 Jun '04

Robert Shearman <R.J.Shearman(a)warwick.ac.uk> writes: > This patch fixes bug 2210: > http://bugs.winehq.org/show_bug.cgi?id=2210 > This patch differs slightly from the one posted to wine-devel, as it > includes some checks for NULL return from DIALOG_get_info. I don't think you want to create the dialog info in all cases, this should only be done where we are sure we have a dialog window. For instance you don't want MapDialogRect to add dialog info to arbitrary windows just because it got passed a wrong handle. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wine/include ddeml.h
by andrejoh＠c2i.net 14 Jun '04

14 Jun '04

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

14 Jun '04

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

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