- wine-devel - winehq.org

Which is correct? listview or treeview?
by Bill Medland 21 Nov '01

21 Nov '01

With regard to my problem that I was getting infinite redraws in my listview following Alexandre's change to server/user/message.c: I eventually tracked it down to the fact our code used SetRedraw(FALSE)/SetRedraw(TRUE) on a list control. (So the bug can now be demonstrated easily on e.g. the MFC RowList sample with a two-line change). Now I see that in the case of LISTVIEW_SetRedraw DefWindowProc is called and then RedrawWindow. In the TREEVIEW_SetRedraw case it simply sets a flag within the … [View More]

1 0

New level of Shlwapi (parts 1 & 2)
by Guy L. Albertelli 21 Nov '01

21 Nov '01

Most of the shlwapi upgrades have been driven by my desire to be able to run Outlook Express under Wine. (I know that there are other mail packages, but the rest of the home uses Windows - anyway it is a great test vehicle, uses everything ever implemented). The current status is as follows: With V4 or IE and OE - with builtin shlwapi,commctrl,comctl32 . IE displays page, can even do www.cnn.com, even runs javascript. + Certain menu popups either fail to display, or bomb. … [View More]

1 0

Re: Improving DIB support for SHM
by Gavriel State 21 Nov '01

21 Nov '01

Doh! I guess we've been too lax about integrating some of our non D3D work back into WineHQ. We did this in WineX some time ago, but with a couple of differences: 1) We don't restrict using XShmGetImage to the whole-screen case and 2) We save and restore the XImage mask fields around the call to XShmGetImage, which seems to like to write over those fields to no useful purpose. IE: /* We must save and restore the bmpImage's masks in order * to preserve them … [View More]across the call to XShmGetImage, which * decides to eliminate them since it doesn't happen to know * what the format of the image is supposed to be, even though * we do. */ saveRed = bmpImage->red_mask; saveBlue= bmpImage->blue_mask; saveGreen = bmpImage->green_mask; XShmGetImage( gdi_display, descr->drawable, bmpImage, descr->xSrc, descr->ySrc, AllPlanes); bmpImage->red_mask = saveRed; bmpImage->blue_mask = saveBlue; bmpImage->green_mask = saveGreen; We'll probably get around to doing some merging back into WineHQ after our next release. -Gav Jukka Heinonen wrote: > > The following patch halves the time it takes to move units > from one square to another in Civilization 2. If SHM is supported, > the patch uses XShmGetImage instead of XGetSubImage when filling > the whole XImage (which is probably way too careful since SHM is > much faster than the alternative...). Hopefully this > version is paranoid enough to work with older XFree86 servers > where XShmGetImage might change the underlying XImage format > into XYPixmap. > > Changelog: > Try to use XShmGetImage instead of XGetSubImage if SHM is supported. > Do a sanity check before using XShmPutImage. > > Index: wine/graphics/x11drv/dib.c > =================================================================== > RCS file: /home/wine/wine/graphics/x11drv/dib.c,v > retrieving revision 1.82 > diff -u -r1.82 dib.c > --- wine/graphics/x11drv/dib.c 2001/11/05 23:52:18 1.82 > +++ wine/graphics/x11drv/dib.c 2001/11/21 12:39:42 > @@ -4473,7 +4473,7 @@ > descr->xSrc, descr->ySrc, descr->xDest, descr->yDest, > descr->width, descr->height); > #ifdef HAVE_LIBXXSHM > - if (descr->useShm) > + if (descr->useShm && descr->image) > { > XShmPutImage( gdi_display, descr->drawable, descr->gc, bmpImage, > descr->xSrc, descr->ySrc, descr->xDest, descr->yDest, > @@ -4519,9 +4519,26 @@ > TRACE("XGetSubImage(%ld,%d,%d,%d,%d,%ld,%d,%p,%d,%d)\n", > descr->drawable, descr->xSrc, descr->ySrc, descr->width, > lines, AllPlanes, ZPixmap, bmpImage, descr->xDest, descr->yDest); > - XGetSubImage( gdi_display, descr->drawable, descr->xSrc, descr->ySrc, > - descr->width, lines, AllPlanes, ZPixmap, > - bmpImage, descr->xDest, descr->yDest ); > + > +#ifdef HAVE_LIBXXSHM > + if (descr->useShm && descr->image && > + descr->xDest == 0 && descr->yDest == 0 && > + descr->width == bmpImage->width && > + lines == bmpImage->height && > + XShmPixmapFormat( gdi_display ) == ZPixmap) > + { > + XShmGetImage( gdi_display, descr->drawable, bmpImage, > + descr->xSrc, descr->ySrc, AllPlanes ); > + if (bmpImage->format != ZPixmap) > + ERR( "XShmGetImage changed image format!\n" ); > + } > + else > +#endif > + { > + XGetSubImage( gdi_display, descr->drawable, descr->xSrc, descr->ySrc, > + descr->width, lines, AllPlanes, ZPixmap, > + bmpImage, descr->xDest, descr->yDest ); > + } > > TRACE("Dib: depth=%2d r=%lx g=%lx b=%lx\n", > descr->infoBpp,descr->rMask,descr->gMask,descr->bMask); > > -- > Jukka Heinonen <http://www.iki.fi/jhei/> -- Gavriel State, CEO TransGaming Technologies Inc. http://www.transgaming.com gav(a)transgaming.com [View Less]

1 0

cleaning up pthreads implementation - ABI problem
by Peter Hunnisett 21 Nov '01

21 Nov '01

