Re: config error
On Tue, Sep 02, 2003 at 10:49:45AM +0200, Moreno wrote:
Hi,
When i try to use the variable ${HOME} in the wine config file don't
work.
some one can tell me if there is a reson or is a bug?
Support for the use of enviroment variables in the config file was
removed not too long ago. You need to replace ${HOME} with the actual
path to your home directory.
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
pgp0.pgp
Description: PGP signature
Re: Direct access to LPT1
On Fri, Jul 25, 2003 at 03:41:10PM +0100, E Lea wrote: E I'm playing around with a program that controls a small design E cutter - it's basically a plotter that connects via the parallel E port. E There is some Windows CAD software that knows about the plotter and E sends commands to it, as far as I can tell in one of two ways: E 1) Through a printer driver. It doesn't seem too bothered about the E details of the driver though. I'm assuming that one would normally E use a generic, text-only Windows driver. This method, apparently, has E the advantage of the driver buffering the output Wine can't run Ring 0 drivers, like something ending in .sys/ .vxd The plotter doesn't need a specific driver - it doesn't even have one. In Windows it uses any old printer driver just to open the printer port, then sends commands to the plotter through the printer driver. Should it not be possible to do this with Wine? Possibly not with CUPS though... Well that should work with cups too, you need to configure a printer with model RAW. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: Typelib marshalling BSTRs
Hello, On Wed, Jul 23, 2003 at 10:41:12AM +0100, Mike Hearn wrote: Perhaps, this really indicates some kind of problem with the loading / linking or the spec.c file or something like that? Does the behavior change if you take out the RpcTryFinally? I would guess not. It does not. To recap: REFIID riid = NULL; - fails, because assignments to it are silently ignored REFIID riid; riid = NULL; - works, because . it confuses the gremlins? Is this in a callback function and riid isn't used in the function? If yes then the gcc is probably throwing the variable away. Did you tried to compile it with -O0 or just put a volatile in front of it: volatile REFIID riid = NULL; bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: testers needed with win 9x/me
On Wed, Jul 02, 2003 at 09:33:34PM +0200, Stefan Leichter wrote: before i convert the function QueryDosDevice from ascii to unicode i did some testings on my NT box. The result returned of the test are much different from what the current implementation returned. Therefore i am okking for some testers which are building the attached program on their computer and returning the output to me. I've got 2 precompiled binaries from Marcelo Duarte (mingw) and from you but both print garbage in the terminal and die after a while (yours much faster) with Windows equivalent (aka MessageBox) of a SIGSEGV. I guess i need to install cygwin on the win95 box and try to compile the test program myself and see if that works better. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: testers needed with win 9x/me
Hi, On Wed, Jul 02, 2003 at 09:33:34PM +0200, Stefan Leichter wrote: before i convert the function QueryDosDevice from ascii to unicode i did some testings on my NT box. The result returned of the test are much different from what the current implementation returned. Therefore i am okking for some testers which are building the attached program on their computer and returning the output to me. I have a win95 box sitting near me. I would prefer a compiled test, would save me the hazzle to cross-compile it. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: quartz once again: was DEVENUM.DLL Implementation
On Thu, Jun 12, 2003 at 11:46:28AM +, Mark Hannessen wrote: Well, if you want to start work on Quartz, feel free to do it, you would be our saviour (to all the gamerz out there who cannot have intro / cutscene movies due to the missing Quartz stuff in Wine). quartz was already was in wine once. but was removed from wine because of legal issues. that is, the author feared it was not legal and demanded it to be removed. transgaming is still using it in WineX and it's LGPL code so you if you really Yes, and that's because they are accepting the risk that somebody will sue them. need it you can just copy it from their cvs tree. still i think it would be nice to have quarz in wine so i have been thinking about this one for some time. but what makes you think writing a new one is not going to have legal issues? It wasn't pulled out because of legal issues, it was pulled out because the author feared legal issues and asked Alexandre to remove it. And Alexandre respects that wish and wont accept the same code back in. New code will be accept. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: [GDI] GetObject patch (for null buffer functionality)
On Fri, Jun 06, 2003 at 10:39:43AM -0500, Kelly Leahy wrote: I just found a problem with this patch. Let me send another one... Please send the patch as unified diff (diff -u). See http://www.winehq.com/Docs/wine-devel/patches.shtml for details. bye michael I'll have it this afternoon. It shouldn't be a big deal (it won't be worse than the code was before) but let me fix it anyway. Kelly - Original Message - From: Kelly Leahy To: [EMAIL PROTECTED] Sent: Friday, June 06, 2003 10:22 AM Subject: [GDI] GetObject patch (for null buffer functionality) Kelly Leahy [EMAIL PROTECTED] Changelog- - fixes problems with GDI GetObject function not working properly when a NULL buffer or 0 count is used. - note - no attempt was made to fix this problem under 16-bit windows functions (GetObject16). Description: The GDI GetObject function should return the number of bytes required for the buffer, when a NULL buffer pointer is passed to the function. However, the implementation in CVS did not provide this functionality. I've added two function pointers to the gdi_obj_funcs structure that allow for this functionality. The pointers are pGetObjectSizeA and pGetObjectSizeW, and for all object types except FONT, they are implemented by the same function. On FONT, the structure differs depending on whether the LOGFONTA or LOGFONTW structure is required (depends on which function is called - GetObjectA or GetObjectW). For bitmaps, the function must determine which structure is most appropriate (BITMAP or DIBSECTION) and return the size of that structure - it does so now. Patch is attached. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: Wierd random spew to the terminal
On Mon, Jun 02, 2003 at 04:03:49PM +0100, Mike Hearn wrote:
Hmm, I think quite a few of us have seen this now. Well, it just
happened again so this time I attached gdb and tried to get a backtrace
to see what was going on.
I found a very curious thing the stack trace was huge, in fact, it
had 3162 frames. As you might expect it was recursive. It looked like
this:
I once had this problem and it was triggered by an unimplemented
function in msvcrt. Did you tried running with --debugmsg +seh? But
better redirect the output to a file.
bye
michael
#3141 signal handler called
#3142 0x4009e977 in rwlock_real_init (rwlock=0x42126020) at
../../include/winbase.h:1932
#3143 0x4009ea48 in __pthread_rwlock_rdlock (rwlock=0x42126020) at
../../scheduler/pthread.c:547
#3144 0x4202365a in __dcigettext () from /lib/i686/libc.so.6
#3145 0x42022ed5 in dcgettext () from /lib/i686/libc.so.6
#3146 0x4207a4b7 in strerror_r () from /lib/i686/libc.so.6
#3147 0x4206148b in perror () from /lib/i686/libc.so.6
#3148 0x40099259 in server_protocol_perror (err=0x400bdc31 read) at
../../scheduler/client.c:134
#3149 0x40099388 in read_reply_data (buffer=0x405ca5a4, size=64) at
../../scheduler/client.c:195
#3150 0x400993de in wine_server_call (req_ptr=0x405ca5a4) at
../../scheduler/client.c:209
#3151 0x400a8653 in send_debug_event (rec=0x405ca6a8, first_chance=1,
context=0x405ca71c)
at exception.c:137
#3152 0x400a87fa in EXC_RtlRaiseException (rec=0x405ca6a8,
context=0x405ca71c) at exception.c:195
#3153 0x400b6e48 in do_segv (context=0x405ca71c, trap_code=14, cr2=0x18,
err_code=4)
at signal_i386.c:814
#3154 0x400b7324 in segv_handler (__signal=11, __context=
{sc_gs = 143, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh
= 0, sc_ds = 43, __dsh = 0, sc_edi = 1108452444, sc_esi = 1108500512,
sc_ebp = 1079815400, sc_esp = 1079815380, sc_ebx = 1074654520, sc_edx =
1108500512, sc_ecx = 1108481382, sc_eax = 0, sc_trapno = 14, sc_err = 4,
sc_eip = 1074391415, sc_cs = 35, __csh = 0, sc_eflags = 66050,
esp_at_signal = 1079815380, sc_ss = 43, __ssh = 0, i387 = 0, oldmask =
2415929859, cr2 = 24}) at signal_i386.c:436
#3155 signal handler called
So it would appear that there is a crash in the exception handler which
just goes round and round, and clearly at some point garbage is written
to stdout/stderr.
Unfortunately my code-fu is not strong in areas related to
threading/exception handling, so I don't really know what's going wrong,
except that it seems there is a problem in rwlock_real_init (in fact the
line number it gives is in GetProcessHeap()).
Well, I thought somebody may find it useful. BTW, after I attached to
wine (ie stopped it) something was still typing out letter by letter
xtermxtermxterm over and over again wake up neo :)
thanks -mike
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
pgp0.pgp
Description: PGP signature
SMATCH: Returning with freed result
Hello,
this was found by unfree-wine.pl a slight modification of smatch's
unfree.pl. The first occurence was easy to fix (see attachment) but i
don't know what should be done in this case:
dlls/ole32/filemoniker.c 1084 1086 FileMonikerImpl_CommonPrefixWith(75)
Returning with freed result var_decl(commonPath)
This is due to this code:
HeapFree(GetProcessHeap(),0,commonPath);
return CreateFileMoniker(commonPath,ppmkPrefix);
I would save the return of CreateFileMoniker to a temp variable and
after that free commonPath but i don't know if it's the desired fix.
License: LGPL, X11
Changelog:
Michael Stefaniuc [EMAIL PROTECTED]
- fix for return of a previous freed object
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
Index: dlls/ddraw/main.c
===
RCS file: /home/wine/wine/dlls/ddraw/main.c,v
retrieving revision 1.31
diff -u -r1.31 main.c
--- dlls/ddraw/main.c 15 Mar 2003 00:12:43 - 1.31
+++ dlls/ddraw/main.c 2 Apr 2003 22:17:16 -
@@ -388,8 +388,10 @@
TRACE((%p)-() decrementing from %ld.\n, This, This-ref);
-if (--This-ref == 0)
+if (--This-ref == 0) {
HeapFree(GetProcessHeap(), 0, This);
+ return 0;
+}
return This-ref;
}
pgp0.pgp
Description: PGP signature
Re: Compiling WINE - Hopeless situation? :)
On Sat, Mar 29, 2003 at 11:50:41PM +0100, Sylvain Petreolle wrote: Really ? :) See GCC team offical response to it. http://gcc.gnu.org/gcc-2.96.html FUD, 2.96 is just yet another C++ incompatible version of gcc. 2.96 was broken in the beginning but is long ago fixed. Even Linus used it to compile the Kernel with it. Ok, the 2.96-0.76mdk of the OP seems to be pretty old; i'm using at the moment gcc-2.96-113 and it just works. bye michael If interested in any other projects response: http://www.mplayerhq.hu/DOCS/users_against_developers.html#gcc If you think its false, telle me why the wine code doesnt compile with 2 Mandrake machines having this version of gcc? That's total FUD. There is no problem compiling and running Wine on a 2.96-based distro. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: Regression in latest CVS
On Sat, Mar 22, 2003 at 09:46:46AM -0700, Vitaliy Margolen wrote: I have a problem with latest CVS in the past several days. Every app locking up. I have the same problem, but only with FreeSolitaire, the other apps are working fine. Monday evening it was working fine and thursday night when i checked it again it didn't worked anymore. I didn't had the time yet to look closer at it and haunt for the patch that introduced the regression. Any suggestions where should I look. It's not a dead loop. Something happening, according to trace. The trace looks similar to this one and I get following backtrace: Unhandled exception: page fault on write access to 0xcf4b in 32-bit code (0x 004db689). In 32-bit mode. 0x004db689 ([EMAIL PROTECTED]@initialization$qqrv+0x6f13d in C:\Program Files\FreeSolitaire\FreeSolitaire.exe): movl %edx,0x0(%ebx) Wine-dbgbt Backtrace: =0 0x004db689 ([EMAIL PROTECTED]@initialization$qqrv+0x6f13d in C:\Program Files\FreeSolitaire\FreeSolitaire.exe) (ebp=40592e30) 1 0x004db6d8 ([EMAIL PROTECTED]@initialization$qqrv+0x6f18c in C:\Program Files\FreeSolitaire\FreeSolitaire.exe) (ebp=40592e60) 2 0x004da904 ([EMAIL PROTECTED]@initialization$qqrv+0x6e3b8 in C:\Program Files\FreeSolitaire\FreeSolitaire.exe) (ebp=40592e74) 3 0x004db49b ([EMAIL PROTECTED]@initialization$qqrv+0x6ef4f in C:\Program Files\FreeSolitaire\FreeSolitaire.exe) (ebp=40592e88) bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: Wine and XFree86 4.3.0
Hi,
On Thu, Mar 20, 2003 at 11:00:06AM +0100, Ulrich Spoerlein wrote:
does anyone here have WINE running with XFree86 4.3.0? Everytime I start
Yes, I have it running and no problems so far. I took the XFree86 srpm
from the next Red Hat Linux release and just recompiled it on Red Hat
Linux 7.3 (i needed to upgrade the kernel too).
bye
michael
up wine it complains about a broken libXrender and the palette is
completely screwed (or the window remains totally black).
The failing test is at wine/dlls/x11drv/render.c:163
screen_format = pXRenderFindVisualFormat(gdi_display, visual);
if(!screen_format) { /* This fails in buggy versions of libXrender.so */
wine_tsx11_unlock();
WINE_MESSAGE(
Wine has detected that you probably have a buggy version\n
of libXrender.so . Because of this client side font rendering\n
will be disabled. Please upgrade this library.\n);
X11DRV_XRender_Installed = FALSE;
return;
}
XRenderVisualFormat changed only slightly between 4.2.1 and 4.3.0, so I
guess the error is somewhere else.
I'm running the newest WINE release on FreeBSD 4.8.
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
pgp0.pgp
Description: PGP signature
Re: error when running wine..
On Tue, Mar 18, 2003 at 11:35:54AM +0100, Juan Rey Saura wrote: It also happened to me with the latest cvs build trying to run totalcommander. JGraham wrote: has anyone gotten this message err:module:get_registry_value Invalid load order module-type Lso, ignored? it's been happening for me on current cvs builds. I have a clean fake windows and registry. so, i shouldn't be getting it.. You need to delete the so entry from your .wine/config file: [DllOverrides] ; default for all other dlls * = builtin, native, so delete this bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: bitmap corruption
On Sun, Mar 16, 2003 at 02:02:18AM +, Mike Hearn wrote: if anybody wishes to tackle a fun bug, take a look at the imagelist control in commctrl32 - it corrupts masks, giving some nasty visual corruption esp on toolbar icons, but i've also seen it in winrar. Have a look at this email http://www.winehq.com/hypermail/wine-patches/2003/03/0038.html ImageList_AddMasked() is known to corrupt images. bye michael i suspect the _read_bitmap function doesn't do 1bit images correctly, but didn't really manage to find out. i might have another crack tomorrow, but in case somebody is looking for a job :) -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: bitmap corruption
On Sun, Mar 16, 2003 at 04:19:55PM +, Mike Hearn wrote:
I think this is different - I have that patch applied, and it still
corrupts things. Also AddMasked isn't used in this app iirc.
Is the app using ImageList_LoadImage{A,W}()? Both functions are using
AddMasked without copying the bitmap. Same applies for TREEVIEW_Create()
bye
michael
On Sun, 2003-03-16 at 15:59, Michael Stefaniuc wrote:
On Sun, Mar 16, 2003 at 02:02:18AM +, Mike Hearn wrote:
if anybody wishes to tackle a fun bug, take a look at the imagelist
control in commctrl32 - it corrupts masks, giving some nasty visual
corruption esp on toolbar icons, but i've also seen it in winrar.
Have a look at this email
http://www.winehq.com/hypermail/wine-patches/2003/03/0038.html
ImageList_AddMasked() is known to corrupt images.
bye
michael
i suspect the _read_bitmap function doesn't do 1bit images correctly,
but didn't really manage to find out. i might have another crack
tomorrow, but in case somebody is looking for a job :)
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
pgp0.pgp
Description: PGP signature
Re: shlwapi.dll, Fix endless loop in StrPBrkW
Ok, i finaly got the time to finish the smatch script. It checks for
while|for (...); constructs and would have found the bug which started
this thread. It found also two possible infinite while loops:
dlls/kernel/tests/thread.c line 102
dlls/winmm/mciseq/mcimidi.c line 982
but that could be also a busy loop waiting for an other thread to modify
the data.
For the script and mored details see
http://people.redhat.com/mstefani/wine/smatch/
bye
michael
On Mon, Mar 03, 2003 at 11:14:34PM +0100, Michael Stefaniuc wrote:
On Mon, Mar 03, 2003 at 04:14:16PM -0500, Vincent Béron wrote:
Michael Stefaniuc a écrit:
That's even easier in smatch, i have to just check for:
(if|for|while)_cond
end_(if|for|while)
but that's still a lot of false positives. One false positive (real
code) is:
while (*p++ != 0x4D p pend);
I need to check what's inside the () too. I'm looking at the moment at
the false positives to know what to look for.
Probably anything that changes a value (++, --, =, +=, -=, *=, /=, etc.).
That is my intention.
But then you risk losing some real problems, as something might be
correctly assigned in the condition part of a while, but with a ; as
loop instead of the real loop.
Hmm ... that is also easy to check
while (...);
{
translates into smatch:
end_while
cmpstmt_start
A lot of nice stuff to play with.
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
pgp0.pgp
Description: PGP signature
Re: Should crosstesting work?
On Wed, Mar 05, 2003 at 07:35:17PM +0100, Ferenc Wagner wrote: Dear Crosstest Users, please speak up! I'm very interested in hearing about anybody being able to 'make crosstest' and run the tests on native Windows. That would be a great help debugging the problem. I've seen this problem too with the precompiled mingw packages (links to them are on the mingw homepage). With self build mingw i couldn't get mingw to link the binaries. The patch in this thread http://www.winehq.com/hypermail/wine-devel/2003/02/0123.html fixed it for me. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: shlwapi.dll, Fix endless loop in StrPBrkW
On Mon, Mar 03, 2003 at 07:01:35PM +0100, Eric Pouech wrote: -while (*lpszStr); +while (*lpszStr) could we catch this type of error with smatch ? It's pretty easy to check for (while|for)();, but the interesting part is to keep the false positive minimal. I'll see what i can do. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: shlwapi.dll, Fix endless loop in StrPBrkW
On Mon, Mar 03, 2003 at 10:01:39PM +0100, Eric Pouech wrote:
Michael Stefaniuc wrote:
On Mon, Mar 03, 2003 at 07:01:35PM +0100, Eric Pouech wrote:
-while (*lpszStr);
+while (*lpszStr)
could we catch this type of error with smatch ?
It's pretty easy to check for (while|for)();, but the interesting
part is to keep the false positive minimal. I'll see what i can do.
look for:
if (...);
(while|for)(...);{
};while
should limit false positives
That's even easier in smatch, i have to just check for:
(if|for|while)_cond
end_(if|for|while)
but that's still a lot of false positives. One false positive (real
code) is:
while (*p++ != 0x4D p pend);
I need to check what's inside the () too. I'm looking at the moment at
the false positives to know what to look for.
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
pgp0.pgp
Description: PGP signature
Re: shlwapi.dll, Fix endless loop in StrPBrkW
On Mon, Mar 03, 2003 at 04:14:16PM -0500, Vincent Béron wrote:
Michael Stefaniuc a écrit:
That's even easier in smatch, i have to just check for:
(if|for|while)_cond
end_(if|for|while)
but that's still a lot of false positives. One false positive (real
code) is:
while (*p++ != 0x4D p pend);
I need to check what's inside the () too. I'm looking at the moment at
the false positives to know what to look for.
Probably anything that changes a value (++, --, =, +=, -=, *=, /=, etc.).
That is my intention.
But then you risk losing some real problems, as something might be
correctly assigned in the condition part of a while, but with a ; as
loop instead of the real loop.
Hmm ... that is also easy to check
while (...);
{
translates into smatch:
end_while
cmpstmt_start
A lot of nice stuff to play with.
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
pgp0.pgp
Description: PGP signature
Re: Wine and Smatch
On Mon, Mar 03, 2003 at 11:03:07AM -0800, Alexandre Julliard wrote: Michael Stefaniuc [EMAIL PROTECTED] writes: It includes also a table with the bugs found by the smatch scripts. I could need a hand with the bugs (status BUG, UKNOWN) cause I don't know how to fix them correctly (and for some locking BUG's i am not sure that they are real bugs). The ones in gdiobj.c and win.c are not bugs, the functions are supposed to return with the lock held. There should be a matching GDI_ReleaseObj/WIN_ReleasePtr after each call though. Thanks. So they are basicaly only wrappers around the locking function and can be treated as locking functions themself. Updated wine_locks.pl and the website acordingly. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: Wine and Smatch
On Mon, Mar 03, 2003 at 08:28:33PM +0100, Eric Pouech wrote: Michael Stefaniuc wrote: I've written a web page about Wine and Smatch: http://people.redhat.com/mstefani/wine/smatch/ - there's a return in excess in programs/wcmd/builtins.c That return needs to be deleted only? - we shouldn't return 0 in dlls/winmm/wineoss/audio.c (as the comment says ;-) I've read the comment but the script dosn't complain about the return, it complains about the ExitThread(0) before it. This is after a switch embeded into a while loop and smatch seems to not handle this quite correctly. I've change the status to NOTABUG. - the code in programs/winhelp/hlpfile.c is correct Same like before, but this already had the NOTABUG status. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Wine and Smatch
Hello, I've written a web page about Wine and Smatch: http://people.redhat.com/mstefani/wine/smatch/ It includes also a table with the bugs found by the smatch scripts. I could need a hand with the bugs (status BUG, UKNOWN) cause I don't know how to fix them correctly (and for some locking BUG's i am not sure that they are real bugs). Now that the fight with the web page is over I can go to write more smatch scripts ;). bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: gcc 3.2.2?
On Mon, Feb 24, 2003 at 01:44:27AM -0600, Gregory M. Turner wrote: To my surprise, Gentoo (ACCEPT_KEYWORDS=, iow stable Gentoo) is ready to give me gcc 3.2.2 (in fact it compiles as I type). So, what can I expect from wine and gcc322? Any known interestingnesses? Anyone even tried it? Presumably, since the threading magic needs to be in the kernel (I run a modified linux-2.4.21-pre4-ac5 atm), I will not get the pthread bug... but then again, how do I know for sure if I suffer from that or not? Is there a test that is known to reliably break against the new threading model (or perhaps I can presume I got it if i can't run notepad?1) If you can run notepad you aren't affected by the bug because the bug is merciless: the wineserver wont even start because it fails to create the needed socket in /tmp/.wine-$user/server-XX/ (this stuff gets deleted on wine shutdown). If by any chance the socket is still present, wine will still crash pretty fast. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: SMATCH: missing LeaveCriticalSection in error path
On Sun, Feb 23, 2003 at 11:39:33AM +0800, Dmitry Timoshkov wrote: Michael, I'm just curious, how hard it would be to adapt your SMATCH script for finding EnterCriticalSection/LeaveCriticalSection pair matching to do a similar work with wine_tsx11_lock/wine_tsx11_unlock, GDI_GetObjPtr/GDI_ReleaseObj, DC_GetDC[Ptr|Update]/GDI_ReleaseObj, USER_Lock/USER_Unlock, WIN_GetPtr/WIN_ReleasePtr, WIN_FindWndPtr/ WIN_ReleaseWndPtr and some other internal Wine locks? Not hard at all, I've created a new script http://people.redhat.com/mstefani/wine/smatch/wine_locks.pl that takes care of locks of the form: lock(this); do_something(); unlock(this); and put all of the above locking pairs into it. To add a new locking pair all that's needed is to add an entry for it in the %locks hash. Running wine_locks.pl requires this patch http://people.redhat.com/mstefani/wine/smatch/smatch.pm.diff for smatch.pm because it treats every ARGV entry as filename (i'll contact the smatch author to find a solution that dosn't require this hack). Besides some NOTABUG's in the CriticalSection locking i found only this: wine/windows/win.c 104 127 create_window_handle(31) 1 USER_Lock not released I'm not sure if it's a bug or not. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart pgp0.pgp Description: PGP signature
Re: SMATCH: add missing LeaveCriticalSection
On Sun, Feb 09, 2003 at 04:27:22PM -0800, Dan Kegel wrote: Michael Stefaniuc wrote: on some error path the critical section wasn't released. Found with smatch's help. I'm impressed. Didn't know smatch could detect this kind of thing in Wine code. I had to adapt a script from smatch to do this, but to be honest, searching for missing LeaveCriticalSection's is a trivial task for smatch. I'll do some more wine specific scripts, easier ones first to get used to smatch. For those who haven't heard of smatch, see http://smatch.sf.net bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg17384/pgp0.pgp Description: PGP signature
smatch, something like the Stanford Checker
Hello, i always dreamed to have something like the Stanford Checker for Wine and some days ago i've seen on freshmeat smatch http://smatch.sourceforge.net/ . It's a project from KernelJanitors and it seems usefull, at least it's worth an entry on Dimi's janitorial page. A short description: Smatch is basicaly a patch to gcc-3.1.1 that makes the gcc dump out it's internal represantation of the code and a set of perl modules/scripts to ease the parsing of the dumped code. Most of the perl scripts are for the Linux Kernel but writing new scripts seems to be easy. I wrote (well, mostly adapted an existing script for the kernel) one script http://people.redhat.com/mstefani/wine/smatch/enter_leave.pl (if we decide to adopt smatch it should probably go to $wine/tools/smatch/) to find code path with missing LeaveCriticalSection's. Scripts to find some other usefull things like fd, DC, GDI obejects leaks should be easy to write. Comments? bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg17380/pgp0.pgp Description: PGP signature
Re: PATCH: Get rid of superfluous dup() and close() calls.
On Thu, Feb 06, 2003 at 10:49:17AM +0100, Martin Wilck wrote:
On Mon, 2003-02-03, I wrote:
Why is that relevant to Wine? 99% of the Wine code uses DOS/Windows
functions like WriteFile() anyway. All we need to do is make sure that
these functions handle the Unix fd's properly (and they will if they
don't call close()).
What's up, people? I think at least I deserve an answer to this
argument. Or is everybody just too busy?
Well, i agree with you that the close call's shouldn't be needed but my
voice dosn't count.
bye
michael
I am not going to give up easily on this one, because I still think it's
the right thing to do. If anybody is worried about regressions or the
risk of future close() calls, I am willing to care for that.
As for the risk of someone inadvertently close()ing an fd and someone
else writing to it, how about something like this:
static inline int wine_close_unix_fd (int fd) { return close (fd); }
#define close(fd) ERROR --- please dont call close() in Wine !!
in the Wine headers, and changing close() to wine_close_unix_fd()
wherever the close() is found to be legitimate?
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
msg17276/pgp0.pgp
Description: PGP signature
Re: Started playing with Wineserver on mingw/cygwin again
On Wed, Feb 05, 2003 at 11:05:08PM +0100, Michael Stefaniuc wrote: On Wed, Feb 05, 2003 at 01:47:46PM -0800, Francois Gouget wrote: On Wed, 5 Feb 2003, Michael Stefaniuc wrote: i hate to reply to myself but here is Ingo's answer: | could you try: | | export LD_ASSUME_KERNEL=2.2.5 | | prior starting up Wine, does this fix the problem for you? According to reports on the CrossOver mailing lists this works on Phoebe 1 but does not work anymore on Phoebe 2. Phoebe 2 had kernel-2.4.20-2.21 and that one had some problems with signals. Usable for wine are kernels starting with kernel-2.4.20-2.30. The actual kernel in rawhide is 2.4.20-2.34; i'll test tomorrow wine on Phoebe 2 with the actual kernel. Ok, i've checked Phoebe2 with kernel 2.4.20-2.33 and the LD_ASSUME_KERNEL workaround and wine seems to work just fine. This should give us some time to move to pthreads. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg17308/pgp0.pgp Description: PGP signature
Re: Started playing with Wineserver on mingw/cygwin again
On Wed, Feb 05, 2003 at 01:47:54PM -0500, Dimitrie O. Paun wrote: On Wed, 5 Feb 2003, Geoff Thorpe wrote: [1] For that matter, has anyone attempted to pull this person into the wine discussion to help flesh this out and find the optimal way forward? Surely any self-respecting (L)GPLer would hate to see a major tool for open source advancement getting hurt over this without so much as some constructive help? This is an interesting question. I know Ingo Molnar has been (one of) the As far as I know he probably reads wine-devel too. main developer working on the glibc threading stuff, and I also know he He did the kernel stuff, the glibc part was done by Ulrich Drepper. used to follow the Wine project. I am sure he's not indifferent to our He even follows rewind . fate, and being so deeply involved with the glibc changes, he's probably an invaluable resource. Unfortunately, I'm not sure he's even aware of the problem -- has anyone contacted him? Anyone want to do so? (Dan? :)) I'll write him an email. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg17232/pgp0.pgp Description: PGP signature
Re: Started playing with Wineserver on mingw/cygwin again
On Wed, Feb 05, 2003 at 01:10:10PM -0600, Phil Bordelon wrote: Phoebe (the current RH beta, labeled 8.0.93) lists glibc-2.3.1, and doesn't include any wine package. Rawhide (the bleeding edge version of RH) doesn't have any wine package either. FWIW, Debian already ships (in unstable) glibc-2.3.1. Somebody using it can tell us if it breaks Wine for them? I don't run Debian unstable, but I /do/ run Gentoo. My glibc version is 2.3.1 (-r2, for those of you who are running Gentoo); WINE works perfectly fine for me. I use it almost daily to play games, etc. AFAIK you need also an nptl enabled kernel to enable the new threading model. This would be an actual 2.5 kernel or a 2.4 kernel from Red Hat's Rawhide or Phoebe. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg17238/pgp0.pgp Description: PGP signature
Re: Started playing with Wineserver on mingw/cygwin again
On Wed, Feb 05, 2003 at 01:47:54PM -0500, Dimitrie O. Paun wrote: On Wed, 5 Feb 2003, Geoff Thorpe wrote: This is an interesting question. I know Ingo Molnar has been (one of) the main developer working on the glibc threading stuff, and I also know he used to follow the Wine project. I am sure he's not indifferent to our To resolve any doubts that Ingo isn't taking care of wine read this: http://lwn.net/Articles/6972/ fate, and being so deeply involved with the glibc changes, he's probably an invaluable resource. Unfortunately, I'm not sure he's even aware of the problem -- has anyone contacted him? Anyone want to do so? (Dan? :)) bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg17240/pgp0.pgp Description: PGP signature
Re: Started playing with Wineserver on mingw/cygwin again
Hello, i hate to reply to myself but here is Ingo's answer: | could you try: | | export LD_ASSUME_KERNEL=2.2.5 | | prior starting up Wine, does this fix the problem for you? | | I'm talking to Alexandre wrt. the threading rewrite - it will be | problematic (release-management wise) but is unavoidable. I'm building now wine on Phoebe and test if the workaround will work, but it will take some time cause the box is only a PII-450. bye michael On Wed, Feb 05, 2003 at 08:14:19PM +0100, Michael Stefaniuc wrote: On Wed, Feb 05, 2003 at 01:47:54PM -0500, Dimitrie O. Paun wrote: On Wed, 5 Feb 2003, Geoff Thorpe wrote: [1] For that matter, has anyone attempted to pull this person into the wine discussion to help flesh this out and find the optimal way forward? Surely any self-respecting (L)GPLer would hate to see a major tool for open source advancement getting hurt over this without so much as some constructive help? This is an interesting question. I know Ingo Molnar has been (one of) the As far as I know he probably reads wine-devel too. main developer working on the glibc threading stuff, and I also know he He did the kernel stuff, the glibc part was done by Ulrich Drepper. used to follow the Wine project. I am sure he's not indifferent to our He even follows rewind . fate, and being so deeply involved with the glibc changes, he's probably an invaluable resource. Unfortunately, I'm not sure he's even aware of the problem -- has anyone contacted him? Anyone want to do so? (Dan? :)) I'll write him an email. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg17241/pgp0.pgp Description: PGP signature
Re: Started playing with Wineserver on mingw/cygwin again
On Wed, Feb 05, 2003 at 01:47:46PM -0800, Francois Gouget wrote: On Wed, 5 Feb 2003, Michael Stefaniuc wrote: Hello, i hate to reply to myself but here is Ingo's answer: | could you try: | | export LD_ASSUME_KERNEL=2.2.5 | | prior starting up Wine, does this fix the problem for you? According to reports on the CrossOver mailing lists this works on Phoebe 1 but does not work anymore on Phoebe 2. Phoebe 2 had kernel-2.4.20-2.21 and that one had some problems with signals. Usable for wine are kernels starting with kernel-2.4.20-2.30. The actual kernel in rawhide is 2.4.20-2.34; i'll test tomorrow wine on Phoebe 2 with the actual kernel. Also it causes Wine to fail on some platforms like SuSE 8.1 so it should not be blindly set. Yet another configure check ... bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg17248/pgp0.pgp Description: PGP signature
Re: move palettes from GDI heap to system heap
On Wed, Feb 05, 2003 at 06:30:21PM -0500, [EMAIL PROTECTED] wrote: ChangeLog: Allocate palette objects on the large heap instead of the GDI heap to avoid GDI heap saturation. This is already in CVS. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg17255/pgp0.pgp Description: PGP signature
Re: Building crosstest ...
Hello!
On Tue, Feb 04, 2003 at 09:08:02AM +, Paul Millar wrote:
Apologies for the rambling email, but here's a bit of a brain-dump. I
don't know how much of this people already know about ...
After banging my head against a wall for the past week or so, I've put
together a script that builds a cross-compiling mingw. The cross-compiler
should be suitable for building .EXE conformance test executables and is
available from:
http://www.astro.gla.ac.uk/users/paulm/Scripts/build-mingw-cross.sh
Thanks for the script.
That should be enough to get mingw for cross-compiling under wine, but
there's still problems with the crosstest target for me.
Using the current CVS, crosstest depends on winebuild. But the
cross-compilation doesn't actually use winebuild. Worse, it fails whilst
trying to building winebuild (missing libraries), if you haven't already
built wine. I guess winebuild is missing some dependencies.
[patch snipped]
fixes this, although I'm not 100% its correct. It stops the .a
libraries from being built, but are they needed for crosstest?
Probably they are needed for things mingw hasn't an .a for like urlmon
but ... having all the *.a in $wine/dlls makes the crosstest build fail
with linker errors:
i586-mingw32msvc-gcc registry.cross.o testlist.cross.o -o advapi32_crosstest.exe
-L../../../ dlls -ladvapi32 -lkernel32 -lntdll -lm
../../../dlls/libmsvcrt.a(ds00432.o)(.text+0x0): multiple definition of `atexit'
/usr/local/mingw/lib/gcc-lib/i586-mingw32msvc/3.2.1/../../../../i586-mingw32msvc/lib/crt2.o(.text+0x230):/home/michi/work/mingw/build-mingw-runtime/../mingw-runtime-2.3/crt1.c:259:
first defined here
../../../dlls/libmsvcrt.a(ds00312.o)(.text+0x0): multiple definition of `_onexit'
/usr/local/mingw/lib/gcc-lib/i586-mingw32msvc/3.2.1/../../../../i586-mingw32msvc/lib/crt2.o(.text+0x250):/home/michi/work/mingw/build-mingw-runtime/../mingw-runtime-2.3/crt1.c:267:
first defined here
So i first do a rm $wine/dlls/*.a before doing make crosstest
After this, it builds the advapi32 tests ok, but there's problems parsing
the files include/winsock{,2}.h when it tries to build the dsound tests...
Francois sent once a patch to fix thix. Should be in the archives.
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
msg17198/pgp0.pgp
Description: PGP signature
Re: infinite loop in msvcrt dll
On Sun, Feb 02, 2003 at 09:05:38PM +0100, Marcus Meissner wrote: On Sun, Feb 02, 2003 at 12:34:53AM +0100, Michael Stefaniuc wrote: Any tips how to debug this further? This is usually a missing function in msvcrt. Run with -debugmsg +seh and check the output directly before the RaiseException. Thanks, that was the problem: _mbsnbcat wasn't implemented (patch to fix this is on the way to wine-patches). What makes me wonder is that i got a loop here; with the missing _mbsnbset and _mbstok the wine debugger started and i could see the cause of the error in the backtrace. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg17083/pgp0.pgp Description: PGP signature
Re: Time
On Thu, Jan 16, 2003 at 01:33:53PM +, Oliver Sampson wrote: Thanks for being gentle. '15:32 +' == '16:32 CET' How's that? +0 is UTC, CET is UTC+1 bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg16556/pgp0.pgp Description: PGP signature
Re: A humble request for help
On Mon, Jan 06, 2003 at 12:29:01PM +0100, Stefan Görling wrote: If there are someone out there who would be willing to answer some more detailed questions, such as how long they've been doing Open Source development as a source of income and how they think it have affected them and their efforts, please drop me a line. I'd be forever greatful. The hall of fame: Dimitrie O. Paun,Unknown / Self-financed Alexandre Julliard,Codeweavers Francois Gouget,Codeweavers Eric Pouech,Unknown / Self-financed Andreas Mohr,Codeweavers Sylvain Petreolle,Unknown / Self-financed Andriy Palamarchuk,Unknown / Self-financed Steven Edwards,Unknown / Self-financed Martin Wilck,Unknown / Self-financed Patrik Stridvall,Unknown / Self-financed Uwe Bonnes,Unknown / Self-financed Dmitry Timoshkov,Codeweavers Greg Turner,Unknown / Self-financed Shachar Shemesh,Unknown / Self-financed Dustin Navea,Unknown / Self-financed Tony Lambregts,Unknown / Self-financed Ove Kaaven,Transgaming Bill Medland,ACCPAC Michael Cardenas,Lindows Lionel Ulmer,Unknown / Self-financed Duane Clark,Unknown / Self-financed Vincent Beron,Unknown / Self-financed Marcus Meissner,SUSE Brett Glass,Unknown / Self-financed Lawson Whitney,Unknown / Self-financed Dan Kegel,Unknown / Self-financed Michael Stefaniuc,RedHat Wrong, my work on Wine is pure hobby and not financed by Red Hat! I'm using the Red Hat mail account only because I'm lazyi: 3 years ago i've thought i could use Wine to run the phone switch configuration program at work, that's why i subscribed to wine-devel. And when i started to work on Wine I already was subcribed to wine-devel with my @redhat.de address and continued to use it. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg16166/pgp0.pgp Description: PGP signature
Re: GlobalAlloc GlobalReAlloc problem
On Sat, Jan 04, 2003 at 02:54:12AM +0100, Michael Stefaniuc wrote:
Do we want to mimic the GlobalAlloc/GlobalReAlloc behaviour of Windows
(the DiMage Viewer dosn't corrupt the images at least on Win98 and it's
the same binary for Win2000 too)? Could be that some other broken, real
life programs are dependent of that behaviour).
At a quick glance i don't know how to fix GlobalAlloc/GlobalReAlloc
without breaking it. I'll do a bugzilla report but want to save me the
work if it will get anyway a WONTFIX resolution.
Well, it wasn't so hard to fix as I first thought. And the patch isn't
too intrusive, it aligns only the storage needed for the HGLOBAL on an
8byte boundary. The only disatvantage is we waste 1 byte per memory
region allocated with GMEM_MOVEABLE but this should be realy tolerable.
Alexandre, i could replace the definition of HGLOBAL_STORAGE with
something like:
#define HGLOBAL_STORAGE ROUND_SIZE(sizeof(HGOBAL))
and use the ROUND_SIZE macro from dlls/ntdll/heap.c . The two magics
-2 in the patch could be also replaced by HGLOBAL_STORAGE/sizeof(HGOBAL)
License: LGPL, X11
Changelog:
Michael Stefaniuc [EMAIL PROTECTED]
- the Minolta DiMAGE Image Viewer relies on Global{,Re}Alloc
called with the GMEM_MOVEABLE flag set, to allocate the exact
specified size and no byte more when size = 8*k, where k=1,2,3,4 .
To achieve this allign the storage needed for the HGLOBAL in
the heap to 8byte boundary.
bye
michael
P.S.: I'll redo the dlls/kernel/tests/alloc.c to have a test case
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
Index: memory/global.c
===
RCS file: /home/wine/wine/memory/global.c,v
retrieving revision 1.74
diff -u -u -r1.74 global.c
--- memory/global.c 2 Jan 2003 17:59:47 - 1.74
+++ memory/global.c 4 Jan 2003 03:50:32 -
@@ -1023,9 +1023,15 @@
#define GLOBAL_LOCK_MAX 0xFF
#define HANDLE_TO_INTERN(h) ((PGLOBAL32_INTERN)(((char *)(h))-2))
#define INTERN_TO_HANDLE(i) ((HGLOBAL) ((i)-Pointer))
-#define POINTER_TO_HANDLE(p) (*(((HGLOBAL *)(p))-1))
+#define POINTER_TO_HANDLE(p) (*(((HGLOBAL *)(p))-2))
#define ISHANDLE(h) (((DWORD)(h)2)!=0)
#define ISPOINTER(h) (((DWORD)(h)2)==0)
+/* allign the storage needed for the HGLOBAL on an 8byte boundary thus
+ * GlobalAlloc/GlobalReAlloc'ing with GMEM_MOVEABLE of memory with
+ * size = 8*k, where k=1,2,3,... alloc's exactly the given size.
+ * The Minolta DiMAGE Image Viewer heavily relies on this, corrupting
+ * the output jpeg's 1 MB if not */
+#define HGLOBAL_STORAGE 8 /* sizeof(HGLOBAL)*2 */
typedef struct __GLOBAL32_INTERN
{
@@ -1070,12 +1076,12 @@
if (!pintern) return 0;
if(size)
{
-if (!(palloc=HeapAlloc(GetProcessHeap(), hpflags, size+sizeof(HGLOBAL {
+if (!(palloc=HeapAlloc(GetProcessHeap(), hpflags, size+HGLOBAL_STORAGE))) {
HeapFree(GetProcessHeap(), 0, pintern);
return 0;
}
*(HGLOBAL *)palloc=INTERN_TO_HANDLE(pintern);
-pintern-Pointer=(char *) palloc+sizeof(HGLOBAL);
+pintern-Pointer=(char *) palloc+HGLOBAL_STORAGE;
}
else
pintern-Pointer=NULL;
@@ -1211,7 +1217,7 @@
maybe_intern = HANDLE_TO_INTERN( handle );
if (maybe_intern-Magic == MAGIC_GLOBAL_USED) {
test = maybe_intern-Pointer;
-if (HeapValidate( GetProcessHeap(), 0, ((HGLOBAL *)test)-1 ) /*
obj(-handle) valid arena? */
+if (HeapValidate( GetProcessHeap(), 0, ((HGLOBAL *)test)-2 ) /*
+obj(-handle) valid arena? */
HeapValidate( GetProcessHeap(), 0, maybe_intern )) /* intern valid
arena? */
break; /* valid moveable block */
}
@@ -1306,25 +1312,25 @@
if(pintern-Pointer)
{
if((palloc = HeapReAlloc(GetProcessHeap(), heap_flags,
- (char *) pintern-Pointer-sizeof(HGLOBAL),
- size+sizeof(HGLOBAL))) == NULL)
+ (char *) pintern-Pointer-HGLOBAL_STORAGE,
+ size+HGLOBAL_STORAGE)) == NULL)
return 0; /* Block still valid */
- pintern-Pointer=(char *) palloc+sizeof(HGLOBAL);
+ pintern-Pointer=(char *) palloc+HGLOBAL_STORAGE;
}
else
{
- if((palloc=HeapAlloc(GetProcessHeap(), heap_flags,
size+sizeof(HGLOBAL)))
+ if((palloc=HeapAlloc(GetProcessHeap(), heap_flags,
+size+HGLOBAL_STORAGE))
== NULL)
return 0;
*(HGLOBAL *)palloc=hmem;
- pintern-Pointer
Re: wine/. configure.ac configure
Hello, i don't think this patch is too correct. I get in the Makefiles following: INSTALL = $(TOPSRCDIR)//usr/bin/install -c $(INSTALL_FLAGS) and that obviously dosn't exist thus make install is failing. bye michael On Mon, Dec 23, 2002 at 06:35:19PM -0600, Alexandre Julliard wrote: ChangeSet ID: 6794 CVSROOT: /opt/cvs-commit Module name: wine Changes by: [EMAIL PROTECTED] 2002/12/23 18:35:19 Modified files: . : configure.ac configure Log message: Make sure INSTALL path is relative to the top dir when using the script in tools/. Patch: http://cvs.winehq.com/patch.py?id=6794 Old revision New revision Changes Path 1.112 1.113 +6 -1 wine/configure.ac 1.380 1.381 +1993 -652 wine/configure -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg15710/pgp0.pgp Description: PGP signature
Re: How long does it take *you* to build wine?
On Sun, Dec 15, 2002 at 10:51:59PM -0800, Dan Kegel wrote: It does look like distributing the load helps a tiny bit, but it's not clear it's a big win over just building on the dual 650MHz machine. The fastest build I've seen so far is 19 minutes. I'm pretty sure I'm not doing things optimally yet. So how long does it take *you* to do a clean build (just the 'make' part after 'make depend', say) of Wine-20021125? On a athlon 900 with 512 MB RAM it takes about 30 minutes for a full build, but only for the first run. On the second run it takes about 3-4 minutes :). Ok, i'm using ccache and it realy paid out during my -DSTRICT work. The cache hit rate had varied between 30% and 80%, depending what i've done. You get 30% - 40% hitrate for normal updates from cvs without doing a make clean. No fair using ccache! That's the next tool I want to investigate; it's probably the biggest win of all, at least for regression testing. I've thought about buying a new computer before i started to use ccache. With ccache i'll wait for the Hammer. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg15497/pgp0.pgp Description: PGP signature
Re: Conformance tests on WinNT
On Wed, Dec 11, 2002 at 09:24:25AM -0600, Jeff Smith wrote: You don't have anyone for Win95? I figured you did. *If* no one else will, I can do this one too, as my linux box is dual boot w/ Win95-OSR2.1 I believe. But if anyone else will take this on, please do, as this box is the Internet gateway for my family. :-/ I have an old box with the first version of Win95 at home and that box is only catching dust. That means i could take ownership for Win95. bye michael On December 11, 2002 09:14 am, Tom Wickline wrote: Were down to ( _1_ ) Win98SE Anyone ?? And what about Win95? -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg15352/pgp0.pgp Description: PGP signature
Re: Screenshots
Hi, On Thu, Nov 21, 2002 at 11:37:50PM -0700, Tony Lambregts wrote: [snip] Other games: Riven - Major screen corruption, Menu doesn't work. Myst - Hell I havent played it for so long I don't realy know whats wrong with it The last time i checked it (4-5 month ago) it worked just fine. I'll check it again. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg14509/pgp0.pgp Description: PGP signature
Re: winewrapper
On Fri, Nov 22, 2002 at 09:45:01AM +0100, Martin Wilck wrote: Am Fre, 2002-11-22 um 00.41 schrieb Dimitrie O. Paun: If Wine was a mature, stable project, I'd agree with you. But it's not. The ability to make a small change in Wine, go back to the Winelib app, and test it, is invaluable. I would have simply given up debugging PuTTY f I had to go through a wine install for every little test and experiment I was making. For me it was quite ok to do a make install only in the dll subdirs where I had modified something. aolme too/aol In the dlls subdirs i also normaly type make install instead of make. Ok, it's a word more to type but it was easier for me to using it in the natural way aka installing wine, then to figure it out how to run it directly from the sources. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg14510/pgp0.pgp Description: PGP signature
Re: wine/ include/x11drv.h include/config.h.in gra ...
On Wed, Nov 20, 2002 at 09:34:20PM +0100, Lionel Ulmer wrote: it seems that this patch introduced a nasty bug (at least for me). With DesktopDoubleBuffered = N wine get's a SIGSEGV, tries to start the debugger, next SIGSEGV looping forever. H, I just tried it here (with my own tree, not with the version merged by Alexandre in CVS but it should be similar) and I have no crash even when setting the option to 'N'. I tried both in Desktop and non-Desktop mode and both work fine. Yes, i couldn't reproduce it myself on a second machine and i started to think that i'm crazy. After the first shock I did a diff of the configs of the two machines and found the needed info to make the bug reproducible: DesktopDoubleBuffered = N AND ScreenDepth = 8 need to be set. Could you run Wine with gdb and in Synchronous mode and attach to the bug report you will raise ( :-) ) or by private mailing me all the information Voila: http://bugs.winehq.com/show_bug.cgi?id=1159 you could obtain at the moment of the crash (ie where it crashes, the value of the display variable, ...). Oh, now that the bug is reprocducible i silently hope(d) you could gather them yourself ;). If you still need my help feel free to shout. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg14395/pgp0.pgp Description: PGP signature
Re: wine/ include/x11drv.h include/config.h.in gra ...
Hello, it seems that this patch introduced a nasty bug (at least for me). With DesktopDoubleBuffered = N wine get's a SIGSEGV, tries to start the debugger, next SIGSEGV looping forever. The SIGSEGV happens in DefaultScreenOfDisplay (X function) called from X11DRV_GDI_Initialize and that one is called by process_attach (x11drv_main.c) . Setting DesktopDoubleBuffered = Y 'fixes' the bug. Any idea? bye michael P.S.: i'll open a bug report but at the moment i'm too tired. On Thu, Nov 14, 2002 at 10:16:39PM -0600, Alexandre Julliard wrote: ChangeSet ID: 6301 CVSROOT: /opt/cvs-commit Module name: wine Changes by: [EMAIL PROTECTED] 2002/11/14 22:16:39 Modified files: include: x11drv.h config.h.in graphics/x11drv: opengl.c dlls/x11drv: x11drv_main.c dlls/opengl32 : Makefile.in dlls/glu32 : Makefile.in dlls/ddraw : Makefile.in dlls/d3d8 : Makefile.in . : configure.ac configure Log message: Lionel Ulmer [EMAIL PROTECTED] Load OpenGL library dynamically from x11drv. Patch: http://cvs.winehq.com/patch.py?id=6301 Old revision New revision Changes Path 1.117 1.118 +3 -1 wine/include/x11drv.h 1.132 1.133 +3 -0 wine/include/config.h.in 1.12 1.13 +79 -22 wine/graphics/x11drv/opengl.c 1.64 1.65 +8 -9 wine/dlls/x11drv/x11drv_main.c 1.12 1.13 +1 -1 wine/dlls/opengl32/Makefile.in 1.3 1.4 +1 -1 wine/dlls/glu32/Makefile.in 1.26 1.27 +1 -1 wine/dlls/ddraw/Makefile.in 1.3 1.4 +1 -1 wine/dlls/d3d8/Makefile.in 1.95 1.96 +6 -3 wine/configure.ac 1.361 1.362 +67 -4 wine/configure -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg14351/pgp0.pgp Description: PGP signature
Re: richedit
On Wed, Oct 30, 2002 at 08:58:54PM -0500, Vincent Béron wrote: Le mer 30/10/2002 à 20:44, Francois Gouget a écrit : On Thu, 31 Oct 2002, Michael Stefaniuc wrote: is somebody working on the richedit dll? I encountered 3 unknown RTF control words and wanted to add them but I got scared by the overzealous use of #define's in rtf.h . My first impuls was exchange that with some enum's, but i thought i better ask here before i do the work in vain. Isn't enum a C++ specific feature? If so then we cannot use it in Wine. No, it's part of standard C. http://www-ccs.ucsd.edu/c/types.html#Enumerations And we already use it quite a lot: brasov:~/work/wine$ find -name \*.h | xargs grep -w -l enum | wc -l 86 bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg13145/pgp0.pgp Description: PGP signature
Re: rpc_H_PL9
On Thu, Oct 31, 2002 at 08:49:18AM -0600, Greg Turner wrote: LICENSE: X11 CHANGELOG: * dlls/rpcrt4: rpc_server.c; include: rpcdcep.h: Greg Turner [EMAIL PROTECTED] - One more fixup for winapi_check -UINT WINAPI I_RpcWindowProc( HANDLE hWnd, UINT Message, UINT wParam, ULONG lParam) +UINT WINAPI I_RpcWindowProc( void *hWnd, UINT Message, UINT wParam, ULONG lParam ) That's totaly broken. It's a problem in winapi_check and not in your code. Well, their is a problem in your code too, i would change HANDLE to HWND. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg13162/pgp0.pgp Description: PGP signature
Re: rpc_H_PL9
On Thu, Oct 31, 2002 at 10:55:10AM -0600, Greg Turner wrote: On Thursday 31 October 2002 09:05 am, Michael Stefaniuc wrote: -UINT WINAPI I_RpcWindowProc( HANDLE hWnd, UINT Message, UINT wParam, ULONG lParam) +UINT WINAPI I_RpcWindowProc( void *hWnd, UINT Message, UINT wParam, ULONG lParam ) That's totaly broken. It's a problem in winapi_check and not in your code. Well, their is a problem in your code too, i would change HANDLE to HWND. bye michael Before I change it back on your advice, are you /sure/ about this? o rpcrt4 compiles STRICT, so how broken can the conflation of HANDLE and void* be? (HWND is DECLARE_HANDLE()'ed so I could see your point there.) HANDLE is a void* therefor compatible to any other pointer, that's why you don't get a warning. o from the Microsoft Platform SDK headers (October '02): ./rpcdcep.h-728-RPCRTAPI ./rpcdcep.h-729-unsigned int ./rpcdcep.h-730-RPC_ENTRY ./rpcdcep.h:731:I_RpcWindowProc( ./rpcdcep.h-732-IN void * hWnd, ./rpcdcep.h-733-IN unsigned int Message, ./rpcdcep.h-734-IN unsigned int wParam, ./rpcdcep.h-735-IN unsigned long lParam ./rpcdcep.h-736-) ; so, technically, isn't void* a /better/ choice? *Sigh* a HWND should be HWND but m$ seems to have decided to do it in an other way. I would say resend the patch but please change the Changelog. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg13183/pgp0.pgp Description: PGP signature
richedit
Hello, is somebody working on the richedit dll? I encountered 3 unknown RTF control words and wanted to add them but I got scared by the overzealous use of #define's in rtf.h . My first impuls was exchange that with some enum's, but i thought i better ask here before i do the work in vain. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg13131/pgp0.pgp Description: PGP signature
DSTRICT: some more fixes for the user dll
Hello,
this fixes 117 warning in the user dll when compiled with -DSTRICT
License: LGPL, X11
Changelog:
Michael Stefaniuc [EMAIL PROTECTED]
- some more fixes for compiling the user dll with -DSTRICT
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
Index: controls/combo.c
===
RCS file: /home/wine/wine/controls/combo.c,v
retrieving revision 1.90
diff -u -u -r1.90 combo.c
--- controls/combo.c29 Oct 2002 21:31:27 - 1.90
+++ controls/combo.c29 Oct 2002 22:53:53 -
@@ -582,7 +582,7 @@
lphc-droppedRect.right -
lphc-droppedRect.left,
lphc-droppedRect.bottom -
lphc-droppedRect.top,
hwnd, (HMENU)ID_CB_LISTBOX,
- GetWindowLongA( hwnd, GWL_HINSTANCE ),
lphc );
+ (HINSTANCE)GetWindowLongA( hwnd,
+GWL_HINSTANCE ), lphc );
else
lphc-hWndLBox = CreateWindowExA(lbeExStyle, ComboLBox, NULL, lbeStyle,
lphc-droppedRect.left,
@@ -590,7 +590,7 @@
lphc-droppedRect.right -
lphc-droppedRect.left,
lphc-droppedRect.bottom -
lphc-droppedRect.top,
hwnd, (HMENU)ID_CB_LISTBOX,
- GetWindowLongA( hwnd, GWL_HINSTANCE ),
lphc );
+ (HINSTANCE)GetWindowLongA( hwnd,
+GWL_HINSTANCE ), lphc );
if( lphc-hWndLBox )
{
@@ -623,14 +623,14 @@
lphc-textRect.right -
lphc-textRect.left,
lphc-textRect.bottom -
lphc-textRect.top,
hwnd, (HMENU)ID_CB_EDIT,
- GetWindowLongA( hwnd,
GWL_HINSTANCE ), NULL );
+ (HINSTANCE)GetWindowLongA( hwnd,
+GWL_HINSTANCE ), NULL );
else
lphc-hWndEdit = CreateWindowExA(0, Edit, NULL, lbeStyle,
lphc-textRect.left,
lphc-textRect.top,
lphc-textRect.right -
lphc-textRect.left,
lphc-textRect.bottom -
lphc-textRect.top,
hwnd, (HMENU)ID_CB_EDIT,
- GetWindowLongA( hwnd,
GWL_HINSTANCE ), NULL );
+ (HINSTANCE)GetWindowLongA( hwnd,
+GWL_HINSTANCE ), NULL );
if( !lphc-hWndEdit )
bEdit = FALSE;
@@ -927,7 +927,8 @@
*/
if (CB_DISABLED(lphc))
{
-hBkgBrush = SendMessageW(lphc-owner, WM_CTLCOLORSTATIC, hDC, (LPARAM)lphc-self
);
+hBkgBrush = (HBRUSH)SendMessageW(lphc-owner, WM_CTLCOLORSTATIC,
+(WPARAM)hDC, (LPARAM)lphc-self );
/*
* We have to change the text color since WM_CTLCOLORSTATIC will
@@ -940,11 +941,13 @@
{
if (lphc-wState CBF_EDIT)
{
- hBkgBrush = SendMessageW(lphc-owner, WM_CTLCOLOREDIT, hDC, (LPARAM)lphc-self
);
+ hBkgBrush = (HBRUSH)SendMessageW(lphc-owner, WM_CTLCOLOREDIT,
+ (WPARAM)hDC, (LPARAM)lphc-self );
}
else
{
- hBkgBrush = SendMessageW(lphc-owner, WM_CTLCOLORLISTBOX, hDC,
(LPARAM)lphc-self );
+ hBkgBrush = (HBRUSH)SendMessageW(lphc-owner, WM_CTLCOLORLISTBOX,
+ (WPARAM)hDC, (LPARAM)lphc-self );
}
}
@@ -1946,14 +1949,14 @@
case WM_PRINTCLIENT:
if (lParam PRF_ERASEBKGND)
- COMBO_EraseBackground(hwnd, lphc, wParam);
+ COMBO_EraseBackground(hwnd, lphc, (HDC)wParam);
/* Fallthrough */
case WM_PAINT:
/* wParam may contain a valid HDC! */
- return COMBO_Paint(lphc, wParam);
+ return COMBO_Paint(lphc, (HDC)wParam);
case WM_ERASEBKGND:
- return COMBO_EraseBackground(hwnd, lphc, wParam);
+ return COMBO_EraseBackground(hwnd, lphc, (HDC)wParam);
case WM_GETDLGCODE:
{
LRESULT result = DLGC_WANTARROWS | DLGC_WANTCHARS;
@@ -1980,7 +1983,7 @@
!(lphc-wState CBF_NORESIZE) ) COMBO_Size( lphc );
return TRUE;
case WM_SETFONT:
- COMBO_Font
Re: DSTRICT: some more fixes for the user dll
I apologize for sending this to the wrong list. remorseful michael On Wed, Oct 30, 2002 at 12:02:05AM +0100, Michael Stefaniuc wrote: Hello, this fixes 117 warning in the user dll when compiled with -DSTRICT License: LGPL, X11 Changelog: Michael Stefaniuc [EMAIL PROTECTED] - some more fixes for compiling the user dll with -DSTRICT bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg13043/pgp0.pgp Description: PGP signature
Re: winsock + DSTRICT
Hello Martin,
On Mon, Oct 28, 2002 at 04:07:46PM +0100, Martin Wilck wrote:
here is a patch to make winsock compile without warnings without
-DWINE_NO_STRICT. Comments are welcome.
Well, i looked at the patch and it seems resonable. You are the winsock
expert and if you feel confortable with it please submit it to
wine-patches (Alexandre will complain if he dosn't like it ;). One
request: i'm not sure if the compiler will optimize away the assert
from __handle2socket on machines where sizeof(HANDLE) == sizeof(SOCKET).
But if not could you please add something like
if (sizeof(HANDLE) sizeof(SOCKET)) {
assert(
}
On i386 the size are equal and the assert not needed.
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
msg12980/pgp0.pgp
Description: PGP signature
Re: Whats done? not?
Hi! On Fri, Oct 25, 2002 at 06:20:56AM +, Christensen Tom wrote: Obviously wine is still being actively developed, and I know its not close to done however, I want to get involved, I know C/C++ and have a pretty good grasp of windows apis, I'm just wondering is there a place (kinda like in the Mono project they have a tree laid out with all of the classes/functions that are in the .NET runtime, and they have them marked done, being worked on, not started...) So I'm wondering if wine has anything similar? or should i just pick a function, and see if its done Well, such a page dosn't exist but you can get that info i some different ways: - functions not implemented at all: find $path_to_wine -name \*.spec | xargs grep stub - grep for FIXME for not fully/corect implemented functions - take a look at http://bugs.winehq.com, especialy at the Tasklists - or take your favorite windows program and make it run perfectly already by searching through the source? At any rate, wine should have a nice concise place to look and see if wine has certain functions implimented.. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg12718/pgp0.pgp Description: PGP signature
Re: DSTRICT: LZexpand
It seems to look good and i'm very happy about it: i almost can't see that stuff anymore. bye michael On Sat, Oct 26, 2002 at 12:05:16AM +0100, Matthew Davison wrote: This is my first patch to wine so if it is wrong please dont chew me up anyway, here goes. ChangeLog: Made LZexpand compile with DSTRICT defined. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg12849/pgp0.pgp Description: PGP signature
Status Report: -DSTRICT
Hello, status reports seems to be pretty popular this day so here is mine regarding compiling wine with -DSTRICT. Below is the amount of warnings we get when removing -DWINE_NO_STRICT: dll realtotal -- commdlg 21 63 gdi 128 273 ntdll 148 178 ole3216 38 shell32 120 155 user450 839 winmm/wavemap 7 40 winmm 104 145 winsock 14 42 x11drv 60 79 -- total 10681852 real is the number of warning for which real work is need to be done, the rest up to total are warnings of the type int format, HANDLE arg. And to fix this beasts just grab http://people.redhat.com/mstefani/wine/fixpointerarg.pl and do: cd wine/dlls/$dll_in_work make clean make 21 | fixpointerarg.pl and you should be done. Happy hacking bye michael P.S.: a request from Eric: please let him finish the 32bit - 16bit separation of winmm. After that is yours. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg12852/pgp0.pgp Description: PGP signature
compile with -DSTRICT
Hello,
i'm not 100% sure what -DWINE_NO_STRICT should do, but i suspect it
should negate the effect of -DSTRICT. The attached patch enables that
and lets wine compile with -DSTRICT where WINE_NO_STRICT isn't defined.
Comments?
bye
michael
P.S.: is this -DSTRICT a m$ windows thing or a wine only thing?
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
Index: Make.rules.in
===
RCS file: /home/wine/wine/Make.rules.in,v
retrieving revision 1.131
diff -u -r1.131 Make.rules.in
--- Make.rules.in 19 Oct 2002 17:15:00 - 1.131
+++ Make.rules.in 21 Oct 2002 19:31:47 -
@@ -25,7 +25,7 @@
CC= @CC@
CPP = @CPP@
CFLAGS= @CFLAGS@ $(EXTRACFLAGS)
-OPTIONS = @OPTIONS@ -D_REENTRANT
+OPTIONS = @OPTIONS@ -D_REENTRANT -DSTRICT
LIBS = @LIBS@
YACC = @YACC@
LEX = @LEX@
Index: include/winnt.h
===
RCS file: /home/wine/wine/include/winnt.h,v
retrieving revision 1.134
diff -u -r1.134 winnt.h
--- include/winnt.h 19 Oct 2002 17:20:02 - 1.134
+++ include/winnt.h 21 Oct 2002 19:31:48 -
@@ -561,14 +561,14 @@
* we're ready we'll remove the '!defined(__WINE__)' (the equivalent
* of converting it from DECLARE_OLD_HANDLE to DECLARE_HANDLE).
*/
-#if defined(__WINE__) defined(WINE_NO_STRICT)
-typedef UINT HANDLE;
-#else
+#if defined(STRICT) !defined(WINE_NO_STRICT)
typedef void *HANDLE;
+#else
+typedef UINT HANDLE;
#endif
typedef HANDLE *PHANDLE, *LPHANDLE;
-#if defined(STRICT) || (defined(__WINE__) !defined(WINE_NO_STRICT))
+#if defined(STRICT) !defined(WINE_NO_STRICT)
#define DECLARE_HANDLE(a) \
typedef struct a##__ { int unused; } *a; \
typedef a *P##a
Index: include/wine/server_protocol.h
===
RCS file: /home/wine/wine/include/wine/server_protocol.h,v
retrieving revision 1.46
diff -u -r1.46 server_protocol.h
--- include/wine/server_protocol.h 18 Oct 2002 23:46:28 - 1.46
+++ include/wine/server_protocol.h 21 Oct 2002 19:31:49 -
@@ -32,7 +32,7 @@
int pad[16];
};
-#if defined(STRICT) || (defined(__WINE__) !defined(WINE_NO_STRICT))
+#if defined(STRICT) !defined(WINE_NO_STRICT)
typedef void *obj_handle_t;
typedef void *user_handle_t;
#else
Index: dlls/twain/ds_image.c
===
RCS file: /home/wine/wine/dlls/twain/ds_image.c,v
retrieving revision 1.2
diff -u -r1.2 ds_image.c
--- dlls/twain/ds_image.c 31 May 2002 23:40:53 - 1.2
+++ dlls/twain/ds_image.c 21 Oct 2002 19:31:49 -
@@ -276,7 +276,7 @@
sane_cancel (pSource-deviceHandle);
ReleaseDC (pSource-hwndOwner, dc);
-*pHandle = hDIB;
+*pHandle = (TW_UINT32)hDIB;
twRC = TWRC_XFERDONE;
pSource-twCC = TWCC_SUCCESS;
pSource-currentState = 7;
msg12586/pgp0.pgp
Description: PGP signature
DECLARE_OLD_HANDLE ?
Hello Alexandre, any reason why you haven't removed DECLARE_OLD_HANDLE? It's now with the per dll -DSTRICT compilation IMO useless. Changing the remaining DECLARE_OLD_HANDLE's to DECLARE_HANDLE didn't changed the compile output. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg12545/pgp0.pgp Description: PGP signature
Re: PATCH: compile fix (when all handles are void*)
On Wed, Oct 16, 2002 at 04:36:53PM -0700, Alexandre Julliard wrote: Michael Stefaniuc [EMAIL PROTECTED] writes: I'm almost finished a short perl script to automaticly convert the int format, HANDLE arg warnings, which would leave us with the other 1343 warnings. Wine compiles and even seems to run so if Alexander would like to speed up the conversion he could change the remaining handles to void*, add -DSTRICT and hope that the some people get annoyed with the warnings and submit patches. But i don't recommend it (yet). No, I don't think we want that. But one thing we could do is to compile individual dlls with -DSTRICT, so that we can fix them one at a time; this would avoid having to do a huge patch that changes the format strings all over the tree at the same time. I can do the needed Makefile magic if you'd like to try this approach. Interesting approach, i've thought about starting to fix whole dlls first, but not about compiling them separately with -DSTRICT. I need to think more about it (after getting some sleep) and do some testing. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg12483/pgp0.pgp Description: PGP signature
Re: Changes in Bitmap behaviour
On Fri, Oct 11, 2002 at 12:13:48PM +0200, Uwe Bonnes wrote: Content-Description: message body and .signature Xilinx webpack 4.2 running with native Common Controls shows an artefact in the display of bitmaps associated with the listview widget. This behaviour changed with http://cvs.winehq.com/patch.py?id=5720 by Michael Stefaniuc [EMAIL PROTECTED], but still is not right. Appended I have jpegs of the error. The first file (comctl32-builtin.jpeg) shows the behaviour with builtin commctl32, which looks good. The second file (comctl32-native-prepatch.jpeg) shows the behaviour with todays cvs, Michael's patch reversed and native comctl32/commctrl (NT4). We get a discontinous black background of the bitmap The last file (comctl32-native-prepatch.jpeg) is with native comctl32/commctrl (NT4) and todays unmodified cvs version. No we have a all black background. Well, the only real changes in the patch are in windows/cursoricon.c and the move the implementation of ExtractAssociatedIcon16 to ExtractAssociatedIconA. The rest are only explicit handle conversions that were done implicitly before by the compiler. Could you please revert only the changes in windows/cursoricon.c and see it that fixes your problem? bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg12350/pgp0.pgp Description: PGP signature
Re: help! latest cvs build of wine crashes every time
On Sun, Oct 13, 2002 at 10:09:48PM +1000, Graham Stoney wrote: On Sun, Oct 13, 2002 at 01:58:03PM +0200, Uwe Bonnes wrote: Did you set synchronous mode in the ~/.wine/config [x11drv] section: Synchronous = y I have now; doesn't seem to help though. Any other suggestions? I had this problems too, and a 'make clean' fixed it for me. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg12791/pgp0.pgp Description: PGP signature
Re: 16 shell seperation
I'm terrible sorry for this email, but i'm ill and seeing the
16-functions the HKEY16's started to dance in front of my eyes ... but
they aren't there :/
bye
michael
On Sun, Oct 13, 2002 at 01:23:06AM +0200, Michael Stefaniuc wrote:
You forgot to do the right HKEY -- HKEY16 conversions with HKEY_16() and
HKEY_32(), examples how to do it should be in the code.
bye
michael
On Sat, Oct 12, 2002 at 05:20:31PM -, György 'Nog' Jeney wrote:
Is it possible to move all of the resources in the shell32 directory to a
sub directory inside shell32 like resources (just like gdi)? Its quite
confusing the way it is now.
Changelog:
* dlls/shell32/shell32_main.h
* dlls/shell32/shell.c
* dlls/shell32/shellreg.c
* dlls/shell32/Makefile.in
* dlls/shell32/shlexec.c
Seperate out 16-bit funvtions into seperate file.
nog.
Index: dlls/shell32/shell.c
===
RCS file: /home/wine/wine/dlls/shell32/shell.c,v
retrieving revision 1.46
diff -u -r1.46 shell.c
--- dlls/shell32/shell.c10 Oct 2002 21:22:11 - 1.46
+++ dlls/shell32/shell.c12 Oct 2002 17:07:39 -
@@ -2,6 +2,7 @@
* Shell Library Functions
*
* Copyright 1998 Marcus Meissner
+ * Copyright 2000 Juergen Schmied
* Copyright 2002 Eric Pouech
*
* This library is free software; you can redistribute it and/or
@@ -526,4 +527,115 @@
break;
}
return ret;
+}
+
+
+/* 0 and 1 are valid rootkeys in win16 shell.dll and are used by
+ * some programs. Do not remove those cases. -MM
+ */
+static inline void fix_win16_hkey( HKEY *hkey )
+{
+if (*hkey == 0 || *hkey == (HKEY)1) *hkey = HKEY_CLASSES_ROOT;
+}
+
+/**
+ * RegOpenKey [SHELL.1]
+ */
+DWORD WINAPI RegOpenKey16( HKEY hkey, LPCSTR name, PHKEY retkey )
+{
+fix_win16_hkey( hkey );
+return RegOpenKeyA( hkey, name, retkey );
+}
+
+/**
+ * RegCreateKey [SHELL.2]
+ */
+DWORD WINAPI RegCreateKey16( HKEY hkey, LPCSTR name, PHKEY retkey )
+{
+fix_win16_hkey( hkey );
+return RegCreateKeyA( hkey, name, retkey );
+}
+
+/**
+ * RegCloseKey [SHELL.3]
+ */
+DWORD WINAPI RegCloseKey16( HKEY hkey )
+{
+fix_win16_hkey( hkey );
+return RegCloseKey( hkey );
+}
+
+/**
+ * RegDeleteKey [SHELL.4]
+ */
+DWORD WINAPI RegDeleteKey16( HKEY hkey, LPCSTR name )
+{
+fix_win16_hkey( hkey );
+return RegDeleteKeyA( hkey, name );
+}
+
+/**
+ * RegSetValue [SHELL.5]
+ */
+DWORD WINAPI RegSetValue16( HKEY hkey, LPCSTR name, DWORD type, LPCSTR data,
DWORD count )
+{
+fix_win16_hkey( hkey );
+return RegSetValueA( hkey, name, type, data, count );
+}
+
+/**
+ * RegQueryValue [SHELL.6]
+ *
+ * NOTES
+ *Is this HACK still applicable?
+ *
+ * HACK
+ *The 16bit RegQueryValue doesn't handle selectorblocks anyway, so we just
+ *mask out the high 16 bit. This (not so much incidently) hopefully fixes
+ *Aldus FH4)
+ */
+DWORD WINAPI RegQueryValue16( HKEY hkey, LPCSTR name, LPSTR data, LPDWORD count
+)
+{
+fix_win16_hkey( hkey );
+if (count) *count = 0x;
+return RegQueryValueA( hkey, name, data, count );
+}
+
+/**
+ * RegEnumKey [SHELL.7]
+ */
+DWORD WINAPI RegEnumKey16( HKEY hkey, DWORD index, LPSTR name, DWORD name_len )
+{
+fix_win16_hkey( hkey );
+return RegEnumKeyA( hkey, index, name, name_len );
+}
+
+
+/*
+ * ShellExecute[SHELL.20]
+ */
+HINSTANCE16 WINAPI ShellExecute16( HWND16 hWnd, LPCSTR lpOperation,
+ LPCSTR lpFile, LPCSTR lpParameters,
+ LPCSTR lpDirectory, INT16 iShowCmd )
+{
+SHELLEXECUTEINFOA sei;
+HANDLE hProcess = 0;
+
+sei.cbSize = sizeof(sei);
+sei.fMask = 0;
+sei.hwnd = HWND_32(hWnd);
+sei.lpVerb = lpOperation;
+sei.lpFile = lpFile;
+sei.lpParameters = lpParameters;
+sei.lpDirectory = lpDirectory;
+sei.nShow = iShowCmd;
+sei.lpIDList = 0;
+sei.lpClass = 0;
+sei.hkeyClass = 0;
+sei.dwHotKey
Re: 16 shell seperation
= lpDirectory; -sei.nShow = iShowCmd; -sei.lpIDList = 0; -sei.lpClass = 0; -sei.hkeyClass = 0; -sei.dwHotKey = 0; -sei.hProcess = hProcess; - -ShellExecuteExA32 (sei, FALSE); -return (HINSTANCE16)sei.hInstApp; -} - /* * ShellExecuteA [SHELL32.290] */ -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg12777/pgp0.pgp Description: PGP signature
include/cursoricon.h
Hello, the conversion of HICON to void* seems to be a hard one ... while trying to do that i found that msdn dosn't know anything about include/cursoricon.h, it seems to be an internal header and therefor should go to dlls/user/ or at least to include/wine. I could do a patch for that. An other question: in windows/cursoricon.c there are some internal functions, that are using a HGLOBAL for a HICON or HCURSOR. I would change that to HICON because HCURSOR is compatible to HICON and HGLOBAL seems too generic (HGLOBAL is a HANDLE and thus wont catch any handle conflicts). bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg12124/pgp0.pgp Description: PGP signature
Re: dlls/ completion nit
On Fri, Sep 27, 2002 at 02:55:45PM -0400, Dimitrie O. Paun wrote: You'll probably think I'm crazy, but here it goes :) : Nah, we think only you have to much spare time :) I work a *lot* from the the command line, and I depend quite a bit on completion. Problem is, all those xxx.dll.so links in dlls/ are screwing with it sometimes, as is the case for avifile.dll.so, etc. Even when the dir name is a proper prefix of the link, it's still annoying as I don't get the / completed automatically, then I hesitate whether to add it or not, and so on. So my small proposal: what about creating them in a sub dir, say dlls/lib or something like that? I'd be willing to cook up a patch, if people are OK with the idea. ;) I would like it. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg12083/pgp0.pgp Description: PGP signature
Re: RFC: Winsock todo's
On Tue, Sep 24, 2002 at 11:18:14AM +0200, Martin Wilck wrote: Am Die, 2002-09-24 um 10.55 schrieb Martin Wilck: I forgot one: There are planse to convert the HANDLE type to void* throughout wine. http://bugs.winehq.com/long_list.cgi?buglist=90 Yes, i'm slowly working on that. HANDLE will be the last one to be changed and i hope to have it finished at the end of the year. If this happens, Winsock needs to be adapted, too. Under Windows, SOCKET is an int type and HANDLE is void*, nevertheless it is legal to pass SOCKETs to functions such as WriteFile() expecting HANDLERs. I am uncertain how to do The Right Thing (tm) for Winsock here. Simple, just cast it to HANDLE. I suspect this what you need to do on Windows too, especialy when using C++. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11934/pgp0.pgp Description: PGP signature
Re: FD_ZERO and FD_SET problems.
Could you please resubmit it as unified diff (diff -u)? The diff's are more readable and are more robust regarding to changes in the target file. bye michael On Fri, Sep 20, 2002 at 08:10:41PM -1000, Patrick J. McNerthney wrote: I hope I am doing this correctly. I am porting some Win32 software using WineLib and ran into some problems with the WinSock headers, specifically with regards to the use of FD_ZERO and FD_SET (they just wouldn't compile at all). Attached is the patch that resolved my problems. ChangeLog Fixed if statement in __WS_FD_SET2 which did not have it's outer set of parenthesis. Removed parentheses around type to be cast in __WS_FD_SET macro. Removed WS macro usage from within other macros because the WS macro is undefined when these macros are expanded. Pat McNerthney Icicle Software, Inc. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11886/pgp0.pgp Description: PGP signature
Re: HRGN
On Sat, Sep 21, 2002 at 01:10:06AM -0400, Dimitrie O. Paun wrote: On September 20, 2002 06:59 pm, Michael Stefaniuc wrote: On Fri, Sep 20, 2002 at 05:15:10PM -0400, Dimitrie O. Paun wrote: Oddly enough, this seem to work... STOP! It dosn't work: Yes, I knew something was wrong -- I did recompile, but I guess make screwed up... Why that is, I don't know. Sorry about that. Do you compile with -DSTRICT? Because if not DECLARE_HANDLE and DECLARE_OLD_HANDLE are the same. Or do you use ccache to speed up wine compilation? I've seen with it some make problems and had to do an export CCACHE_NOLINK=1. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11868/pgp0.pgp Description: PGP signature
Re: [OT] site down?
On Wed, Sep 18, 2002 at 12:34:56PM +0100, Paul Millar wrote: I can ping www.winehq.com, but can't load http://www.winehq.com/ (or any other page). Instead, I get a connection refused back from the local proxy. Also, email to [EMAIL PROTECTED] is not being delivered (connection problems again). Looks like a server problem, so could someone give it a kick? Don't know if someone kicked the server but it works for me. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11814/pgp0.pgp Description: PGP signature
Re: PATCH: almost ready with the conversion of HWND to a void*
On Fri, Sep 06, 2002 at 12:58:34PM -0700, Alexandre Julliard wrote: Michael Stefaniuc [EMAIL PROTECTED] writes: the attached patch is independent of the previous sent HWND4.diff and should almost finish the conversion of HWND to a void*. There are still some warning: assignment makes pointer from integer without a cast but they occur between SERVER_START_REQ and SERVER_END_REQ and i didn't figured out to what to cast the HWND's (that code is a little bit too obfuscated for me). Actually you don't need to cast them at all. When handles are made void* server handles will be void* too so it will all work fine. Cool. After applying HWND5.diff you can switch than to DECLARE_HANDLE(HWND). bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11562/pgp0.pgp Description: PGP signature
Re: removing mp3 code
Hello, On Thu, Aug 29, 2002 at 10:52:34AM +0200, Marcus Meissner wrote: Apparently distributing even mp3 decoders is not royaltee free anymore, according to the slashdot thread and the Thomson MultiMedia pages. So we probably should remove the msacm mp3 decoder we include. :( I would wait with that, because every day you get an other information. Have a look at http://www.heise.de/newsticker/data/vza-29.08.02-000/ bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11416/pgp0.pgp Description: PGP signature
New win api docs
Hello, here is the documentation for the API's that m$ had to disclose after the settlement: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnapiover/html/api-overview.asp bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11389/pgp0.pgp Description: PGP signature
Re: New win api docs
On Wed, Aug 28, 2002 at 08:16:36AM -0400, tom wrote: Dmitry Timoshkov wrote: Michael Stefaniuc [EMAIL PROTECTED] wrote: here is the documentation for the API's that m$ had to disclose after the settlement: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnapiover/html/api-overview.asp And nothing regarding undocumented comctl32 interfaces... Almost all disclosed APIs are already known or useless. Yea here is a nice link : http://www.theregister.co.uk/content/4/26803.html It tell's the real story about the API documentation ;-) Yes, i've seen it too on http://www.heise.de/newsticker/data/ps-28.08.02-000/ (in german only) but sent the email before I've read the lower part of the message (sorry to have spamed the list). bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11394/pgp0.pgp Description: PGP signature
Re: extremely simple borland C builder app hangs
On Sun, Aug 25, 2002 at 09:03:31PM +0200, Sylvain Petreolle wrote: snip fixme:commctrl:FlatSB_SetScrollProp stub fixme:commctrl:InitializeFlatSB stub did you look at MSDN if these 2 stubs aren't the cause of your problem ? This shouldn't be a problem at all because FlatScrollBar controll defaults to the ScrollBar controll if the FlatScrollBar wasn't initialized. This behaviour is documented by msdn. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11345/pgp0.pgp Description: PGP signature
Re: PATCH: Convert HMIDI to void*
On Thu, Aug 01, 2002 at 09:13:40AM +0200, Eric Pouech wrote:
Michael Stefaniuc a écrit :
Hello,
am I right that HMIDI and HMIDIIN, HMIDIOUT shouldn't be
interchangeable? Would save some conversions.
License: LGPL, X11
Changelog:
Michael Stefaniuc [EMAIL PROTECTED]
Convert HMIDI to a void*
I just modified a bit Michael's patch:
- better fix for midimap file
- changed all HMIDI
Alexandre, use this version instead.
No, use my version instead ;) (it's attached). It proper handles
HMIDI*16 - HMIDI* conversions.
The patch is based on Eric patch which is based on my patch ...
License: LGPL, X11
Changelog:
Eric Pouech [EMAIL PROTECTED]
Michael Stefaniuc [EMAIL PROTECTED]
- Convert HMIDI, HMIDIIN, HMIDIOUT, HMIDISTRM to void*
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
Index: dlls/winmm/lolvldrv.c
===
RCS file: /home/wine/wine/dlls/winmm/lolvldrv.c,v
retrieving revision 1.29
diff -u -r1.29 lolvldrv.c
--- dlls/winmm/lolvldrv.c 3 Jul 2002 21:10:44 - 1.29
+++ dlls/winmm/lolvldrv.c 1 Aug 2002 14:07:20 -
@@ -693,7 +693,7 @@
*(LPDWORD)((char*)ptr + sizeof(LPMIDIOPENDESC)) = *lpdwUser;
mod16 = (LPMIDIOPENDESC16)((LPSTR)ptr + sizeof(LPMIDIOPENDESC) +
2*sizeof(DWORD));
- mod16-hMidi = mod32-hMidi;
+ mod16-hMidi = LOWORD(mod32-hMidi);
mod16-dwCallback = mod32-dwCallback;
mod16-dwInstance = mod32-dwInstance;
mod16-dnDevNode = mod32-dnDevNode;
Index: dlls/winmm/mmsystem.c
===
RCS file: /home/wine/wine/dlls/winmm/mmsystem.c,v
retrieving revision 1.63
diff -u -r1.63 mmsystem.c
--- dlls/winmm/mmsystem.c 29 Jul 2002 23:29:23 - 1.63
+++ dlls/winmm/mmsystem.c 1 Aug 2002 14:07:20 -
@@ -48,6 +48,10 @@
WINE_DEFAULT_DEBUG_CHANNEL(mmsys);
+#define HMIDIIN_32(h16)((HMIDIIN)(ULONG_PTR)(h16))
+#define HMIDIOUT_32(h16) ((HMIDIOUT)(ULONG_PTR)(h16))
+#define HMIDISTRM_32(h16) ((HMIDISTRM)(ULONG_PTR)(h16))
+
static LPWINE_MM_IDATA lpFirstIData = NULL;
static LPWINE_MM_IDATA MULTIMEDIA_GetIDataNoCheck(void)
@@ -2188,7 +2192,7 @@
*lphMidiOut = hMidiOut;
if (lpwm) {
- lpwm-mod.hMidi = hMidiOut;
+ lpwm-mod.hMidi = (HMIDI) hMidiOut;
lpwm-mod.dwCallback = *lpdwCallback;
lpwm-mod.dwInstance = *lpdwInstance;
lpwm-mod.dnDevNode = 0;
@@ -2255,7 +2259,7 @@
ret = MMSYSTEM_midiOutOpen(hmo, uDeviceID, dwCallback, dwInstance,
dwFlags, FALSE);
-if (lphMidiOut != NULL) *lphMidiOut = hmo;
+if (lphMidiOut != NULL) *lphMidiOut = LOWORD(hmo);
return ret;
}
@@ -2283,7 +2287,7 @@
*/
UINT16 WINAPI midiOutClose16(HMIDIOUT16 hMidiOut)
{
-return midiOutClose(hMidiOut);
+return midiOutClose(HMIDIOUT_32(hMidiOut));
}
/**
@@ -2381,7 +2385,7 @@
*/
UINT16 WINAPI midiOutShortMsg16(HMIDIOUT16 hMidiOut, DWORD dwMsg)
{
-return midiOutShortMsg(hMidiOut, dwMsg);
+return midiOutShortMsg(HMIDIOUT_32(hMidiOut), dwMsg);
}
/**
@@ -2437,7 +2441,7 @@
*/
UINT16 WINAPI midiOutReset16(HMIDIOUT16 hMidiOut)
{
-return midiOutReset(hMidiOut);
+return midiOutReset(HMIDIOUT_32(hMidiOut));
}
/**
@@ -2503,7 +2507,8 @@
UINT16 WINAPI midiOutCachePatches16(HMIDIOUT16 hMidiOut, UINT16 uBank,
WORD* lpwPatchArray, UINT16 uFlags)
{
-return midiOutCachePatches(hMidiOut, uBank, lpwPatchArray, uFlags);
+return midiOutCachePatches(HMIDIOUT_32(hMidiOut), uBank, lpwPatchArray,
+ uFlags);
}
/**
@@ -2739,7 +2744,7 @@
if (lpwm == NULL)
return MMSYSERR_NOMEM;
-lpwm-mod.hMidi = hMidiIn;
+lpwm-mod.hMidi = (HMIDI) hMidiIn;
lpwm-mod.dwCallback = dwCallback;
lpwm-mod.dwInstance = dwInstance;
@@ -2778,7 +2783,7 @@
ret = MMSYSTEM_midiInOpen(xhmid, uDeviceID, dwCallback, dwInstance,
dwFlags, FALSE);
-if (lphMidiIn) *lphMidiIn = xhmid;
+if (lphMidiIn) *lphMidiIn = LOWORD(xhmid);
return ret;
}
@@ -2805,7 +2810,7 @@
*/
UINT16 WINAPI midiInClose16(HMIDIIN16 hMidiIn)
{
-return midiInClose(hMidiIn);
+return midiInClose(HMIDIIN_32(hMidiIn
Re: PATCH: Convert HMIDI to void*
On Wed, Jul 31, 2002 at 10:11:51PM +0200, Eric Pouech wrote: Michael Stefaniuc a écrit : am I right that HMIDI and HMIDIIN, HMIDIOUT shouldn't be interchangeable? Would save some conversions. yes no HMIDIIN cannot be used for a HMIDIOUT (anyway, this will be checked internally by our mmsys implementation: all HMIDI handles are stored in the same table, and we never rely on the HMIDI??? handle type but on the actual object type) however, HMIDI can be used for a HMIDIIN (or HMIDIOUT or HMIDISTRM) handle (see midiConnect for example) I expressed myself wrong, with interchangable i meant having typedef HMIDI HMIDIIN typedef HMIDI HMIDIOUT typedef HMIDI HMIDISTRM in include/mmsystem.h instead of DECLARE_HANDLE(HMIDIIN); DECLARE_HANDLE(HMIDIOUT); DECLARE_HANDLE(HMIDISTRM); I've suspected what you have described from reading the code (but it's always good to get confirmation). it's true that midimap dll should use HMIDIOUT instead of HMIDI in its internal data structure Do you want me to change that? bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11095/pgp0.pgp Description: PGP signature
Re: PATCH: Convert HMIDI to void*
On Wed, Jul 31, 2002 at 02:25:08PM -0700, Francois Gouget wrote: On Wed, 31 Jul 2002, Michael Stefaniuc wrote: [...] I expressed myself wrong, with interchangable i meant having typedef HMIDI HMIDIIN typedef HMIDI HMIDIOUT typedef HMIDI HMIDISTRM in include/mmsystem.h instead of DECLARE_HANDLE(HMIDIIN); DECLARE_HANDLE(HMIDIOUT); DECLARE_HANDLE(HMIDISTRM); I just checked and the windows headers declare the HMIDI* handles using the DECLARE_HANDLE macro. So that's the way we should do it too. That means my patch is valid and can be applied. Could you please verify that HWAVE HWAVEIN HWAVEOUT HMIXER HMIXEROBJ are also declared with the DECLARE_HANDLE macro? I don't have the windows headers. thanks bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11097/pgp0.pgp Description: PGP signature
bugzilla privs
Hello, could somebody please give me the necessary privs so I can take ownership of wine bugs (account [EMAIL PROTECTED]). If not please close bugs #483, #489, #502. thanks bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11062/pgp0.pgp Description: PGP signature
Re: CallNextHookEx16 strageness
On Tue, Jul 23, 2002 at 03:18:04PM -0700, Alexandre Julliard wrote:
Michael Stefaniuc [EMAIL PROTECTED] writes:
It seems that we don't have an implicit transformation of a HHOOK to a
HANDLE16. Most of the internal HOOK_* functions are using HANDLE16's and
the few functions that accepts as parameter a HHOOK are checking for the
presence of the HOOK_MAGIC and are doing the conversion to a HANDLE16
with LOWORD(hhook).
Well yes, the hook functions are mostly using HANDLE16 internally, but
it would be much better to change them to use HHOOK. There isn't much
point in making HHOOK work with -DSTRICT if we don't use it anywhere.
Hmm ... looking at windows/hook.c i guess that we have to keep using
with HOOKDATA, MESSAGEQUEUE, USER_HEAP_LIN_ADDR, etc. and this ones are
using HANDLE16. HOOK_systemHooks could be changed to HHOOK, but this
would introduce a lot of conversions.
I've changed all internal HOOK_* functions to pass only HHOOK's to each
other. I've kept the use of HANDLE16 in functions that make extensive
use of HOOKDATA and MESSAGEQUEUE but changed the variables name from
hook to handle to not produce confusion.
-return CallNextHookEx16( WH_SHELL, code, wParam, lParam );
+return CallNextHookEx16( (HHOOK)MAKELONG(WH_SHELL, HOOK_MAGIC), code,
+ wParam, lParam );
WH_SHELL is not a valid hook handle, this code is broken (of course it
was broken before too).
ShellHookProc is only a win win95 function and I couldn't find any
documentation for it (searching on msdn revealed nothing) so i've made a
separat patch for it, but it's a pure guesstimation.
License: LGPL, X11
Changelog:
Michael Stefaniuc [EMAIL PROTECTED]
- converted HHOOK to a void*
- changed the internal HOOK_* functions to pass only HHOOK's between
them
- fixed wrong HHOOK - HANDLE16 conversions
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
Index: include/windef.h
===
RCS file: /home/wine/wine/include/windef.h,v
retrieving revision 1.65
diff -u -r1.65 windef.h
--- include/windef.h19 Jul 2002 00:28:13 - 1.65
+++ include/windef.h27 Jul 2002 17:13:00 -
@@ -79,7 +79,7 @@
DECLARE_HANDLE(HDESK);
DECLARE_OLD_HANDLE(HENHMETAFILE);
DECLARE_OLD_HANDLE(HFONT);
-DECLARE_OLD_HANDLE(HHOOK);
+DECLARE_HANDLE(HHOOK);
DECLARE_OLD_HANDLE(HICON);
DECLARE_OLD_HANDLE(HINSTANCE);
DECLARE_OLD_HANDLE(HKEY);
Index: windows/hook.c
===
RCS file: /home/wine/wine/windows/hook.c,v
retrieving revision 1.35
diff -u -r1.35 hook.c
--- windows/hook.c 10 Jul 2002 23:20:49 - 1.35
+++ windows/hook.c 27 Jul 2002 17:13:02 -
@@ -61,6 +61,8 @@
#include poppack.h
#define HOOK_MAGIC ((int)'H' | (int)'K' 8) /* 'HK' */
+#define HHOOK_32(h) ((HHOOK)(h ? MAKELONG(h, HOOK_MAGIC) : 0))
+#define HHOOK_16(h) ((HANDLE16)((HIWORD(h) == HOOK_MAGIC) ? LOWORD(h) : 0))
/* This should probably reside in USER heap */
static HANDLE16 HOOK_systemHooks[WH_NB_HOOKS] = { 0, };
@@ -590,16 +592,16 @@
*
* Get the next hook of a given hook.
*/
-static HANDLE16 HOOK_GetNextHook( HANDLE16 hook )
+static HHOOK HOOK_GetNextHook( HHOOK hook )
{
-HOOKDATA *data = (HOOKDATA *)USER_HEAP_LIN_ADDR( hook );
+HOOKDATA *data = (HOOKDATA *)USER_HEAP_LIN_ADDR(HHOOK_16(hook));
if (!data || !hook) return 0;
-if (data-next) return data-next;
+if (data-next) return HHOOK_32(data-next);
if (!data-ownerQueue) return 0; /* Already system hook */
/* Now start enumerating the system hooks */
-return HOOK_systemHooks[data-id - WH_MINHOOK];
+return HHOOK_32(HOOK_systemHooks[data-id - WH_MINHOOK]);
}
@@ -608,15 +610,15 @@
*
* Get the first hook for a given type.
*/
-static HANDLE16 HOOK_GetHook( INT16 id )
+static HHOOK HOOK_GetHook( INT16 id )
{
MESSAGEQUEUE *queue;
-HANDLE16 hook = 0;
+HANDLE16 handle = 0;
if ((queue = QUEUE_Current()) != NULL)
-hook = queue-hooks[id - WH_MINHOOK];
-if (!hook) hook = HOOK_systemHooks[id - WH_MINHOOK];
-return hook;
+handle = queue-hooks[id - WH_MINHOOK];
+if (!handle) handle = HOOK_systemHooks[id - WH_MINHOOK];
+return HHOOK_32(handle);
}
@@ -677,7 +679,7 @@
TRACE(Setting hook %d: ret=%04x [next=%04x]\n,
id, handle, data-next );
-return (HHOOK)( handle? MAKELONG( handle, HOOK_MAGIC ) : 0 );
+return HHOOK_32(handle);
}
@@ -686,14 +688,14 @@
*
* Remove a hook from the list.
*/
-static BOOL HOOK_RemoveHook( HANDLE16 hook )
+static BOOL HOOK_RemoveHook( HHOOK hook )
{
HOOKDATA *data;
-HANDLE16 *prevHook;
+HANDLE16 *prevHandle;
TRACE
Re: CUPS and Wine
On Sat, Jul 27, 2002 at 11:53:57PM +0200, Andreas Mohr wrote: On Sat, Jul 27, 2002 at 12:13:57PM -0500, David D. Hagood wrote: I've been having trouble with my RH7.2 LPRng based printing, so I decided I'd try installing CUPS. After fighting for hours to get this so-called easier printing system installed and working, I finally got to where I could print from Linux apps. Now, however, Wine steadfastly refuses to bring up a meaningful print dialog. Yep, I've always been asking myself how this company came to name itself Easy Software Products. At least the CUPS install on Debian is rather problematic. You even have to type in printer URLs *by hand* in several cases ! The menu choices are not exactly non-confusing. A web-based system could be considered to be *made* for a good context-sensitive help system, yet there's none to be found. I also encountered some string garbage (typical stray pointer or so) in the printer URL input some months ago. Add to that the fact that CUPS gets rather completely rid of the useful Unix filter machanism, and you really start to wonder whether CUPS really is better than say lpd+printtool. Quite the other way around or so... It IS realy better, especialy if you have a lot of machines and real printers with many options (different trays, duplex, etc.). And the non technical people just love the graphical print tools (qtcups, gtklp kprinter). And the best feature (best for me :) of cups is that it significantly reduces the I can't print helpdesk requests. Setup the printserver and for the clients all what you need to do is to install cups and start it, nothing more. You can still use filter, you can define them in ppd file, but normaly you don't need them because today most people print from applications and not from the command line and the applications use postscript as output. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg11054/pgp0.pgp Description: PGP signature
CallNextHookEx16 strageness
Hello, while trying to convert HHOOK to a void* i found this strangeness: CallNextHookEx16 expects its first parameter to be a real HHOOK, that means it checks the HIWORD of the HHOOK to see it it contains 'HK' if (HIWORD(hhook) != HOOK_MAGIC) return 0; /* Not a new format hook */ In wine there are only 2 functions that call CallNextHookEx16, one is DefHookProc16, the other is ShellHookProc16. The first one calls CallNextHookEx16 with first parameter queue-hCurHook (an HANDLE16), the second one with WH_SHELL (the number 10). This parameters gets implicitly transformed to a HHOOK and will have their HIWORD set to 0, thus CallNextHookEx16 will always fail and return 0. I don't know what the right fix would be, I'm seeing two possibilities: - remove in CallNextHookEx16 the check if (HIWORD(hhook) != HOOK_MAGIC) return 0; - or transform in DefHookProc16 and ShellHookProc16 the first parameter passed to CallNextHookEx16 to a real HHOOK with the HIWORD set to 'HC' Comments? bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg10967/pgp0.pgp Description: PGP signature
Re: Double DECL_GLOBAL_CONSTRUCTOR in latest CVS
Hello, got the same error, but Alexander fixed it 15 minutes later (the fix is already in CVS). On Mon, Jul 22, 2002 at 11:29:11PM +0200, Uwe Bonnes wrote: copiling a recent CVS, I got: gcc -c -I. -I. -I../../include -I../../include -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o mouse/main.o mouse/main.c mouse/main.c:217: warning: `mousedev' defined but not used ld -r device.o dinput_main.o joystick/linux.o joystick/linuxinput.o keyboard/main.o mouse/main.o -o dinput.dll.tmp.o keyboard/main.o: In function `DECL_GLOBAL_CONSTRUCTOR': /home/bon/tmp/wine/compile/wine/dlls/dinput/keyboard/main.c(.text+0x380): multiple definition of `DECL_GLOBAL_CONSTRUCTOR' joystick/linuxinput.o(.text+0x550):/home/bon/tmp/wine/compile/wine/dlls/dinput/joystick/linuxinput.c: first defined here make: *** [dinput.dll.tmp.o] Fehler 1 bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg10968/pgp0.pgp Description: PGP signature
Re: fix for bug #24
Hello, i forgot the license for this patch. It's a trivial patch so it has the X11 license. bye michael On Mon, Jul 15, 2002 at 09:53:34PM +0200, Michael Stefaniuc wrote: at least the attached patch fixes the problem described in the summary of bug #24 (in the description there are some other problems described too. That's why i CC wine-devel to let one of the bugzilla guru's decide how to proceed with that bug report). ImageList_Remove when called to remove all images on an empty ImageList returns TRUE. Checked with the ControlSpy on Windows 98SE (MSDN wasn't helpfull in this case). Changelog: - Michael Stefaniuc [EMAIL PROTECTED] ImageList_Remove returns TRUE when removing all images of an empty ImageList -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg10886/pgp0.pgp Description: PGP signature
Re: fix for bug #24
On Wed, Jul 17, 2002 at 06:57:14PM +0300, Hetz Ben Hamo wrote: On Wednesday 17 July 2002 01:42, Michael Stefaniuc wrote: i forgot the license for this patch. It's a trivial patch so it has the X11 license. If you want it to be included on both wine and rewind, you'll need to dual license it. No, because wine can include X11 code and sending it to wine-patches I implicitly given it the LGPL license. The email was send only for the rewind people. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg10888/pgp0.pgp Description: PGP signature
Re: Eliminate bogus error messages
Hello! On Sun, Jul 14, 2002 at 12:19:13PM -0400, Guy L. Albertelli wrote: This eliminate ERR messages for messages greater than 0x7fff which are application dependent message. Note Listview and UpDown are not included because they are currently under repair in my tree. Those fixes will be coming later. License: X11 Changelog: Guy Albertelli [EMAIL PROTECTED] dlls/comctl32/animate.c,comboex.c,datetime.c, flatsb.c,header.c,hotkey.c,ipaddress.c,monthcal.c, progress.c,rebar.c,status.c,tab.c,toolbar.c,tooltips.c, trackbar.c,treeview.c - Don't issue error message if message number in application range. Index: dlls/comctl32/tab.c === RCS file: /home/wine/wine/dlls/comctl32/tab.c,v retrieving revision 1.69 diff -u -r1.69 tab.c --- dlls/comctl32/tab.c 20 Jun 2002 22:45:29 - 1.69 +++ dlls/comctl32/tab.c 14 Jul 2002 16:04:57 - @@ -1755,6 +1755,8 @@ */ bkgnd = comctl32_color.clrBtnFace; corner = comctl32_color.clrBtnFace; +bkgnd = 0x00c0c000; /* GLA */ +corner = 0xc0c0; /* GLA */ Are you sure that this should go in? Makes the tabs in the Minolta Dimage Image Viefer have the color lightblue/tourquoise. Without this (and also with the native comctrl32 or in Windows) the tabs are lightgray. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg10835/pgp0.pgp Description: PGP signature
Re: linux kernel thoughts
On Mon, Jun 03, 2002 at 02:58:35AM -0400, William Knop wrote: I'm sure people have asked questions about integrating wine into the linux kernel. Probably got flamed by everybody, yeah? But that's not what I'm Not realy. A wine kernel patch already exists, see ftp://ftp.infradead.org/pub/people/dwh . And Linus dosn't oppose the idea of having a wine/windows support in the kernel: http://lists.insecure.org/linux-kernel/2000/Sep/1504.html . bye michael posting about. Not directly, anyway. =) I'm thinking of writing a kernel patch for PE executable support. Is there any reason why wine libraries should not be used in a similar manner as standard linux libraries? Granted wine is more than just it's libraries. Anyway, good idea, bad idea? And please keep the if it ain't broke, don't fix it comments to yourself. No progress is made with that mentality. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg10236/pgp0.pgp Description: PGP signature
Re: wine/dlls/winmm mmsystem.c winemm.h
Hello, this patch has introduced a regression, see http://bugs.winehq.com/show_bug.cgi?id=684 for details. bye michael On Sat, May 11, 2002 at 10:10:27PM -0500, Alexandre Julliard wrote: ChangeSet ID: 1021173026714339351122366 CVSROOT: /opt/cvs-commit Module name: wine Changes by: [EMAIL PROTECTED] 02/05/11 22:10:27 Modified files: dlls/winmm : mmsystem.c winemm.h Log message: Eric Pouech [EMAIL PROTECTED] Better behavior of PlaySound (error handling, synchronization). Removed some unnecessary tests about windows handles. Patch: http://cvs.winehq.com/patch.py?id=1021173026714339351122366 Revision ChangesPath 1.52 +178 -204 wine/dlls/winmm/mmsystem.c 1.11 +14 -0 wine/dlls/winmm/winemm.h -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg09793/pgp0.pgp Description: PGP signature
Re: cups support apparently broken
On Mon, Apr 29, 2002 at 02:53:32PM -0400, Michael Cardenas wrote: On Mon, Apr 29, 2002 at 10:09:19PM +0200, Marcus Meissner wrote: trying to do an echo print | lpr -Peng Actually WINE assumes that a CUPS printer can be sent jobs using lpr -Pprintername on stdin. If this is not the case, you will have to change dlls/gdi/printdrv.c and dlls/winspool/info.c. Apparently, the correct command for cups is lp and -P needs to be replaced with -d I don't know how the cups package is build on debian, but cups provides both commands lpr and lp. And both commands work. bye michael so by changing if (!strncmp(LPR:,pszOutput,4)) sprintf(psCmd,|lpr -P%s,pszOutput+4); to if (!strncmp(LPR:,pszOutput,4)) sprintf(psCmd,|lp -d%s,pszOutput+4); in wine/dlls/gdi/printdrv.c it now works, but only for CUPS printers. I'll send a patch that checks the registry for a description with CUPS in it and uses lp -d if appropriate. thanks for the help. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg09383/pgp0.pgp Description: PGP signature
Re: building documentation failed
Hello! On Tue, Apr 16, 2002 at 09:25:44AM +0200, Stefan Leichter wrote: On Sat, Apr 13, 2002 at 01:36:37PM +0200, Stefan Leichter wrote: when i run make inside the ~wine/documentation directory i get an error when the pdf is created. The fix is easy for me, just an additional parameter (-s) for the command db2pdf. But before i send the attached patch to wine-patches i like to know if anyone can run make successful in the documentation directory. In this case we may have to add a check in the configure script. If someone is able to build the documentation successful please post the output of db2pdf -v. Yes, it works without the -s for me. camus:~/work/wine/documentation$ db2pdf -v DocBook-utils version 0.6.9 (jw version 1.1) does the documentation build with '-s' too? No, it fails with unknown option and presents me the db2pdf -h output. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg09050/pgp0.pgp Description: PGP signature
Re: building documentation failed
Hello! On Sat, Apr 13, 2002 at 01:36:37PM +0200, Stefan Leichter wrote: when i run make inside the ~wine/documentation directory i get an error when the pdf is created. The fix is easy for me, just an additional parameter (-s) for the command db2pdf. But before i send the attached patch to wine-patches i like to know if anyone can run make successful in the documentation directory. In this case we may have to add a check in the configure script. If someone is able to build the documentation successful please post the output of db2pdf -v. Yes, it works without the -s for me. camus:~/work/wine/documentation$ db2pdf -v DocBook-utils version 0.6.9 (jw version 1.1) bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg09010/pgp0.pgp Description: PGP signature
Re: make test leaves 2 wine processes running
On Sat, Mar 30, 2002 at 11:58:49PM +0100, Sylvain Petreolle wrote: Did you set the Desktop parameter at any value other than N ? Running it whitout a desktop window gives no problem. Hmm ... you are right, I never use wine in desktop mode. I can now reproduce your problem. bye michael Noted another thing : occasionnally the program goes to debugger and is in X processes. I'm running the same and don't see the problem, no wine process is left after make test. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg08754/pgp0.pgp Description: PGP signature
Re: Wine wrongly seeing gdi32 user32 as native
On Thu, Mar 28, 2002 at 04:14:16PM +0100, Marcus Meissner wrote: On Wed, Mar 27, 2002 at 05:56:18PM +0100, Sylvain Petreolle wrote: Hi, While running 'make test', I receive these messages :make[2]: Entre dans le répertoire `/home/wine/dlls/oleaut32' ../../programs/winetest/runtest -q -P wine -M oleaut32.dll -T ../.. -p tests/oleaut32_test tests/vartest.c touch tests/vartest.ok Warning: loading builtin gdi32.dll, but native version already present. Expect trouble. Warning: loading builtin user32.dll, but native version already present. Expect trouble. wine: Unhandled exception, starting debugger... snipLoaded debug information from ELF '/usr/local/lib/wine/gdi32.dll.so' (0x4064f000) Loaded debug information from ELF '/home/wine/dlls/libgdi32.dll.so' (0x40871000) Wine is loading several dlls twice : from the source directory and from installed binaries... Is this the expected behaviour ?? I am occasionaly getting the same. If you do make -k you will see the same for the 'user' tests. I am utterly puzzled on why it happens, probably due to the LD_PRELOAD magic or something. I'm always getting this errors. I'm trying to write a test for the imagelist functions but even this get's that error: #!/usr/bin/perl use wine use comctl32 Didn't had the time to take a deeper look into this problem. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg08685/pgp0.pgp Description: PGP signature
Re: fixme:bitblt:MaskBlt errors
On Tue, Mar 26, 2002 at 04:37:39PM -0500, Lonnie Cumberland wrote: Hello All, I am running a program that I have compiled with wxWindows, but when I run the application it comes up with one of the graphic images (background image) displayed, but then the other 3 images do not show up and I see an error message in my xterm: fixme:bitblt:MaskBlt (2144,50,50,53,61,2376,0,0,2256,0,0,-1429471200): stub fixme:bitblt:MaskBlt (2144,100,100,44,63,2380,0,0,2284,0,0,-1429471200): stub fixme:bitblt:MaskBlt (2144,150,150,53,53,2384,0,0,2312,0,0,-1429471200): stub I am using the latest release of wine, but not the CVS version. Has this been fixed yet or is someone working on it? No, it isn't fixed yet and i don't know if someone is working on it. As a quick fix, try to run your program with -winver win98, because MaskBlt is only inplemented on NT, W2K and XP. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg08663/pgp0.pgp Description: PGP signature
Re: ImageList fixes
Hello,
sorry to replay so late but I didn't had the time to test your patch
before.
On Fri, Feb 22, 2002 at 08:39:39PM -0500, Dave Hawkes wrote:
The hotspot handling in imagelist is broken. This fix partially repairs it.
... and breaks it too. With your patch the hotspot handling in
FreeSolitaire is broken. The attached patch reverts a small portion of
your patch and fixes the recursion.
For what do you need bHSPending? With the recursion removed it's pretty
useless.
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
Index: imagelist.c
===
RCS file: /home/wine/wine/dlls/comctl32/imagelist.c,v
retrieving revision 1.49
diff -u -r1.49 imagelist.c
@@ -2614,14 +2616,13 @@
* dxHotspot, dyHotspot is the offset of THE Hotspot (there is only one
* hotspot) to the origin of the second image.
* See M$DN for details */
+dx = InternalDrag.dxHotspot - dxHotspot;
+dy = InternalDrag.dyHotspot - dyHotspot;
+
if(InternalDrag.bHSPending) {
- dx = 0;
- dy = 0;
InternalDrag.bHSPending = FALSE;
-} else {
- dx = InternalDrag.dxHotspot - dxHotspot;
- dy = InternalDrag.dyHotspot - dyHotspot;
}
+
himlTemp = ImageList_Merge (InternalDrag.himl, 0, himlDrag, iDrag, dx, dy);
if (visible) {
msg08210/pgp0.pgp
Description: PGP signature
Re: resent: GetPrivateProfileInt*() fix
On Fri, Feb 01, 2002 at 12:13:57PM +0100, Andreas Mohr wrote: Hello! these functions were pretty much broken (overflow and signed/unsigned behaviour), so I fixed almost every problem. Some German tax calculation program barfed because of this. Now it works much better: it crashes due to a rather familiar BadMatch error at X_GetImage ;-) (I'm almost sure I know where this happens in Wine code, and of course we should really fix that problem finally) I have also a german tax program (Steuertipps PC for the year 1999) and I tried your patch as is. With or without the patch the program fails with a MessageBox. Without patch after clicking ok an exception is trapped and the debugger starts. With the patch wine just segfaults. bye michael I wrote my private testing framework for these functions, so I'll convert that to the official framework soon. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg07394/pgp0.pgp Description: PGP signature
Re: ROTD (Rant Of The Day): patches
On Thu, Jan 31, 2002 at 03:52:19PM -0500, Dimitrie O. Paun wrote:
I've come to _hate_ diffs attached as Application/OCTET-STREAM. Can you
please, Please, PLEASE, attach them as Text/PLAIN?
I use Pine over a ssh connection to read wine-{devel,patches}, and I can
Use a better mailer like mutt ;) ?
simply view the Text/PLAIN attachments, whereas I have to:
-- press V to view the list of attachments
-- select the attachment I want to view
-- press S to save it to disk
This is what have todo with mutt too, but I don't have to save. I press
Enter to display the message. mutt complains about not having an
appropiate method for the mime type and displays it in it's internal
pager. I suspect this should work in pine too.
-- exit Pine
-- start vi to actually view the thing
-- restart pine...
Uuuh ... this is like rebooting. Has pine a pipe function (it's long
ago when I saw The Light and switched to mutt)? That's what i do in mutt
wenn I get an gzip'ed patch: go to the list of attachments, select the
attachment and pipe it through zless. So no need to leave the mailer.
Just to view a Application/OCTET-STREAM attachment.
They don't annoy me too much, but the extra key strokes I need to view
them will get me the carpal tunnel syndrome.
bye
michael
P.S.: sorry, couldn't resist
Which means 2 things:
-- I get frustrated (and look what happens when I do:))
-- I simply ignore those patches
For all these reasons (and more), I think Linus is right when he insists on:
-- ONE patch per email
-- ONLY Text/PLAIN attachments.
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
msg07362/pgp0.pgp
Description: PGP signature
Re: Prob with freetype...
On Tue, Jan 29, 2002 at 09:26:34PM +, Meths wrote: Didn't see anyone mention this so... When compiling CVS tonight... gcc -c -I. -I. -I../../include -I../../include -I/usr/include/freetype2 -g -O2 -Wall -mpreferred-stack-boundary=2 -fPIC -D__WINE__ -D_REENTRANT -I/usr/X11R6/include -o freetype.o freetype.c freetype.c: In function `WineEngGetGlyphOutline': freetype.c:947: `FT_Angle' undeclared (first use in this function) freetype.c:947: (Each undeclared identifier is reported only once freetype.c:947: for each function it appears in.) freetype.c:947: parse error before `angle' freetype.c:993: `angle' undeclared (first use in this function) freetype.c:1003: warning: implicit declaration of function `FT_Vector_Rotate' freetype.c:1059: warning: implicit declaration of function `FT_Cos' freetype.c:1060: warning: implicit declaration of function `FT_Sin' make[2]: *** [freetype.o] Error 1 make[2]: Leaving directory `/root/cvs_root/wine/dlls/gdi' make[1]: *** [gdi/libgdi32.so] Error 2 make[1]: Leaving directory `/root/cvs_root/wine/dlls' make: *** [dlls] Error 2 Upgrade your freetype to 2.0.3 . bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg07290/pgp0.pgp Description: PGP signature
Re: To which freetype should I upgrade? 2.0.6 or earlier
On Tue, Jan 29, 2002 at 07:54:14AM -0800, Bill Medland wrote: and while we are on the subject what is the philosophy on ifdefing header files? (I have freetype 2.0.1 from RedHat 7.1 so this morning's build failed because I don't have the trig stuff.) If we test for a header file and only include it if it is present should we be putting similar ifdefs around the code that required the header and providing alternatives when it is not present, or specifying that it NEEDS to exist? I had the same problem this morning and updated to freetype-2.0.3 from Red Hat Linux 7.2 and it works again. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbHEmail: [EMAIL PROTECTED] Hauptstaetterstr. 58http://www.redhat.de/ D-70178 Stuttgart msg07272/pgp0.pgp Description: PGP signature
Re: Bulletproof the debugger.
Hello,
please do not apply the previous patch, i did something very stupid. Use
the attached patch instead (makes also better use of the C99 style
return value).
bye
michael
On Wed, Dec 26, 2001 at 01:09:06AM +0100, Michael Stefaniuc wrote:
[snip]
I did a short check with
camus:~/work/wine$ grep -r -I -C snprintf ./ | less
and this is what I found:
- most of the time the return value of *snprintf isn't checked
- if the return value is checked it's mostly checked for C89 and C99
style
- the attached patch should fix all the remaining cases.
Changelog:
Michael Stefaniuc [EMAIL PROTECTED]
check the return value of *snprintf for C99 style overflow reporting
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbHEmail: [EMAIL PROTECTED]
Hauptstaetterstr. 58http://www.redhat.de/
D-70178 Stuttgart
Index: dlls/kernel/format_msg.c
===
RCS file: /home/wine/wine/dlls/kernel/format_msg.c,v
retrieving revision 1.19
diff -u -r1.19 format_msg.c
--- dlls/kernel/format_msg.c2001/10/10 02:51:24 1.19
+++ dlls/kernel/format_msg.c2001/12/26 09:46:29
@@ -265,6 +265,7 @@
strcpy( fmtstr, %s );
}
if (args) {
+ int ret;
int sz;
LPSTR b;
@@ -282,8 +283,9 @@
b = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sz
= 100);
/* CMF - This makes a BIG assumption about va_list */
TRACE(A BIG assumption\n);
-while (vsnprintf(b, sz, fmtstr, (va_list)
argliststart) 0) {
-b = HeapReAlloc(GetProcessHeap(),
HEAP_ZERO_MEMORY, b, sz += 100);
+while ((ret = vsnprintf(b, sz, fmtstr, (va_list)
+argliststart) 0) || (ret = sz)) {
+ sz = (ret == -1 ? sz + 100 : ret + 1);
+b = HeapReAlloc(GetProcessHeap(),
+HEAP_ZERO_MEMORY, b, sz);
}
}
for (x=b; *x; x++) ADD_TO_T(*x);
Index: dlls/user/lstr.c
===
RCS file: /home/wine/wine/dlls/user/lstr.c,v
retrieving revision 1.18
diff -u -r1.18 lstr.c
--- dlls/user/lstr.c2001/10/17 17:50:02 1.18
+++ dlls/user/lstr.c2001/12/26 09:46:30
@@ -683,14 +683,16 @@
strcpy( fmtstr, %s );
}
if (args) {
+ int ret;
int sz;
LPSTR b = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sz =
100);
argliststart=args+insertnr-1;
/* CMF - This makes a BIG assumption about va_list */
- while (vsnprintf(b, sz, fmtstr, (va_list) argliststart) 0) {
- b = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, b, sz
+= 100);
+ while ((ret = vsnprintf(b, sz, fmtstr, (va_list) argliststart)
+ 0) || (ret = sz)) {
+ sz = (ret == -1 ? sz + 100 : ret + 1);
+ b = HeapReAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, b, sz);
}
for (x=b; *x; x++) ADD_TO_T(*x);
} else {
Index: programs/wineconsole/wineconsole.c
===
RCS file: /home/wine/wine/programs/wineconsole/wineconsole.c,v
retrieving revision 1.4
diff -u -r1.4 wineconsole.c
--- programs/wineconsole/wineconsole.c 2001/12/04 20:46:54 1.4
+++ programs/wineconsole/wineconsole.c 2001/12/26 09:46:36
@@ -22,7 +22,7 @@
len = vsnprintf(buf, sizeof(buf), format, valist);
va_end(valist);
-if (len = -1)
+if ((len = -1) || (len = sizeof(buf)))
{
len = sizeof(buf) - 1;
buf[len] = 0;
Index: win32/console.c
===
RCS file: /home/wine/wine/win32/console.c,v
retrieving revision 1.84
diff -u -r1.84 console.c
--- win32/console.c 2001/12/21 20:29:10 1.84
+++ win32/console.c 2001/12/26 09:46:38
@@ -62,6 +62,7 @@
static BOOLstart_console_renderer(void)
{
char buffer[256];
+intret;
STARTUPINFOA si;
PROCESS_INFORMATIONpi;
HANDLE hEvent = 0;
@@ -85,14 +86,16 @@
/* first try environment variable */
if ((p = getenv(WINECONSOLE)) != NULL)
{
- if (snprintf(buffer, sizeof(buffer), %s -- --use-event=%d, p, hEvent) 0