Howdy, I was just looking at cleaning up the pthreads implementation but I don't think that it's possible to have our pthreads implementation without providing binary compatibility with the pthread implementation we're hijacking. The reason is that the mutex and rwlock objects are supposed to be opaque to the programmer but in fact they are not opaque to the compiler. According to the standard, one doesn't have to call pthread_{mutex,rwlock}_init before using a {mutex,rwlock} as would be … [View More]required with a totally opaque type. The standard allows for static initialization of the mutex and rwlock using PTHREAD_{MUTEX,RWLOCK}_INITIALIZER if you don't want any special attributes. libc does just this with its rwlock for gettext's global data. If you look at the ream of FIXME:pthread_rwlock_{rd,un}lock that sometimes come out starting wine you'll see that there's no call to pthread_rwlock_init. Of course, this stuff is safe because there's generally no writers wanting the pthread_rwlock_wrlock. So our current pthreads mutex implementation works in Linux by the skin of its teeth, becuase the first field in the mutex is reserved and initialized to 0 (in both the static and pthread_mutex_init cases), provided the version of LinuxThreads is new enough and a pointer is the same size as an int. Now I assume that this would mean it fails curiously for things that don't use LinuxThreads. This would also seem to mean, since we need binary compatibility, that things could even fail if someone upgrades their libc :( BTW, our check is presently basically only on __GLIBC__. Flavour me ignorant, and lazy, but I would assume that this not a Linux only symbol. So in fact the wine pthreads implementation might be already used incorrectly. Reader/Writer locks can be made to work the same way, as the mutex, since there are several fields which are initialized to NULL and we can then HeapAlloc our own structure off that field. We can then come up with weird and wonderful exceptions for the wonky cases that are sure to exist in some implementation of pthreads. Can anyone see a nice way out of this that I'm remaining ignorant to? I can't even think of a runtime way of detecting if our implementation is going to work. All in all I'm not too enthusiatic about the potential maintenance nightmare that this may provide but it would seem the only way is to have different mutex and rwlock structures depending on the pthreads implementation we're hijacking. Some code if people are more interested in details: >From glibc 2.2.4 /* Mutexes (not abstract because of PTHREAD_MUTEX_INITIALIZER). */ /* (The layout is unnatural to maintain binary compatibility with earlier releases of LinuxThreads.) */ typedef struct { int __m_reserved; /* Reserved for future use */ int __m_count; /* Depth of recursive locking */ _pthread_descr __m_owner; /* Owner thread (if recursive or errcheck) */ int __m_kind; /* Mutex kind: fast, recursive or errcheck */ struct _pthread_fastlock __m_lock; /* Underlying fast lock */ } pthread_mutex_t; #define PTHREAD_MUTEX_INITIALIZER \ {0, 0, 0, PTHREAD_MUTEX_TIMED_NP, __LOCK_INITIALIZER} What WINE uses (scheduler/pthread.c): /* assume that pthread_mutex_t has room for at least one pointer, * and hope that the users of pthread_mutex_t considers it opaque * (never checks what's in it) */ typedef struct { CRITICAL_SECTION *critsect; } *wine_mutex; rwlocks on the other hand are not so lucky as there's no unused bits: >From glibc-2.2.4 /* Read-write locks. */ typedef struct _pthread_rwlock_t { struct _pthread_fastlock __rw_lock; /* Lock to guarantee mutual exclusion */ int __rw_readers; /* Number of readers */ _pthread_descr __rw_writer; /* Identity of writer, or NULL if none */ _pthread_descr __rw_read_waiting; /* Threads waiting for reading */ _pthread_descr __rw_write_waiting; /* Threads waiting for writing */ int __rw_kind; /* Reader/Writer preference selection */ int __rw_pshared; /* Shared between processes or not */ } pthread_rwlock_t; # define PTHREAD_RWLOCK_INITIALIZER \ { __LOCK_INITIALIZER, 0, NULL, NULL, NULL, \ PTHREAD_RWLOCK_DEFAULT_NP, PTHREAD_PROCESS_PRIVATE } Ciao, Peter hunnise(a)yahoo.com __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 [View Less]

2 1

Re: _dev_t for MSVCRT
by Marcus Meissner 21 Nov '01

21 Nov '01

On Tue, Nov 20, 2001 at 10:16:14PM +0100, Uwe Bonnes wrote: > Changelog: > include/msvcrt/sys/types: > _dev_t in a unsigned integer > -- > Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de > > Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- > Index: wine/include/msvcrt/sys/types.h > =================================================================== > RCS … [View More]

1 1

Re: (no subject) (msvcrt.getenv)
by Francois Gouget 20 Nov '01

20 Nov '01

On Tue, 20 Nov 2001, Uwe Bonnes wrote: > > Changelog: > dlls/msvcrt/environ.c: MSVCRT_getenv > Compare for the length of the key and return NULL in case of failure Good catch. Another thing to keep in mind: IIRC environment strings are not case sensitive on Windows. This means that normally getenv("PATH")==getenv("path") and that putenv("Path") would overwrite that same environment variable... This does not appear to be the case in the current code. -- Francois … [View More]

1 0

winsock2.h
by lawson_whitney＠juno.com 20 Nov '01

20 Nov '01

Good day! To try debugging techniques for winelib apps, I had in mind to make a winelib app with an intentional segment fault, and found that _my_ winelib app will no longer compile. (gcc-2.95.3, glibc-2.2.3, current wine CVS). Please, it needs unistd.h so it can comfortably log to syslog. running winemaker on it again didn't help. checking for wrc... /usr/local/bin/wrc updating cache ./config.cache creating ./config.status creating Make.rules creating Makefile creating launcher Configure … [View More]

2 4

Civilization2 segment register troubles
by Jukka Heinonen 20 Nov '01

20 Nov '01

Hi. I noticed that Civilization 2 has several problems under Wine. First, the game wants to access memory using segment register value zero, which causes protection exception since that is not allowed in protected mode. Second problem is that the game uses segment register value 0xf8, which Wine does not like. If I drop null-pointer protection [call to DOSMEM_Init(TRUE)], emulate cmp and mov commands so that they work even if using segment register value zero [added stuff to memory/instr.c] … [View More]

2 2

Re: Patches for FreeBSD 5.x compilation
by Alexandre Julliard 20 Nov '01

20 Nov '01

Steve Kargl <sgk(a)troutmask.apl.washington.edu> writes: > What I questioned was the criticism that FreeBSD was guilty > of namespace pollution. Alexandre isn't the only wine > developer who made this statement (check usenet). The header > files in question are implementation dependent and can > contain any variable name or #define or typedef. The fact is > that both wine and FreeBSD have struct thread in implementation > header files. AFAICT, neither is … [View More]

1 0

Re: LibaudioIO Patch for Solaris
by eric pouech 20 Nov '01

20 Nov '01

Robert Lunnon wrote: > > Attached find files for libaudioio patch for audio on solaris 7 > > winmm.diff - Only the makefile patch is significant wavemap, just contains > some extra debugging traces > > libaudioio.tar, libaudioio goes under winmm > > base.diff, Patches to configure.in and Makefile.in to better support Solaris > and Libaudioio > > config.h.in added HAVE_SOLARIS and HAVE_LIBAUDIOIO and added a way for force > a 32 bit mmap. a few … [View More]

1 0

Re: Patches for FreeBSD 5.x compilation
by Alexandre Julliard 20 Nov '01

20 Nov '01

Steve Kargl <sgk(a)troutmask.apl.washington.edu> writes: > Can you please explain how this is namespace pollution on the > part of the OS? AFAIK, <sys/user.h> is not specified by any > Standard (ISO C89, C90, or C99). <sys/user.h> can include > any (unprotected) variable name. Yes of course it can, but the fact that this isn't explicitly forbidden by some standard doesn't mean it's good practice or that it doesn't pollute the namespace. sys/user.h is also … [View More]

4 4

interesting comment about WINE from MS
by Igor 20 Nov '01

20 Nov '01

As far as WINE and Mono are concerned, I'm just not sure whether these organizations will end up being able to produce satisfactory products. The real problem is this: it is not good enough for WINE to run some Windows apps. If the general public is going to consume it, it must run all Windows apps. Windows 2000/XP has a significant level of POSIX compliancy, but many developers just don?t write their apps with these standards in mind. You'll find pieces of code everywhere in third party apps … [View More]

1 0

Implementation of TB_REPLACEBITMAP
by Marco Bizzarri 20 Nov '01

20 Nov '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. I'm trying to provide an implementation of TB_REPLACEBITMAP Included is the patch I've done to record the bitmaps which are provided to the toolbar and to replace them when the message arrives. Even though the number of buttons displayed is correct, the output is otherwise garbled. I would appreciate any suggestion on this topic. The platform is a RH Linux 6.2. wine is from CVS (20/11/2001) - -- Marco Bizzarri - Responsabile Tecnico … [View More]

1 0

audio.c fault reproduction
by Simon Britnell 20 Nov '01

20 Nov '01

I downloaded and ran the QuickTime installer and the Pajama Sam demo last PM. I have reproduced the problem with Pajama Sam (it seems that ends of samples are either not playing or being overwritten), but I can't get QuickTimePlayer.exe to do anything at all. I'll investigate the Pajama Sam problems over the remainder of the week. __________________________________________________ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1

2 1

RE: MIDL and COM
by Patrik Stridvall 20 Nov '01

20 Nov '01

> On 16 Nov 2001, Alexandre Julliard wrote: > > > Ove Kaaven <ovehk(a)ping.uio.no> writes: > > > > > But can the machine-generated sources that MIDL outputs > be put into the > > > official Wine source? > > > > I'd prefer not. If we want to use .idl files we'll have to come up > > with our own compiler, and then we can put the .idl source > in the tree > > and compile it at build time. > > Hmm. Even when using … [View More]flex and bison, it sounds like a fair amount of > work... wonder who would volunteer? There already are a multitude of open souce (GPL and otherwise) CORBA .idl compilers. Of course Wine have probably slightly different requirements but I should guess that we could save 90% of the work compared to writing it from scratch. Alexandre: Is a GPL:ed (or possible different licenced) .idl compiler acceptable? > > > And how about source IDL files? Can we put into Wine IDL > extracted from > > > real Windoze .tlb files with a tool like oleview.exe, or > IDL parsed from > > > MIDL-generated Windows SDK .h files, like objidl.h, with a script? > > > > No, anything generated from a Windows file is copyrighted by > > Microsoft, so we cannot distribute it. We need to rewrite > these files > > from scratch, just like we do for the normal headers. > > Now where are all the usual non-lawyers on this list who > would argue that > API definitions, like prototypes in header files (which of > course IDL, as > a formalized API spec format, is all about), cannot be copyrighted? > Oh well... I'm here. :-) Well, I wouldn't really go quite that far. The API definitions in themselves can't be copyrighted, true. But a specific way of expressing them is, so compiling any Microsoft file will generate create a derived work copyrighted by Microsoft as the main rule. However it is not quite that easy, since only the specific expression is protected, the compilation result is only a derived work if it still contains any protected expression. In light of this you could argue that since, I presume, MIDL removes whitespace and commments which is IIRC the only really expression, since the rest the API defintions are just facts, that the MIDL compiled files just contains facts not any part of the protected expression. However that is a little thin line to walk, since there is quite of lack of real cases in the area, so I would recommend that we do as Alexandre suggest. Beside having the real .idl files in the Wine tree might be useful for other things as well. [View Less]

1 0

Re: MIDL and COM
by Alexandre Julliard 20 Nov '01

20 Nov '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > Problem 1: MIDL-generated code. > midl.exe is Microsoft's IDL compiler, it reads .idl files which describe > RPC and COM interface, from which it generates .c files, .h files, and > typelibs. (It is possible to find copies of midl.exe floating on the net, > as some people have put together "COM kits" for Borland C++ that contains > midl.exe and some standard .idl files and put them on the web) > > But can the machine-… [View More]

2 1

audio.c regression on Nov. 10th
by Ori Pessach 19 Nov '01

19 Nov '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Despite my previous report on this, something did break in audio.c between November 9th and November 10th. I checked out a version from 11/09/2001, and it works. I updated just audio.c with -D 11/10/2001, and Humongous Entertainment games don't recognize the sound card anymore. There have been substantial changes to audio.c during those 24 hours - enough to confuse diff, as a matter of fact. I'll look into it, but I wanted to report … [View More]

2 1

Re: Patches for FreeBSD 5.x compilation
by Alexandre Julliard 19 Nov '01

19 Nov '01

Francois Gouget <fgouget(a)free.fr> writes: > I guess that one day Alexandre is going to argue that Linux should > stop polluting the namespace with 'struct user'... Well, struct user is the only reason for including sys/user.h, so I guess it can be considered acceptable; but anything else defined in there (like struct user_regs_struct on Linux) is namespace pollution too IMO. And if there comes a day when the server is managing users, the corresponding struct will definitely … [View More]

2 1

Re: Patches for FreeBSD 5.x compilation
by Alexandre Julliard 19 Nov '01

19 Nov '01

Steve Kargl <sgk(a)troutmask.apl.washington.edu> writes: > FreeBSD isn't polluting the namespace. <sys/user.h> is a > a non-standard header file. It's still made available to applications, and there is really no reason for exporting internal kernel names this way. At least it could be renamed or put inside #ifdef _KERNEL. The alternative is of course to avoid sys/user.h, or play with #defines on the Wine side; but prefixing our structures with wine_ is not a solution. -- Alexandre Julliard julliard(a)winehq.com

4 4

Re: Fix to audio.c 1.46 loop problem + choppy sound
by Michael Stefaniuc 19 Nov '01

19 Nov '01

On Fri, Nov 16, 2001 at 07:59:20PM -0800, Simon Britnell wrote: > This patch should fix a loop playing failure reported > by Eric and a problem with choppy sound I experienced > playing total annihilation Hmm ... this patch horrible breaks the sound in Quicktime. The sound is now (audio.c 1.47) practicaly nonexistand: every 5-7 seconds you hear something for about 1/2 seconds. Before that (audio.c 1.45,1.46) the sound was choppy and played at 4/5 of the normal speed whereas with audio.… [View More]

1 0

Re: Patches for FreeBSD 5.x compilation
by Alexandre Julliard 19 Nov '01

19 Nov '01

Francois Gouget <fgouget(a)free.fr> writes: > Renaming struct thread it the right thing to do though. Why > doesn't changing thread to wine_thread in request.h work? No, the right thing is to fix the FreeBSD headers to stop polluting the namespace. struct thread is a perfectly valid identifier for an application to use (and we are certainly not the only application using it). -- Alexandre Julliard julliard(a)winehq.com

2 1

Kdevelop and Wine
by Chuck Fischer 19 Nov '01

19 Nov '01

Hello, I'm new to Linux, Kdevelop and Wine. I've been given the task of getting a Windows application to run on *nix. After some surfing I found KDevelop and Wine. I would like to use KDevelop to build my Windows app with WineLib. Can this be done? Has it been done? What do I need to do to get it to work? Also, are there any plans or thoughts about integrating WineLib with KDevelop? TIA, Chuck

2 1

Re: Build failure due to winsock.h changes, specifically htonl
by Gerald Pfeifer 19 Nov '01

19 Nov '01

On Thu, 15 Nov 2001, Francois Gouget wrote: > Yes. This one is actually simple to solve: do not include > 'winsock2.h'. AFAICT including 'winsock2.h' is not necessary since 1.66 > (2000/08/31) when get_socket_event and FD_MAX_EVENTS where removed. > I am working on the other compilation problems... I just performed a cvs update and now was able to again build Wine on FreeBSD 4.4 due to your latest changes. Thanks a lot! Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

1 0

readdir broken when called from wine
by Lionel Elie Mamane 19 Nov '01

19 Nov '01

Hi, After "upgrading" from Wine-20010418 to Wine-20011004 (self-compiled from tarballs), suddenly it didn't find my "C:\Windows" any more. Worked before, same 'puter, config files, etc (TM). Tried with CVS version. Nope. I recruited Andreas Mohr on #WineHQ for help, we ruled out the obvious (yes, the directory exists, here is my config file, no, I don't confuse root and non-root, ...), and got down to add traces and dug in the code. So, for some reason, the readdir calls from files/dos_fs.c:… [View More]DOSFS_ReadDir() report success (ie return non-NULL), but the directory entry name returned (dirent->d_name) is always the empty string (*(dirent->d_name)=='\0')! So I checked if readdir worked generally on my system, it does, this program does the expected thing: int main(void) {//Tst code DIR *mydir; struct dirent *entr; mydir = opendir("/"); while ((entr = readdir(mydir))) { TRACE("Dir_entry: %s\n", entr->d_name); } closedir(mydir); } I even went the extra mile and compiled it with exactly the same options (minus the various -I's) as dos_fc.c gets in wine, it works. Then, I added that code snippet (without the "int main(void)", obviously) to wine's main(). Worked. So I went down the stack of called functions, putting that same snippet in each function to see when it breaks: It works "up to" (or down to?) loader/main.c:MAIN_MainInit(). That function calls files/directory.c:DIR_Init(), and there, it doesn't work (ie name is always empty string) in DIR_Init(). After DIR_Init() returns, it still works in MAIN_MainInit(). I tried to find a difference between these files, but they get compiled with the same compile options, combined by "ld -r" along with other .o's in files/files.o, resp. loader/loader.o, and the two latter go in libntdll.so. What could be the difference that makes readdir "break"? I've put the test code snippet just before the call to DIR_Init in MAIN_MainInit, and just after variable declaration in DIR_Init, so it's not a function that DIR_Init calls that "breaks havoc". Well... We're lost there. No idea. Anyone of you? Anyway, here's some info on my system, just giving random info, I don't really know which one will be useful: Pentium III 500 / 440BX motherboard SuSE 6.4 distrib "base" with several self-compiled "add-ons", "upgrades", and some newer SuSE RPM's installed (from 7.0, 7.1 or 7.2). Along the latter (newer RPM than SuSE 6.4), the glibc... glibc-2.2-9 Linux 2.2.20 (Was using .19 when problem started) Soundblaster AWE32 3Com NIC (3C905B) Adaptec SCSI controller (AHA-3950U2) gcc 2.95.2 GNU ld 2.9.5 binutils-2.9.5.0.24-30 Err... What more??? Any additional info useful? Just ask. (except r00t password, "of course" ;-> ) Thank you for your time, -- Lionel Elie Mamane RFC 1991 (PGP 2.x) 2048 bits Key Fingerprint (KeyID: 20C897E9): 85CF 986F 263E 8CD0 80FD 4B8C F5F9 C17D OpenPGP DH/DSS 4096/1024 Key Fingerprint (KeyID: 3E7B4B73): 9DAD 3131 3ADA F50B D096 002A B1C4 7317 3E7B 4B73 [View Less]

3 3

Query on ActiveX components support from Wine.
by Ganesh.S 19 Nov '01

19 Nov '01

Hi, Is it possible to run an application that uses MSGrid ActiveX component and other database related components. My application was developed in VB6.0 which uses Microsoft Access in the backend. When I run the application the datas are not comming. Also few of the screens are not coming up saying that can't load the ActiveX component and the application gets killed. Is there any patch or solution for this. Can you suggest me the solution for this. thanks in advance, with regards, Ganesh.S … [View More]

1 0

Re: misc. code fixes
by Alexandre Julliard 19 Nov '01

19 Nov '01

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > - make listbox.c use reasonable bounds checking That's a completely gratuitous change, it makes absolutely no difference to the code. If you like your way better you are free to use it on your own code; but please don't go around "fixing" other people's code like this. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: Patches for FreeBSD 5.x compilation
by Francois Gouget 19 Nov '01

19 Nov '01

On Sun, 18 Nov 2001, Steve Kargl wrote: > The following patches are required to compile > the latest wine sources on FreeBSD 5.x. Note, I have a patch that I think should fix this compilation problem. I sent it on the 15th but it got loast without a trace so I resent it today (search for 'Solaris and FreeBSD compilation fixes (fwd)'). > Index: wine/dlls/wsock32/socket.c > =================================================================== > RCS file: /home/wine/wine/dlls/… [View More]wsock32/socket.c,v > retrieving revision 1.16 > diff -u -r1.16 socket.c > --- wine/dlls/wsock32/socket.c 2001/11/14 21:26:23 1.16 > +++ wine/dlls/wsock32/socket.c 2001/11/18 18:42:14 > @@ -42,6 +42,7 @@ > #include <stdio.h> > #include <stdlib.h> > #include <unistd.h> > +#include <sys/socket.h> > #ifdef HAVE_SYS_SOCKIO_H > # include <sys/sockio.h> > #endif This should have a #ifdef HAVE_SYS_SOCKET_H around it. See my patch. > Index: wine/include/winsock.h > =================================================================== > RCS file: /home/wine/wine/include/winsock.h,v > retrieving revision 1.37 > diff -u -r1.37 winsock.h > --- wine/include/winsock.h 2001/11/14 21:26:24 1.37 > +++ wine/include/winsock.h 2001/11/18 18:42:17 > @@ -894,14 +894,10 @@ > struct WS(servent)* WINAPI WS(getservbyport)(int,const char*); > int WINAPI WS(getsockname)(SOCKET,struct WS(sockaddr)*,int*); > int WINAPI WS(getsockopt)(SOCKET,int,int,char*,int*); > -u_long WINAPI WS(htonl)(u_long); > -u_short WINAPI WS(htons)(u_short); > unsigned long WINAPI WS(inet_addr)(const char*); > char* WINAPI WS(inet_ntoa)(struct WS(in_addr)); > int WINAPI WS(ioctlsocket)(SOCKET,long,u_long*); > int WINAPI WS(listen)(SOCKET,int); > -u_long WINAPI WS(ntohl)(u_long); > -u_short WINAPI WS(ntohs)(u_short); > int WINAPI WS(recv)(SOCKET,char*,int,int); > int WINAPI WS(recvfrom)(SOCKET,char*,int,int,struct WS(sockaddr)*,int*); > int WINAPI WS(send)(SOCKET,const char*,int,int); This will break Winelib. I guess this was to fix the compilation errors in 'server/trace.c'. In that case I think a better solution is to not include 'winsock2.h' at all in server/trace.c since it appears to no longer be needed. > Index: wine/server/context_i386.c > =================================================================== > RCS file: /home/wine/wine/server/context_i386.c,v > retrieving revision 1.18 > diff -u -r1.18 context_i386.c > --- wine/server/context_i386.c 2001/07/11 17:30:59 1.18 > +++ wine/server/context_i386.c 2001/11/18 18:42:55 > @@ -20,9 +20,6 @@ > #ifdef HAVE_SYS_PARAM_H > # include <sys/param.h> > #endif > -#ifdef HAVE_SYS_USER_H > -# include <sys/user.h> > -#endif What is the problem with 'sys/user.h' ? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager. [View Less]

2 2

Re: Excessive redraw in Lotus Notes with Wine 20011108
by Glenn Schrader 19 Nov '01

19 Nov '01

Toby Haynes wrote: >I've just compiled up Wine 20011108 and given it a little testing. QuickTime >installer works fine and QuickTime player comes up, although it wants to be >fullscreen most of the time (something to do with strange mouse click handling >I think). SameTime installer runs (at least for version 1.5) although I can't >get the actual program to start (Unhandled exception). > >Lotus Notes 5.0.4 also appears to run fine with this build (I couldn't reply to >… [View More]messages with the October WINE release) but there is one headache-inducing >problem. When composing a message or editing a document, the screen redraws for >every letter. It does this pretty quickly but the effect is that the screen >flashes as I type. It's bad enough that I type with my eyes closed to avoid >looking at the screen and edit any mistakes I make at the end. It's not a >problem at other times such as reading messages or browsing databases - only >editing seems to suffer from this. > >Setting double-buffer visuals doesn't seem to help. Managed or desktop >configurations both suffer from this. > >Does anyone have any clues as to settings to tweak to minimise/stop this >happening? I'd rather not go back to 20010326 (my stable backup build) but I >will if I can't solve this problem. > >Thanks, >Toby Haynes > I have been having a similar problem with a different app. Try the attached patch and see if it helps. --- Glenn Schrader Index: painting.c =================================================================== RCS file: /home/wine/wine/windows/painting.c,v retrieving revision 1.61 diff -u -r1.61 painting.c --- painting.c 2001/10/16 21:58:59 1.61 +++ painting.c 2001/11/18 22:48:09 @@ -345,23 +345,12 @@ TRACE("hrgnUpdate = %04x, \n", hrgnUpdate); - if (GetClassLongA( hwnd, GCL_STYLE ) & CS_PARENTDC) - { - /* Don't clip the output to the update region for CS_PARENTDC window */ - if( hrgnUpdate ) - DeleteObject(hrgnUpdate); - lps->hdc = GetDCEx( hwnd, 0, DCX_WINDOWPAINT | DCX_USESTYLE | - (bIcon ? DCX_WINDOW : 0) ); - } - else - { - if( hrgnUpdate ) /* convert to client coordinates */ - OffsetRgn( hrgnUpdate, wndPtr->rectWindow.left - wndPtr->rectClient.left, - wndPtr->rectWindow.top - wndPtr->rectClient.top ); - lps->hdc = GetDCEx(hwnd, hrgnUpdate, DCX_INTERSECTRGN | - DCX_WINDOWPAINT | DCX_USESTYLE | (bIcon ? DCX_WINDOW : 0) ); - /* ReleaseDC() in EndPaint() will delete the region */ - } + if( hrgnUpdate ) /* convert to client coordinates */ + OffsetRgn( hrgnUpdate, wndPtr->rectWindow.left - wndPtr->rectClient.left, + wndPtr->rectWindow.top - wndPtr->rectClient.top ); + lps->hdc = GetDCEx(hwnd, hrgnUpdate, DCX_INTERSECTRGN | + DCX_WINDOWPAINT | DCX_USESTYLE | (bIcon ? DCX_WINDOW : 0) ); + /* ReleaseDC() in EndPaint() will delete the region */ TRACE("hdc = %04x\n", lps->hdc); [View Less]

1 0

Re: readdir broken when called from wine
by Gerard Patel 18 Nov '01

18 Nov '01

At 08:17 PM 18/11/2001 +0100, you wrote: >After "upgrading" from Wine-20010418 to Wine-20011004 (self-compiled >from tarballs), suddenly it didn't find my "C:\Windows" any >more. Worked before, same 'puter, config files, etc (TM). Tried with >CVS version. <snip> >What could be the difference that makes readdir "break"? Take a look at the 'cvs-regression' file in the documentation directory. Gerard

2 1

Re: cleanup patch
by Marcus Meissner 18 Nov '01

18 Nov '01

> diff -u -r1.5 dib.c > --- dlls/ddraw/dsurface/dib.c 10 Sep 2001 23:12:16 -0000 1.5 > +++ dlls/ddraw/dsurface/dib.c 18 Nov 2001 13:47:22 -0000 > @@ -386,7 +386,11 @@ > > dbuf = (BYTE*)ddesc.lpSurface+(xdst.top*ddesc.u1.lPitch)+(xdst.left*bpp); > > - dwFlags &= ~(DDBLT_WAIT|DDBLT_ASYNC);/* FIXME: can't handle right now */ > + if (dwFlags & (DDBLT_WAIT|DDBLT_ASYNC)) > + { > + FIXME("dwFlags DDBLT_WAIT and/or DDBLT_ASYNC: can't handle … [View More]

1 0

I've been too damn bored today...
by Andreas Mohr 18 Nov '01

18 Nov '01

Hi all, that was the result: http://home.nexgo.de/andi.mohr/download/nicegraph.png -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany

2 1

Re: SystemParametersInfo: Screen Save actions
by Alexandre Julliard 17 Nov '01

17 Nov '01

Francois Gouget <fgouget(a)free.fr> writes: > In fact, I disagree with Alexandre when he says: > > > If users want to reconfigure X behavior, they have to use the X > > configuration programs. > > I think Wine is about more than just running Windows applications on > Linux. It's about integrating Windows and Linux applications and thus > they should be able to manipulate these kind of settings. Otherwise Wine > would only support the 'desktop mode'… [View More]

5 7

AutoCad2000 Error ...
by Ancient Computers 16 Nov '01

16 Nov '01

Wine release 20011108 Standard config. starting with wine acad.exe in a windows install ... fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--12-120-75-75-p-64-tis620.2533-1' has unknown character encoding '1' in known registry 'tis620 .2533' fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--13-130-75-75-p-71-tcvn-5712' has unknown character encoding '5712' in known registry 'tcvn' fixme:font:LFD_InitFontInfo font '-mdk-helvetica-medium-r-normal--8-80-75-… [View More]

1 0

Re: SystemParametersInfo: Screen Save actions
by Andreas Mohr 16 Nov '01

16 Nov '01

On Wed, Nov 14, 2001 at 07:22:39AM -0800, Andriy Palamarchuk wrote: > Change log: > > SystemParametersInfo. Implemented processing for > actions SPI_GET/SETSCREENSAVETIMEOUT, > SPI_GET/SETSCREENSAVEACTIVE, > SPI_GET/SETSCREENSAVERRUNNING. Removed integration > with X Window screen saving. Hmm, why did you remove X11 screen saving completely ?? Probably because it was horribly broken, right ? (SPI_SETSCREENSAVEACTIVE *activated* screen saver instead of *enabling* it - doh !… [View More]

3 3

RE: wine/ dlls/user/message.c include/win.h server ...
by Medland, Bill 16 Nov '01

16 Nov '01

Found the problem, not the fix. message.c function PeekMessageW. It used to call FindWinToRepaint but that has been moved into the server. But FindWinToRepaint was able to return a window handle other than the original message window handle. 1. So what about the IsIconic line following it? Now it's testing the wrong handle. 2. (The real problem)PeekMessageW returns the message. Now the handle it returns is the unadulterated one, not the potential child. So what do we do about that? Get the … [View More]

2 1

Re: [RFC]: Overlapped I/O implementation
by Alexandre Julliard 16 Nov '01

16 Nov '01

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > B) The check_async() function in synchro.c operates on file descriptors > rather than async requests. Once an overlapped I/O request is > issued by the application, it is queued either in the readers or > writers list of the async object (which is obtained from the server). > If both the readers and writers lists were NULL beforehand, the fd > is inserted into the list for check_async to work on. … [View More]

3 5

MIDL and COM
by Ove Kaaven 16 Nov '01

16 Nov '01

OK, since list traffic is low at the moment (which might be because /var on WineHQ got full again, and as usual the secondary MX provided by Corel seems to have the functionality of a black hole, so I've now moved the apache logs off /var), I thought I'd try to liven it up a bit with a couple of things I'm wondering about... Problem 1: MIDL-generated code. midl.exe is Microsoft's IDL compiler, it reads .idl files which describe RPC and COM interface, from which it generates .c files, .h files, … [View More]

1 0

RE: wine/ dlls/user/message.c include/win.h server ...
by Medland, Bill 15 Nov '01

15 Nov '01

This patch causes the listview class to enter some sort of infinite repaint loop on our application. Is someone else already tackling it? Bill > -----Original Message----- > From: Alexandre Julliard [mailto:julliard@winehq.com] > Sent: Wednesday, November 14, 2001 1:29 PM > To: wine-cvs(a)winehq.com > Subject: wine/ dlls/user/message.c include/win.h server ... > > > ChangeSet ID: 1005773317852080273907632 > CVSROOT: /opt/cvs-commit > Module name: wine > … [View More]

1 0

Re: Need to increase REQUEST_MAX_VAR_SIZE
by Andreas Mohr 15 Nov '01

15 Nov '01

On Thu, Nov 15, 2001 at 01:54:29PM +0100, Uwe Bonnes wrote: > Hallo, > > some aplication tries to set a reather longish windows text with over 512 > characters > > 0970c7a0:Call kernel32.lstrlenA(41b6bd8c "License for required features not available\n\n\nSorry, no Synplicity license is av"...) ret=006f06c2 > 0970c7a0:Ret kernel32.lstrlenA() retval=0000026b > ... > 0970c7a0:Call user32.SetWindowTextA(0001002e,41b6bb0c "License for required features not available\n\n\… [View More]

1 0

Re: 3D Studio 4 notes
by Gerard Patel 15 Nov '01

15 Nov '01

At 04:58 AM 15/11/2001 +0100, you wrote: <snip> >091d38d8:Call ws2_32.getsockopt(ffffffff,0000ffff,00007008,00f1ca84,45e96d54) ret=00de3f47 >fixme:winsock:_get_sock_fd handle -1 is not a socket (GLE 6) >trace:winsock:WSOCK32_getsockopt socket: ffffffff, opt 0xffff, ptr f1ca84, len 4 >091d38d8:Ret ws2_32.getsockopt() retval=ffffffff ret=00de3f47 Yes, this is not the old bug - the same call would fail under Windows. Even if the option is not supported by Wine, using a socket … [View More]

1 0

Re: wine_anon_mmap MAP_FIXED patch
by Ove Kaaven 15 Nov '01

15 Nov '01

On Thu, 15 Nov 2001, Bang Jun-Young wrote: > on MAP_FIXED flag. On Linux, it shouldn't do any harm. Yes, it would do harm. See http://www.winehq.com/hypermail/wine-devel/2000/11/0167.html

1 0

Re: 3D Studio 4 notes
by Gerard Patel 15 Nov '01

15 Nov '01

At 04:43 PM 14/11/2001 +0100, you wrote: <snip> >fixme:winsock:_get_sock_fd handle -1 is not a socket (GLE 6) >MSG .0 fatal: getsockopt(SO_OPENTYPE) failed - Invalid handle This error message has already been posted several times on the news group. It was linked to the previous Wine version (october) Do you use last version (1108) or current Cvs ? Gerard

2 2

Re: patch.py?id=1005690229526658676564693 (fwd)
by Alexandre Julliard 15 Nov '01

15 Nov '01

lawson_whitney(a)juno.com writes: > Hmmm, I put the patch back, and took desktop= out of the config. The > problem only happens in desktop mode. That is not so bad, I don't have > to spend 45 minutes reverting the patch just to get mail. Still, I > guess I should try to debug it. It should be fixed now. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wine_anon_mmap MAP_FIXED patch
by Ulrich Weigand 15 Nov '01

15 Nov '01

Bang Jun-Young <junyoung(a)mogua.com> wrote: > Why this is necessary is because most Win32 binaries expect itself > to be loaded at fixed address (0x400000). GCC and M$ compilers seem > to strip relocation info on .exe by default, so we need to ensure > that on some OS, i.e. NetBSD. Refer to NetBSD/FreeBSD mmap(2) manpage > on MAP_FIXED flag. On Linux, it shouldn't do any harm. On Linux and Solaris, MAP_FIXED has a different meaning: it will *replace* any pre-existing … [View More]

1 0

Re: patch.py?id=1005690229526658676564693 (fwd)
by Gerard Patel 14 Nov '01

14 Nov '01

At 10:10 PM 13/11/2001 -0500, you wrote: >Good day! > >regapi still works. My little winelib program exits with no error, but >leaves a stale socket and does nothing. juno.exe, progman, >I_view32.exe, and Dmitry's little About.exe leave a stuck wine process >and a stale wineserver socket. I expect there is general consternation, >or else it has been fixed already, but I guess I will have to reverse >the patch to see. > general consternation ? Well, I have about 20 … [View More]

2 3

patch.py?id=1005690229526658676564693 (fwd)
by lawson_whitney＠juno.com 14 Nov '01

14 Nov '01

Good day! regapi still works. My little winelib program exits with no error, but leaves a stale socket and does nothing. juno.exe, progman, I_view32.exe, and Dmitry's little About.exe leave a stuck wine process and a stale wineserver socket. I expect there is general consternation, or else it has been fixed already, but I guess I will have to reverse the patch to see. Regards, Lawson ---oof--- ________________________________________________________________ GET INTERNET ACCESS FROM … [View More]

2 1

Re: [RFC]: Overlapped I/O implementation
by Mike McCormack 14 Nov '01

14 Nov '01

Hi Martin, >However, I assume you have had good reasons to abaondon the old >server-centric implementation, so I'm reluctant to go that way. Not really. The main reason i did it was because the server is slow and clunky and i thought i'd be able to squeeze a bit of extra performance out of the code by putting it in the client. The best starting point for solving the problems you describe is to revert my patch that put async I/O in the client. i'll even do it if you like... Now who … [View More]

1 0

Yet another async I/O issue: block devices
by Martin Wilck 14 Nov '01

14 Nov '01

Hi, I just discovered yet another problem that arises for overlapped I/O on normal disk files, more correctly, for any file on a block device. Obviously IO requests on block devices on Linux are _always blocking_. I wrote a very simple test program for reading from a floppy disk and found exactly this behaviour, no matter if O_NONBLOCK was set or not. "man 2 open" also says that O_NONBLOCK may or may not have any effect on non-socket fd's and for block devices it clearly has none. I don't … [View More]know the reason for this, but it may have to do with Linux' caching algorithms. This means that - with ReadFile() etc. on regular files, the asynch code will never be executed. Instead, the call will block when trying to read immediately, and then return success. - I am not 100% sure in what context the asynchronous handlers are executed, but the read() write() calls there will be blocking as well. I assume this is not what we want. - I guess that for programs that "know" some IO is going to take a lot of time (read()s on floppies, network file systems, ...) will potentially be broken if they try to do overlapped IO and "do something else" while the IO is executing. I do see the need, therefore, to have an approach that mimics Windows' behaviour here. - The only simple approach that I can see for making this happen is creating a separate thread for reading/writing asynchronous IO. The simplest approach would actually be to do a clone() for each async request with CLONE_FILES | CLONE_VM | CLONE_PARENT. I don't know how this would fit into Wine's general synchronization approach - please give me hints. - The separate thread itself would be very simple for files on block devices, because it can simply execute the blocking read and finish when the read finishes, leaving some status information somewhere. - For other devices that _do_ support O_NONBLOCK, it may be cool to mimic this simple behaviour by clone()ing too, dup() ing the fd, resetting the O_NONBLOCK flag, and doing a blocking IO request just the same. That means to basically leave it up to the kernel to handle synchronization. This would also mean that we wouldn't have to worry about differences between files and sockets/pipes, because I'm 99% sure the kernel would do it right. I don't understand the concept of the wine service thread well enough yet to judge if that could be used for doing what I just suggested. Perhaps someone can help me out with that, I'll be studying the sources in the meantime. Cheers, Martin PS. I guess another possible approach would be using raw I/O, but I am very certain this is not what we want. -- 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 [View Less]

2 1

Local USER classes act as global
by Joshua Thielen 14 Nov '01

14 Nov '01

Hello, When I checked out the latest CVS, all the dialog boxes in Finale stopped working (again) . This happened since Alexandre fixed a function call from GetModuleHandleA("USER") to GetModuleHandle16("USER") in my previous GetClassInfo16 patch (thanks Alexnadre!). My patch had worked because GetModuleHandleA returned hInstance 0 for USER and Finale would proceed to register a window class with hInstance 0. Since classes with hInst=0 are treated sort of like global classes in wine, the … [View More]window class was found. After more investigating, I discovered that in Win16, any window class that is registered with a USER instance handle will be found even if the hInstance passed to the function (GetClassInfo, CreateWindow etv c.) is completely different. This happens even for classes without the CS_GLOBALCLASS style. I have some small test apps if anyone is intrigued by this. Anyway, this patch implements this undocumented bug, uh.. er.. feature in wine and gets Finale working again . Changelog: Local classes registered with USER instance handle now are now found in CLASS_FindClassByAtom. Modified Files: wine/windows/wnd16.c Josh Thielen Index: wine/windows/class.c =================================================================== RCS file: /home/wine/wine/windows/class.c,v retrieving revision 1.42 diff -u -r1.42 class.c --- wine/windows/class.c 2001/11/06 20:57:27 1.42 +++ wine/windows/class.c 2001/11/13 23:23:39 @@ -279,10 +279,14 @@ * NOTES * 980805 a local class will be found now if registred with hInst=0 * and looed up with a hInst!=0. msmoney does it (jsch) + * + * Local class registered with a USER instance handle are found as if + * they were global classes. */ static CLASS *CLASS_FindClassByAtom( ATOM atom, HINSTANCE hinstance ) { - CLASS * class, *tclass=0; + CLASS * class, *tclass = 0, *user_class = 0; + HINSTANCE hUser = GetModuleHandle16("USER"); TRACE("0x%08x 0x%08x\n", atom, hinstance); @@ -293,16 +297,20 @@ if (class->style & CS_GLOBALCLASS) continue; if (class->atomName == atom) { - if (hinstance==class->hInstance || hinstance==0xffff ) + if (hinstance==class->hInstance || hinstance==0xffff) { TRACE("-- found local %p\n", class); return class; } - if (class->hInstance==0) tclass = class; + if (class->hInstance == 0) tclass = class; + else if(class->hInstance == hUser) + { + user_class = class; + } } } - /* Then search global classes */ + /* Then search global classes */ for (class = firstClass; (class); class = class->next) { @@ -312,6 +320,13 @@ TRACE("-- found global %p\n", class); return class; } + } + + /* Check if there was a local class registered with USER */ + if( user_class ) + { + TRACE("--found local USER class %p\n", user_class); + return user_class; } /* Then check if there was a local class with hInst=0*/ [View Less]

1 0

weird linux/solaris problem.
by Roger Fujii 13 Nov '01

13 Nov '01

Well, I finally figured out the major problem I've been having with wine and virtualdub under solaris, but I'm not sure what to do about it. In memory/virtual.c, there are 2 problems: 1) in function anon_mmap_aligned, there is a section that tries to release extra memory. The problem is that under solaris, munmap length parameter is defined as: The munmap() function removes the mappings for pages in the range [addr, addr + len), rounding the len argument up to … [View More]

1 0

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