Re: faq merge #2 -- Alexandre please look over the first patch :)
On Mon, Sep 01, 2003 at 06:19:17PM -0700, Alexandre Julliard wrote: Tom [EMAIL PROTECTED] writes: changelog merge from lostwages faq It doesn't build here, that's because of the '' in the rpmseek.com URL, I'm not sure what's the correct way to escape that: amp; should be the escape for Ciao, Marcus
Re: Viruses in the wine-devel archive ??
On Fri, Aug 22, 2003 at 06:13:39PM +0300, P. Christeas wrote: Yup, here is the message. http://winehq.com/hypermail/wine-patches/2003/08/0203.html I'll remove that attachment. Should we contact that author and let him know he is infected, or simply remove him from the list? Btw. Does SoBig.F run under wine? If yes, how bad can it get? It crashes for me. Ciao, Marcus
Re: About spam
On Fri, Aug 22, 2003 at 10:58:44AM -0700, Duane Clark wrote: Sylvain Petreolle wrote: I have an evidence that some robots can grab our email adress, even with our mangling process on winehq. I used my work adress only onto wine-devel and got spammed last week. A lot of spammers do dictionary attacks using various email combinations including first initial last [EMAIL PROTECTED] And I get regular email at [EMAIL PROTECTED], since I get all mail @jet.franken.de, so the scrambling does not really help ;) But basically I do not care, I no longer read my spam folder, I just delete everything that gets in there. Ciao, Marcus
REGRESSION: environment variables no longer possible
Hi, Apparently the changes from yesterday removed support of environment variables in registry keys (very useful for the Path keys in the Drive sections). Can it be readded? Or is there a rational behind it? Ciao, Marcus pgp0.pgp Description: PGP signature
Re: REGRESSION: environment variables no longer possible
On Tue, Aug 19, 2003 at 10:33:44AM -0700, Alexandre Julliard wrote: Dmitry Timoshkov [EMAIL PROTECTED] writes: Actually it's just the format of the Wine config has changed. Now all environment variables should be surrounded by the percent signes (%HOME%), and are handled by the normal registry code. Alexandre has changed the sample config as well. Actually the format of the config has not really changed, most entries have been behaving that way for a long time already. I just made the drives part of the config behave like all the other entries. Small migration nightmare though. But then again, WINE is alpha software. Ciao, Marcus
Re: wine/. configure.ac configure
On Wed, Jul 23, 2003 at 07:09:52PM -0500, Alexandre Julliard wrote: ChangeSet ID: 8863 CVSROOT: /home/winehq/opt/cvs-commit Module name: wine Changes by: [EMAIL PROTECTED] 2003/07/23 19:09:52 Modified files: . : configure.ac configure Log message: Disable gcc strict aliasing optimization for now. Patch: http://cvs.winehq.com/patch.py?root=/home/winehq/opt/cvs-commitid=8863 Old revision New revision Changes Path 1.167 1.168 +9 -0 wine/configure.ac 1.442 1.443 +52 -0 wine/configure Which file/functions gets broken by strict aliasing? Ciao, Marcus
Re: Warning on Alpha Linux
On Sat, Jul 19, 2003 at 11:37:12PM -0700, Steven Edwards wrote: --- Todd Vierling [EMAIL PROTECTED] wrote: You should be aware that NT on Alpha was *NOT* a LP64 operating system (whereas Windows on IA64 is indeed LP64), and I'm presuming that the alpha-pe is targeting the classical NT/Alpha configuration. The ARC BIOS that was used to load NT created a memory map that simulated a 32-bit memory space, thus essentially making an Alpha behave much like an x86 -- well, sort of. A Wine compiled as Win64 will likely not be able to run Alpha NT binaries. However, it might work reasonably well to compile apps with Winelib. I dont really care so much about being compatible with Alpha NT stuff. I know Marcus broke the NT PPC compatiblity stuff for his Winelib port so I think its a non-issue for anyone here. Side note: The ABI is broken just for 1 register (TEB), since it is used by the Linux/PPC ABI. Ciao, Marcus
Re: [RESENT]: Fixed winedbg example configuration
On Fri, Jul 18, 2003 at 08:09:58AM +0200, Jon Bright wrote: ... The point is that the automatic reordering should go away because it's causing at least one bug that I know of. Keys should be read out of the registry in the same order they were written to it. Thus, saying this is a no-op because keys are reordered isn't a valid argument against BiGgUn's patch. You could equally say This patch seems completely pointless, key re-ordering or not, though and I'd be quite happy. Please give more details on that bug. Ciao, Marcus
Re: HRESULTs and headers
On Mon, Jul 14, 2003 at 11:44:20AM +0100, Mike Hearn wrote: Good morning everybody! I was wondering if anybody knew where I could find a definitive list of HRESULT values, as the one I want to know, 0x80770001, is not in the Wine headers, nor on Google. Is there somewhere that I can get the official set of headers for free? I don't want to buy Visual Studio just to get them (the mingw headers are partially taken from Wine I think). Download a DirectX SDK for instance. Just some hundreds of megabytes, but I have always found includes somewhere. Ciao, Marcus
Re: PPC CPU Detection in configure
On Sun, Jul 13, 2003 at 02:20:53PM +0200, Pierre d'Herbemont wrote: Hi, Here is a patch which adds CPU Detection for the PowerPC Processor in configure.ac. There wasn't any in configure, is there any reason? By the way there is two flags for the powerpc : __PPC__ and __powerpc__ any reason, or should they be unified? My gcc already defines them correctly. Ciao, Marcus pgp0.pgp Description: PGP signature
Re: Building winelib without wine...
On Fri, Jul 11, 2003 at 01:50:28PM +0100, Mark Easton wrote: Having scanned the WineHQ website thoroughly I've come across a couple of posts that suggest that winelib has been previously been made to work on PPC, although I cannot find any details of how to attempt such a thing. Can anyone suggest how I could start trying to get Winelib built on PPC as I really can't find any details about building winelib without wine There are some patches needed, one is floating around from the Darwin maintainer, one is in my tree at SuSE. I will submit mine next week, but its just a small dlls/ntdll/signal_powerpc.c fix, Ciao, Marcus
Re: Freetype libs in /usr/include/libs
On Mon, Jul 07, 2003 at 12:34:31PM -0700, Jeff Smith wrote: If I am not mistaken, /usr/local/lib is the *standard* location to find the freetype libraries, if it is built stand-alone, as opposed to being built as part of XFree86. Of course, I would have thought that /usr/local/lib should be a part of the standard library search path. Note that we should probably first try pkg-config, then freetype-config, then fall back on standard locations when looking for the freetype libraries. And we do not even link against them, we just need the headers. The libraries are loaded dynamically, where the search path is not honored yet. Ciao, Marcus
Re: Heap APIS
On Sat, Jul 05, 2003 at 08:34:51AM +, Jean-Eric Cuendet wrote: Hi, In windows, there is APIs for Heap management (HeapCreate, HeapAlloc, ...). Are they implememted in wine? How? Is it just stubs on malloc? Or are they *really* implemented and working as secondary heaps? Yes. On top of VirtualAlloc. No. Yes. Ciao, Marcus
Re: PATCH: dlls/commdlg/printdlg.c add casts
On Sat, Jun 28, 2003 at 04:30:13PM +0100, Mike Hearn wrote: On Sat, 28 Jun 2003 09:46:35 +0200, Sir Gerald Pfeifer scribed thus: The following patch to dlls/commdlg/printdlg.c revision 1.66 date: 2003/06/27 22:21:06; author: julliard; state: Exp; lines: +4 -7 Mike Hearn [EMAIL PROTECTED] Store PrintStructures in a window property instead of extra window bytes. cause two new warnings printdlg.c:2056: warning: passing arg 2 of `GetPropW' from incompatible pointer type printdlg.c:2061: warning: passing arg 2 of `SetPropW' from incompatible pointer type Odd, I don't remember getting those. Perhaps I just didn't notice. In future I'll try and remember to compile with -Werror before submitting. In this case I think it's mostly academic as the string doesn't have any non ANSI characters in it, but I think another solution might be to put an L before the string, so it becomes: SetPropW(hDlg, L__WINE_WHATEVER) No, Lx is not guaranteed to do the things you think it does. (It will use 4 byte characters, depending on how gcc is configured or if you use -fwchar-short or so.) Ciao, Marcus
Re: PATCH: dlls/commdlg/printdlg.c add casts
No, Lx is not guaranteed to do the things you think it does.
(It will use 4 byte characters, depending on how gcc is configured
or if you use -fwchar-short or so.)
Doesn't Wine's comfigure complain if gcc doesn't understand
-fshort-wchar? (It seems it doesn't, but I'm sure it did in the past...)
I am pretty sure it never did.
Actually, since I can't find that option passed to gcc anymore, how does
Wine gets its binary compatibility with native apps regarding this
issue?
Hmm? The native apps when compiled use the option -fshort-wchar,
see : tools/winegcc.c:gcc_argv[i++] = -fshort-wchar;
I'm asking because I saw a couple L_text while grepping for answering
Mike...
There ain't:
./dlls/kernel/messages/winerr_enu.mc.rc: LSuccess\n\x\x,
is handled by wmc
./dlls/shlwapi/ordinal.c: lstrlenW(L{D0FCA420-D3F5-11CF-B211-00AA004AE837
});
./dlls/shlwapi/ordinal.c: StrCpyW(a6, L{D0FCA420-D3F5-11CF-B211-00AA004A
E837});
#if 0'ed out.
./include/wincrypt.h (and one other .h file) use L protected by MSVC
checks.
Ciao, Marcus
Re: PATCH: dlls/commdlg/printdlg.c add casts
On Sat, Jun 28, 2003 at 05:56:23PM -0400, Vincent Béron wrote: Le sam 28/06/2003 à 17:27, Marcus Meissner a écrit : Actually, since I can't find that option passed to gcc anymore, how does Wine gets its binary compatibility with native apps regarding this issue? Hmm? The native apps when compiled use the option -fshort-wchar, see : tools/winegcc.c:gcc_argv[i++] = -fshort-wchar; I was talking about a random foo.exe in PE format. How does Wine understands the WSTR from it if it's not itself compiled with -fshort-wchar? It must be compiled with -fshort-wchar. Thats why winegcc sets it by default. Ciao, Marcus
Re: Mac OS X Support : Asm syntax support
On Wed, Jun 25, 2003 at 02:32:29PM +0200, Pierre d'Herbemont wrote: Hi, Here is a patch which should add support for Mac OS X ppc asm syntax, and some Mach-O quirk (like text section). I hope it will be ok. It mainly relay on Macro which are stored in build.h (any better place?). Cheers, Pierre ChangeLog: - Add support for Mac OS X assembler syntax This needs 2 places fixed: +# define LD_SECTION_TEXT .section \.text\ Should be # define LD_SECTION_TEXT .section \\\.text\\\ and: +# define PPC_LOW(mem,index) ( mem )@l(##index) should be: # define PPC_LOW(mem,index) ( mem )@l( #index ) Ciao, Marcus
Re: Mac OS X Support : winebuild assembler conformance
On Mon, Jun 23, 2003 at 02:01:38PM +0200, Pierre d'Herbemont wrote:
Hi,
Here is a patch which fix the problem with darwin's asm. I would like
to know if linux assembler is ok with this patch.
Hmm, not quite. On Linux/PPC:
d3d8.spec.s:351: Error: syntax error; found `(' but expected `,'
d3d8.spec.s:351: Error: junk at end of line: `(_imports+80)'
351:lis r9,ha16(_imports+80)
352:la r8,lo16(_imports+80)(r9)
Ciao, Marcus
Re: Wine
On Thu, Jun 19, 2003 at 02:51:43PM -0500, Sundaranathan S wrote: Hi All, I have posted a question long back but no reply from anyone. So onceagain posting the same question please can anyone tell me client error:0: recvmsg: Bad address error. is coming after installing wine. Also if there is any build or binaries for wine on solaris intel then please let me know. Please let me know what is the reason and also the possible solution. Thanks in advance. Please reply. Did you compile WINE for yourself? Did you try the latest version? What OS? What Kernel? What glibc? Ciao, Marcus
Re: Wine
On Thu, Jun 19, 2003 at 03:21:01PM -0500, Sundaranathan S wrote: What OS? What Kernel? What glibc? - Solaris 9 on Intel. gcc-lib for solaris 9 intel version 3.2.2 Please let me what could be the reason ... i got stuck up ... I think just because no one else has tested it on Solaris 9 yet, so it might just be buggy on Solaris 9. Ciao, Marcus
Re: How to use CVS Wine?
On Mon, Jun 09, 2003 at 12:04:05AM +0200, Z_God wrote: Op zondag 8 juni 2003 22:57, schreef Mike Hearn: If this is on RH9, check you don't have LD_ASSUME_KERNEL set in the environment. Running `unset LD_ASSUME_KERNEL` before running Wine should suffice (unless wine in this case is actually a script). I'm using SuSE 8.2. I'm using regwine (created by the GetWine script) to run CVS regular Wine. Running 'unset LD_ASSUME_KERNEL' anyway before running Wine didn't seem to fix. Just download the SuSE 8.2 RPMs from SourceForge? Ciao, Marcus
Re: Add root drive mapping to default config file
On Tue, Jun 03, 2003 at 12:33:49PM +0200, Lionel Ulmer wrote: That would work too. But it's just a general pain in the ass even when you know exactly what is going on anyway, it's not like Wine is already too convenient to use or anything. No, but if they users get this error, it means that they did not configure Wine properly... So that we are only hiding the problem anyway. What makes you sure that they will have set a fake C drive properly or created the sub-directories and all that stuff ? My RPMs have a Z drive mapped to /, marked as network drive. The network drive mark usually make programs refrain from creating Z:\files. I don't really see a problem, except a virus might go and scan the whole UNIX system including NFS trees. But the risk is low, and benefits are greater. Ciao, Marcus
Re: wine exception handling
On Sun, Jun 01, 2003 at 03:26:40PM +0200, Martin Fuchs wrote:
Hi,
I have problems running an application with wine. At startup it tries to read
its config file. But it catches up in an endless loop of exceptions.
The attached trace is generated using --debugmsg +msvcrt,+seh,+file,+dosfs.
I send only the interesting part of the full trace.
However there is a:
fixme:seh:EXC_RtlRaiseException call to unimplemented function
msvcrt.dll.localeconv
But why does there happen an excpeption anyways?
The missing function is passed up using a standard Win32 exception,
which is handled by the program here.
Oh, and please try this patch:
Ciao, Marcus
Changelog:
Implemented localeconv() by just calling to Linux localeconv().
Index: locale.c
===
RCS file: /home/wine/wine/dlls/msvcrt/locale.c,v
retrieving revision 1.16
diff -u -r1.16 locale.c
--- locale.c12 Feb 2003 21:28:47 - 1.16
+++ locale.c1 Jun 2003 14:49:31 -
@@ -30,6 +30,8 @@
#include wine/debug.h
+#include locale.h
+
WINE_DEFAULT_DEBUG_CHANNEL(msvcrt);
/* FIXME: Need to hold locale for each LC_* type and aggregate
@@ -546,4 +548,36 @@
* arguments to wide strings and then calls LCMapStringW
*/
return LCMapStringA(lcid,mapflags,src,srclen,dst,dstlen);
+}
+
+/*
+ * localeconv (MSVCRT.@)
+ */
+struct MSVCRT_lconv *MSVCRT_localeconv(void) {
+
+ struct lconv *ylconv;
+ static struct MSVCRT_lconv xlconv;
+
+ ylconv = localeconv();
+
+#define X(x) xlconv.x = ylconv-x;
+ X(decimal_point);
+ X(thousands_sep);
+ X(grouping);
+ X(int_curr_symbol);
+ X(currency_symbol);
+ X(mon_decimal_point);
+ X(mon_thousands_sep);
+ X(mon_grouping);
+ X(positive_sign);
+ X(negative_sign);
+ X(int_frac_digits);
+ X(frac_digits);
+ X(p_cs_precedes);
+ X(p_sep_by_space);
+ X(n_cs_precedes);
+ X(n_sep_by_space);
+ X(p_sign_posn);
+ X(n_sign_posn);
+ return xlconv;
}
Index: msvcrt.spec
===
RCS file: /home/wine/wine/dlls/msvcrt/msvcrt.spec,v
retrieving revision 1.72
diff -u -r1.72 msvcrt.spec
--- msvcrt.spec 12 May 2003 03:31:16 - 1.72
+++ msvcrt.spec 1 Jun 2003 14:49:32 -
@@ -655,7 +655,7 @@
@ cdecl labs(long)
@ cdecl ldexp( double long) MSVCRT_ldexp
@ cdecl ldiv(long long) MSVCRT_ldiv
-@ stub localeconv #()
+@ cdecl localeconv() MSVCRT_localeconv
@ cdecl localtime(ptr)
@ cdecl log(double)
@ cdecl log10(double)
Re: edit control question
On Sat, May 31, 2003 at 03:40:55PM -0400, Steven Edwards wrote: Hello, I am wanting to adapt the WINE edit control for use in ReactOS and I dont understand how the edit control gets called by the application. I have a simple window program that calls the EDIT class and have stubbed out the exported functions but I dont see or understand how EditWndProc gets called from the application. When I look at the imports of my edit control test application this function isnt called but running it I do get a Window I can type text in. I am still really new to this whole programming gig so if I looking in the wrong area please point me in the right direction. The class EDIT gets registered using RegisterClass, with the window procedure specified. So if you CreateWindow() a window with EDIT as the windowclass, then the class above is used for the window, and the EditWndProc gets called. Check: dlls/user/user_main.c: CLASS_RegisterBuiltinClass( EDIT_builtin_class ); Ciao, Marcus
Re: Bultin OCX?
On Thu, May 29, 2003 at 05:25:20PM +0100, Mike Hearn wrote: They are normally shipped with the app. So would we really need one in Wine? I think one of the goals of wine is to implement all the functions of windows systems, for instance now i'm testing an application written in VB that uses both Winsock.ocx and mscomm.ocx (RS-232), and I would like to use as builtin libraries/com libraries as possible, instead of using a closed ocx, in which i can't do anything if something fails...I know now exists some builtin programs like wine-Notepad or winemine, so i think, the next step is to develop builtin OCX...under wine license OK, that's fine, but be aware that: * notepad is there because some apps require it * winemine is just a simple demo of how to write a WineLib app ie, Wine is NOT trying to replicate the entirety of Windows. Err, we are trying that. And a standard winsock OCX falls under the to be done category for me. Ciao, Marcus
Re: Application crashes (something to do with OLE 16/32 split)
On Sun, May 25, 2003 at 10:37:55PM +0100, Mike Hearn wrote:
This is the trace I get:
Unhandled exception: unimplemented function storage.dll.IStream16_Stat
called in 32-bit code (0x4126eb7a).
In 32-bit mode.
0x4126eb7a (__wine_unimplemented+0x52 [storage.spec.c] in ole32.dll.so):
jmp0x4126eb74 (__wine_unimplemented+0x4c [storage.spec.c] in
ole32.dll.so)
45 static void __wine_stub_StgCreateDocFileOnILockBytes(void) {
__wine_unimplemented(StgCreateDocFileOnILockBytes); }
Wine-dbgbt
Backtrace:
=0 0x4126eb7a (__wine_unimplemented+0x52 [storage.spec.c] in
ole32.dll.so) (ebp=41092118)
1 0x4126edc8 (__wine_stub_IStream16_Clone [storage.spec.c:66] in
ole32.dll.so) (ebp=41092128)
So we have 3 possibilities for the stub:
* IStream16_Stat
* StgCreateDocFileOnILockBytes
* IStream16_Clone
Time to play guess the stub - wholesome fun for all the family! :)
No, it is definitely said what is missing:
Unhandled exception: unimplemented function storage.dll.IStream16_Stat
called in 32-bit code (0x4126eb7a).
Chances are pretty good that StgCreateDocFileOnILockBytes is called
just some lines later though.
Ciao, Marcus
Re: Application crashes (something to do with OLE 16/32 split)
On Tue, May 27, 2003 at 07:40:07PM +0100, Mike Hearn wrote: No, it is definitely said what is missing: Unhandled exception: unimplemented function storage.dll.IStream16_Stat called in 32-bit code (0x4126eb7a). Chances are pretty good that StgCreateDocFileOnILockBytes is called just some lines later though. Why does the backtrace show a different function altogether? Because the debuginfo is not complete in the generated files I think. Ciao, Marcus
Re: OLE storage SetFilePointer fix
On Sat, Apr 12, 2003 at 11:07:11PM +0200, Andreas Mohr wrote:
Hi all,
the OLE storage code basically disabled itself, by doing a
READ_HEADER;
in STORAGE_get_pps_entry().
This READ_HEADER uses -1 as block number for STORAGE_get_big_block()
(in order to retrieve the storage header block).
And if you look at the SetFilePointer() in STORAGE_get_big_block(),
you might notice that (n+1)*BIGSIZE for some strange reason evaluates
to 0, for n == -1.
Thus, SetFilePointer() seeks to position 0 to read the storage header.
And now I'm terribly sorry to tell you that STORAGE_get_big_block()
did a
if (!SetFilePointer( hf, (n+1)*BIGSIZE, NULL, SEEK_SET ))
{
WARN( seek failed (%ld)\n,GetLastError());
return FALSE;
}
Sounds like SetFilePointer() is *supposed* to return 0 if it seeks to
position 0, eh?
In other words:
- fix blatantly wrong SetFilePointer() calls
The 16bit storage code is probably not safe to work with, for instance
saving is probably not working.
It should call forward to the 32bit storage code, which I think
is more correct.
Ciao, Marcus
Re: Oleaut32 Debug Messages
On Thu, Mar 13, 2003 at 01:05:21AM -0500, Dimitrie O. Paun wrote: On March 11, 2003 05:49 pm, Jon wrote: - if (debugout) MESSAGE(%lx,*arg); + if (debugout) TMSG2(%lx,*arg); This is just too ugly! Please don't do such code uglification to save a few bytes. Beyond that, why isn't this file using the standard TRACE macro? MESSAGEs should be very rare, and are intended for the user, as such there's no need to compile them out, ever. It is constructing lines of debugoutput out of different pieces. How to do that with TRACE? Ciao, Marcus
Re: (5th) Janitorial dlls/advapi32/registry.c W-A cleanup
Hope this one makes everyone happyg Change Log: Janitorial. Get rid of W-A calls Files Changed: dlls/advapi32/registry.c -- Tony Lambregts Index: Makefile.in === RCS file: /home/wine/wine/dlls/advapi32/Makefile.in,v retrieving revision 1.17 diff -u -r1.17 Makefile.in --- Makefile.in 25 Oct 2002 19:17:33 - 1.17 +++ Makefile.in 10 Mar 2003 06:22:56 - -IMPORTS = kernel32 ntdll +IMPORTS = kernel32 ntdll user32 This creates a circular dependency advapi32 - user32 ? Ciao, Marcus
Re: Patch Ole32 - More 16/32 Splitting
On Mon, Mar 03, 2003 at 12:41:38PM -0500, Steven Edwards wrote: I dont know if this is right. So i figured I would submit and ask... Can you use CLSIDFromProgID rather then CLSIDFromProgID16 here? I have not really looked at any of these functions before. You can't. The 16 version uses 8bit strings, the ole32 version uses 16bit strings. Ciao, Marcus
Re: GlobalInterfaceTable?
On Sun, Mar 02, 2003 at 07:15:16PM +, Mike Hearn wrote:
Hi,
As part of a program that creates an instance of MSXML2.DOMDocument, I
get the following errors:
fixme:ole:CoCreateInstance no classfactory created for CLSID
{0323---c000-0046}, hres is 0x80040154
fixme:ole:CoCreateInstance no classfactory created for CLSID
{6c736db1-bd94-11d0-8a23-00aa00b58e10}, hres is 0x80040154
(actually there are some more beforehand, but they don't seem fatal).
Anyway, the first one seems to be StdGlobalInterfaceTable, which MSDN
indicates should be implemented by Windows. Is this right, and if so,
does Wine implement it? I grepped the sources and the only mention is in
an IDL file, so I'd assume not.
It is not implemented yet.
Should not be hard though. It belongs to OLE32 I guess.
- winedefault.reg entries.
- add to OLE32_DllGetClassObject().
- add a brief static implementation of IGlobalInterfaceTable and return
that.
Ciao, Marcus
Re: Consoles (1/3)
On Sat, Mar 01, 2003 at 10:22:13AM -0800, Dan Kegel wrote: Eric Pouech wrote: So what's new? Copy and paste from wineconsole has always defeated me. It has literally never worked properly. All the backtraces I've posted have been done using redirection. Err, just press Shift and the select the area you want to copy. Ciao, Marcus
Re: gcc 3.2.2?
Gregory M. Turner wrote: 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... Wine even compiles and works fine with the gcc 3.3 branch. It also compiles with 3.4 branch, but I have not tested it with it yet (I think it will also work). So gcc version is not a problem. Ciao, Marcus
Re: Problem with recent builds under RH8.0
On Tue, Feb 18, 2003 at 02:13:35PM +0100, Lionel Ulmer wrote: As I said, my GL headers come from the CVS pull from the DRI, not from any pre-packaged headers. Well, I think the problem comes from one of your OpenGL headers... Can you do a 'grep GL_VERSION_1_3' in your GL headers (mostly GL.h I think). From what I suspect, you will get something like this : #define GL_VERSION_1_31 The problem is that your OpenGL library is NOT implementing GL 1.3 (as shown in your glxinfo output). This means that you have a mismatch between your system headers and your library. This could be considered as a bug to report to the DRI people (if they really provide a gl.h which defines GL_VERSION_1_3, they should also provide a library with all OpenGL 1.3 entry points). We *could* fix this in Wine by adding yet another configure check (or going the full 'GetProcAddress' way which would be needed if we wanted a nice OpenGL packaged Wine) but well, sometimes enough is enough and stuff should be fixed outside of Wine and respecting the rules instead of adding yet another work-around. I have the same problem, Mesasoft headers are used during compile, but the xf86glx libraries are installed. The former are 1.3, the latter not which leads to that problem. Ciao, Marcus
Re: Resources and more with Darwin
First, windres supports any conversions between .rc, .res, .o files, whereas wrc supports only .rc - .res. It would be interesting (from the Winelib point of view) to also support .rc and .res - .o. The other transformations supported by windres (.o - .res - .rc) are not as interesting, as they are not used in the build process. from: http://www.winehq.com/hypermail/wine-devel/2002/12/0168.html I would like to know if you still plan this. I mean do you plan to use wrc instead of windres? Hmm, as of now we use the winebuild tool to convert the .res files into the C structure bytecode, so we have the .res - .o in a fashion. Ciao, Marcus
Re: Resources and more with Darwin
On Sun, Feb 16, 2003 at 06:22:56PM +0100, Pierre d'Herbemont wrote: Hi all! I am trying to build wine onto Max OS X/Darwin. I am getting trouble with windres and the *.res files. I would like to know if it would be possible to have winelib running without those resources, I mean, could I build a program and link it fine without those resources? What trouble? It should just work, be basically just convert bytestreams into a C file. In a second time I would like to know if you plan to use wrc as the only (without windres) resource manager. I have read in the list something like that, could you give me the confirmation? Huh? Also I would like to know in which measure is the Elf file format implicated in wine (in opposition to darwin's mach-o). It is not, but basically we require shared libraries of some kind. Ciao, Marcus
Re: wine/ win32/device.c server/trace.c server/tim ...
On Sun, Feb 16, 2003 at 02:09:30PM -0800, Dan Kegel wrote: Eric Pouech wrote: ;-) anyway, Uwe's patch doesn't fix all the issues I have here (it seems there is still an initialized pointer around) Another reason to look forward to the coming unification of wine threads with NPTL threads: getting Valgrind running will be easier... Which will not help at all with filedescriptors. Ciao, Marcus
Re: Crash in MSVCRT_type_info_name
On Sun, Feb 09, 2003 at 06:29:14PM +0100, Uwe Bonnes wrote: Hallo, Altera Quartus crashes soon after start when run with builtin msvcrt: 0009:Call msvcrt.?name@type_info@@QBEPBDXZ(0062) ret=407ec69a trace:msvcrt:MSVCRT_type_info_name trace:seh:EXC_RtlRaiseException code=c005 flags=0 addr=0x402a680b trace:seh:EXC_RtlRaiseException info[0]= trace:seh:EXC_RtlRaiseException info[1]=006a I didn't see where the argument(0062) comes from. Any ideas? Well, however we implemented this function, we most likely did it wrong I would guess. Ciao, Marcus
Re: cvs wine + win2k ole + installshield = unhappy
On Sat, Feb 08, 2003 at 03:48:37AM -0800, Dan Kegel wrote: Dan Kegel wrote: An installer made with plain old Installshield 6. ... Start the installer (SETUP.EXE) with the command $ wine --dll compobj,storage,ole,ole2,ole32,oleaut32,rpcrt4=n SETUP.EXE OK, I have more data. wine-20030115 works without any DLL overrides; cvs wine requires overrides, otherwise it hangs after a while. This is a regression. Yes, someone else spotted it already. One patch is breaking named pipes. Ciao, Marcus
Re: cvs wine + win2k ole + installshield = unhappy
On Fri, Feb 07, 2003 at 01:52:34PM -0500, Vincent Béron wrote: Dan Kegel a écrit: Roderick Colenbrander wrote: Installing IS6 installers is not very hard on Wine. You don't need any windows dlls. You need to have the winedefault.reg file installed and after that you need stdole32.tlb from windows. For the rest no native files are needed. Does ./tools/wineinstall properly install winedefault.reg? It does install it (or did last time I used it, and those lines are still in it). If so, then it looks like you might be mistaken. Shall I file a bug report? Please give us full error messages and/or detailed descriptions. Ciao, Marcus
Re: Started playing with Wineserver on mingw/cygwin again
Do we have a definitive explanation of just how bad the current wine/pthread incompatibilities are, and/or where current efforts are at? I'd not known there were any efforts to get wine working with nptl (hence my perhaps exaggerated alarm) until the link to Ingo's kernel patch was posted (aug2002 moreover) which suggests at least that some people *are* working on this (phew). I would be very grateful to know what the status is. Anyone? TIA. There are no known current efforts. However I talked to Ulrich today and he said (and I agree) that it will be way easier to implement threading on top of (nptl) pthreads today. Just no one started/did it yet. And we do not need the glibc developers, the ball is in our park ;) Ciao, marcus
Re: Started playing with Wineserver on mingw/cygwin again
On Thu, Feb 06, 2003 at 03:31:52PM -0600, Chris Tooley wrote: On Thu, 2003-02-06 at 15:10, Alexandre Julliard wrote: Geoff Thorpe [EMAIL PROTECTED] writes: Do we have a definitive explanation of just how bad the current wine/pthread incompatibilities are, and/or where current efforts are at? I'd not known there were any efforts to get wine working with nptl (hence my perhaps exaggerated alarm) until the link to Ingo's kernel patch was posted (aug2002 moreover) which suggests at least that some people *are* working on this (phew). I would be very grateful to know what the status is. Anyone? TIA. I've been in touch with Ingo, and I'm looking into the issue. However I'm currently moving, so things are a bit hectic around here, and I don't have good internet access. Hopefully things will settle down a bit soon so that I can get some real work done... I realize that this discussion is targeted at a real solution to the problem, however some of us are already in the situation and are too dumb to know how to deal with it. On the RedHat Phoebe (Beta versions already exhibit this problem) it was said that using LD_ASSUME_KERNEL=2.2.5 would solve the problem but that didn't work for me. However, there was a workaround on the vmware newsgroup (vmware is afflicted with a similar disease) that preloads a small .so to make it work. This might be useful for some people. I've used it with some success on my installation of wine. I've attached the modified newsgroup posting below in case someone else would like it. I posted the same thing 2 weeks ago on wine-patches if someone wants to go that way for now ;) It will not work when the NPTL threading is enabled, see the other discussions. Ciao, Marcus
Re: Started playing with Wineserver on mingw/cygwin again
On Wed, Feb 05, 2003 at 09:00:27AM -0500, Dimitrie O. Paun wrote: On February 5, 2003 03:36 am, David Fraser wrote: Under cygwin, there is no clone call as far as I can make out ... there is pthreads support and there is hackish support for fork. Do threads in Cygwin's pthreads map one-to-one to Windows threads? Can Wine use pthreads to implement its threading? I'm curious about that myself, Alexandre was saying that we have to do it, to accommodate the new glibc threading changes. I'd say this is a top issue since I expect the new glibc to make it's way into distributions fairly soon (maybe by RedHat 9.0), and which point we'll be in a lot of trouble. What's the thinking on this, currently? No, Redhat Phoebe is affected already (is that 8.1?). Shipping soon. Ciao, marcus
Re: infinite loop in msvcrt dll
On Sun, Feb 02, 2003 at 12:34:53AM +0100, Michael Stefaniuc wrote: Hello, when starting ACT!2000 with wine the program freezes after the main window is brought up and one wine process goes mad and eats all the cpu. Running strace on that pid dosn't show any system call and even the relay output stops. I've attached with gdb to the wine process and got a backtrace with 3569 entries. I've captured the output with screen and attached it. Seems to be a loop in an exception handler (sigsegv's over and over again). I hope that somebody can do more with the output. The last entries in the relay output are tons of: 0009:Call kernel32.TlsGetValue() ret=405d833e 0009:Ret kernel32.TlsGetValue() retval=402a7810 ret=405d833e 0009:Call msvcrt.__CxxFrameHandler(403821f0,40592c60,4038226c,40382180) ret=400c42b7 fs=008f eax=179c3008 ebx=400f6204 ecx=4010de20 edx=40382d54 esi=403821f0 edi=400f5fe1 ebp=40382150 esp=40382124 ds=002b es=002b gs=0007 flags=0246 0009:Ret msvcrt.__CxxFrameHandler() retval=0001 ret=400c42b7 fs=008f eax=0001 ebx=400f6204 ecx=4010de20 edx=40382d54 esi=403821f0 edi=400f5fe1 ebp=40382150 esp=40382124 ds=002b es=002b gs=0007 flags=0246 0009:Call msvcrt.__CxxFrameHandler(403821f0,40592ce8,4038226c,40382180) ret=400c42b7 fs=008f eax=179c3030 ebx=400f6204 ecx=4010de20 edx=40382d54 esi=403821f0 edi=400f5fe1 ebp=40382150 esp=40382124 ds=002b es=002b gs=0007 flags=0246 In the -debugmsg +msvcrt output i see some: warn:msvcrt:msvcrt_mbc_to_wc MultiByteToWideChar failed on 73 lines, but i suspect this is not the problem. When running with -dll msvcrt=n the error dosn't occur. 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. Ciao, Marcus
Re: Avoiding tempnam (in favor of mkstemp)
On Sun, Feb 02, 2003 at 06:12:06PM -0500, Dimitrie O. Paun wrote: On February 1, 2003 03:31 am, Gerald Pfeifer wrote: We have had some (security-relevant) warning regressions for the following two programs in tools: There's no regression -- these utilities have been using tempnam() from their very beginnings... :) Would you mind using mkstemp() instead of tempnam()? I'm afraid that's not possible. I need a file name to pass to other processes, not a file descriptor. Any other suggestions? mkstemp returns both filename and descriptor, it modifies the passed argument array. There is just the caveat that it needs the filename to end with XX. Ciao, Marcus
Re: common file dialogs
On Fri, Jan 31, 2003 at 10:56:28AM +, Mike Hearn wrote: Hi, Is there a reason that: a) The Wine open/save dialog boxes don't show or follow symlinks and b) They show dotfiles? I seem to recall a discussion on wine-devel way back on the topic of dotfiles, but a quick archive search didn't turn up much of use. At the very least I think it should be a pref, wading through lots of dotfiles in your home dir makes it much harder to open files with wine, and obviously non-technical users will wonder what is going on with all these stranges folders that I never made.. Check out the config file: [wine] ;ShowDirSymlinks = 1 ;ShowDotFiles = 1 Ciao, Marcus
Re: open_master_socket ???
On Mon, Jan 27, 2003 at 01:00:46AM +0400, Auge Mike wrote: /* open the master server socket and start waiting for new clients */ open_master_socket Who can explain for me the task of the above function in more words? Why we need to do fork() inside this function, although the parent of this process will terminate after the child do call acquire_lock()? To daemonize the server process (detach it from the current session group), so it is not affect by signals or similar from it. See 'man setsid'. Ciao, Marcus
Re: Unhandled exception in VB app Yardi Property Management
On Sat, Jan 25, 2003 at 12:06:10AM -0800, Dan Kegel wrote: A local company wants to run Yardi Professional Property Management, a VB app that doesn't use Access, under Wine. (See http://www.yardi.com.) I tried it under CVS wine as of a few days ago. Happily, the setup program completes, with just a few warnings and one 'illegal function call' vb dialog box, e.g. err:ddeml:WDML_CreateString Unknown code page 437 err:module:BUILTIN32_LoadLibraryExA loaded .so but dll commdlg.dll still not found - 16-bit dll or version conflict. ... Not bad, I guess; after all, setup did run all the way to the end. Problem came when I tried running the app. It gets an unhandled exception -- and oddly, the wine debugger refused to run. [dank@boogie PMWPROG]$ wine --debugmsg +wc_font Y.EXE err:fixup:NE_LoadSegment No implementation for HEDLG.26, setting to 0xdeadbeef err:fixup:NE_LoadSegment No implementation for HEDLG.27, setting to 0xdeadbeef fixme:hook:SetWindowsHookEx16 System-global hooks (7) broken in Win16 fixme:hook:SetWindowsHookEx16 System-global hooks (2) broken in Win16 wine: Unhandled exception, starting debugger... trace:wc_font:WCUSER_SetFontPmt = LMisc Fixed h=13 w=0 trace:wc_font:WCUSER_DumpLogFont InitFamily: truetype lf.lfHeight=99 lf.lfWidth=97 lf.lfEscapement=0 lf.lfOrientation=0 lf.lfWeight=400 lf.lfItalic=0 lf.lfUnderline=0 lf.lfStrikeOut=0 lf.lfCharSet=0 lf.lfOutPrecision=3 lf.lfClipPrecision=2 lf.lfQuality=1 lf-lfPitchAndFamily=18 lf.lfFaceName=LAdvMICR err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting Editing ~/.wine/config and changing UseXTerm to 0 helped there. (And what the hell, I can never get wine debugger copy-and-paste to work properly with that at its default value, so it's just as well.) The error was: Unhandled exception: privileged instruction in 16-bit code (25f7:0ca4). Backtrace: =0 0x25f7:0x0ca4 (bp=6cd4) 1 0x00f7:0x (bp=6d1c, far call assumed) 2 0x407cf7dd (K32WOWCallback16Ex+0x45(vpfn16=0x25f70c78, dwFlags=0x0, cbArgs=0x18, pArgs=0x40e12b90, pdwRetCode=0x40e12b88) [wowthunk.c:298] in kernel32.dll.so) (ebp=40e12b68) 3 0x412d8005 (StgIsStorageILockBytes16+0x75(plkbyt=0x26ff0042) [storage.c:1716] in ole32.dll.so) (ebp=40e12bbc) Now this should work. What does -debugmsg +relay,+ole say just before the crash? However, if it will try to create a IStorage interface later (most certainly) it will just fail, I did not come around to implement it yet. You still have to use: -dll compobj,storage,ole...=n Ciao, Marcus
Re: PATCH: glibc 2.3.x and errno
On Sat, Jan 25, 2003 at 04:43:09AM -0800, Francois Gouget wrote:
On Fri, 24 Jan 2003, Ulrich Weigand wrote:
[...]
This means that C source code compiled against the new headers will
result in assembler code that *directly* accesses a thread-local
variable as defined by the TLS ABI. In the case of errno, this
will involve accessing the %gs segment using an offset from the GOT,
without any function call being performed. (errno is defined to use
the initial-exec TLS storage model.)
I probably only have a limited understanding of these threading
problems. However I had an idea and this limited knowledge lead me to
believe that it might work and so now I have to inflict it on the
worldg.
So basically the problem as I understand it is that both Linux libraries
and some Windows applications believe that the %gs register points to a
TLS structure, except that these two structures are not compatible.
No, this is just a side problem only for 16bit applications.
The problem is different.
Lets have a small example:
wine does:
#include errno.h
...
ret = mkdir(/blub/);
if (ret == -1) {
fprintf(stderr,mkdir failed with errno %d\n,errno);
exit(1);
}
In 1980 this was rather nice and worked all the time with the nice global 'errno'
integer variable. However, someone had to invent multi threading.
After this, errno could not stay a global integer variable, since you could get
into race conditions writing/accessing it. Sinc millions of lines of code
could not be changed, the errno.h header was changed to defined it as:
extern int *__errno_location();
#define errno *(__errno_location())
With __errno_location (or similar) a function that returns a pointer to an
integer variable within the thread local storage area.
(The same goes for __h_errno_location and other internal functions.)
The glibc implementation basically does:
... convert registers ...
int 0x80
jae error
lret...
error:
...
lcall __errno_location
mov errorcode , ($eax)
...
lret
glibc follows the pthread style of threading, at the time WINE needed threading
implemented by SIGALRM timers within a single process (clone(2) was not invented
yet).
As WINE started Win32 threading the clone(2) handler was available for us and
we implemented our own kind of threading, Windows style. glibc however does not
know a single thing about that and still assumes there is no threading and
had __errno_location return a single pointer.
So we had to overwrite __errno_location(), which was easy possible, since libpthread
also did so and it was exported as weak symbol meant to be overwritten.
However with glibc 2.3 the internal thread representation changed, most pthread
libraries now use clone(2) too, and use a new way of Thread Local Storage,
using a segment register. Since WINE was using %fs, they chose to use %gs.
Now a system call looks like:
... convert registers ...
int 0x80
jae error
lret...
error:
...
mov errorcode , %gs:(offset)
...
lret
So we no longer can overwrite __errno_location to have our own errno storage, so
we need to cooperate with the libc threading.
Ciao, Marcus
Re: debugger detection in newbin.
On Thu, Jan 23, 2003 at 10:12:32AM +0100, Rein Klazes wrote: Hi, The latest version of newsbin 4.1B5 refuses to run, displaying debugger or monitoring tool detected. The detection code is very simple, immedeately at the program entry point 0x516000 it does (intel syntax): | Disassembly of 0x00516000 | 0x51600D: 64A02300 mov al,fs:[0x23] | 0x516013: EB03 jmp 0x516018 | ;*** | 0x516018: 84C0 test al,al | 0x51601A: EB03 jmp 0x51601f | ;*** | 0x51601F: 7567 jnz 0x516088 This jump is taken and leads immedeatly to the messagebox displaying the message above. Any idea's and/or explanation? Well, we store the thread pid there, see thread.h: DWORDpid;/* !2- 20 Process id (win95: debug context) */ Try to move the pid somewhere else and mark this field as unused. Ciao, Marcus
Re: PATCH: kernel / errno testing
On Wed, Jan 22, 2003 at 12:49:50PM -0800, Francois Gouget wrote: On Wed, 22 Jan 2003, Dan Kegel wrote: Marcus Meissner wrote: Hi, glibc 2.3.current CVS is throwing a huge stone in our direction, it no longer allows overload of __errno_location. To visualize this problem I have added this testcase. ... sched_yield(); /* will not change errno */ BTW sched_yield() is allowed to be a no-op; would nanosleep() or something like that be a better choice? Even better, can we achieve the same effect with a Win32 function? Maybe Sleep(10) (milliseconds) or something like it? It seems like it should be possible to write this without any platform dependent code. The problem is to avoid functions that might change 'errno'. Almost all could do that, we want to avoid that. nanosleep() might be ok. Ciao, Marcus
Re: Installshield 6 crash: ole trouble
On Wed, Jan 22, 2003 at 01:50:36PM -0800, Dan Kegel wrote: Marcus Meissner wrote: IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real windows to wine's system directory. I will add a large message suggesting that. Thanks. (I'm also looking forward to the possibility of wine having its own stdole32.tlb soon.) It looks like there's a Heisenbug here. If I run without logging, I get a window titled Unhandled Exception, with contents Error Number: 0x80040706 Description: Object reference not set Setup will now terminate. I have seen this on and off, but I thought I fixed it. Interestingly, under wine20020605, I am able to complete the installation program. Thus we seem to have a regression. Which would be more helpful: me tracking down which patch caused the regression, or me sending some more knowledgeable person a minimal test case? Hmm, I think binary search for the broken patch would be easier. Ciao, Marcus
Re: Buiz talk
On Tue, Jan 21, 2003 at 09:32:45AM +0100, Uwe Bonnes wrote: Hallo, on http://www.vnunet.com/News/1138118 Suse's Dan Homolka is cited with: Dan Homolka, technical sales manager at SuSE, claimed that the vendor's Linux environment actually runs Microsoft Office faster than Windows mainly because Linux is much better at context-switching. Well, you know sales statements, piped through unreliable reporters etc. The announcement does not include that statement: (englisch) http://www.suse.de/en/private/products/suse_linux/office_desktop/index.html (german) http://www.suse.de/de/private/products/suse_linux/office_desktop/index.html Suse Window support is based on Codeweavers Cross Office. Yes. Does this stand a real world test? Well, we hope so. Ciao, Marcus (end of advertisement ;)
Re: Installshield 6 crash: ole trouble
On Tue, Jan 21, 2003 at 09:43:29AM +, Mike Hearn wrote: Would this be fixed by the work that's being done on Wines RPC implementation? This is a different implementation, when it is finished ... yes. The current implementation should be capable of doing that too. Why exactly does an installer require such complex parts of OLE anyway? That seems like overkill for a self-extracting exe to me. No clue. Ciao, Marcus
Re: Installshield 6 crash: ole trouble
On Tue, Jan 21, 2003 at 04:26:28PM +0100, Sylvain Petreolle wrote: what are the missing functions that live in stdole2.tlb ? is someone trying to implement it ? The TLB is a typelib file, which is compiled from a .IDL file. So widl needs to generate it at one point. Ciao, Marcus
Re: Stdole32.tlb (was: Installshield 6 crash: ole trouble)
And what's wrong with importing lots of structures, if unused typedefs aren't stored in the type library? The main problem is that the typelibs import all kinds of stuff. Stdole2.tlb imports declarations from guiddef.h, oaidl.idl, unknwn.idl, ocidl.idl, olectl.h, plus some functions and interfaces that are not in any other file. Also, the IFont interface has been slightly modified in the type lib which might break an app if it were to use our ocidl.idl version of it. Huh? How that? Is there any point in cluttering our typelib? In my opinion our typelib should at least contain all of the stdole2/32.tlb stuff. If there are some more entries, it does not really matter I guess. Where should I put such a file? I'd go for dlls/oleaut32. Standard ole32 has no need for typelibs, they're a feature of oleaut32. I'll wait a bit longer for opinions from a few more people, although your logic about type libs being an oleaut32 feature seems right to me. Go ahead with what you consider best. My acceptance criteria would be basically 'InstallShield v6 still works' ;) Ciao, Marcus
Re: Installshield 6 crash: ole trouble
On Mon, Jan 20, 2003 at 11:12:29PM -0800, Dan Kegel wrote: Dan Kegel wrote: Bobby Bingham wrote: IIRC, InstallShield 6 can work if you copy stdole32.tlb from a real windows to wine's system directory. I will add a large message suggesting that. Yep, copying just that one file made things get a lot further! After futzing around for half an hour, I finally convinced our app to install. There appear to be a lot of rough edges here; I had to turn on ole logging and run just the extracted setup.exe (not the package-for-the-web wrapper) to get things to work It looks like there's a Heisenbug here. If I run without logging, I get a window titled Unhandled Exception, with contents Error Number: 0x80040706 Description: Object reference not set Setup will now terminate. I have seen this on and off, but I thought I fixed it. Ciao, Marcus
Re: 1995-era installshield woes - foreground window never appears
On Sun, Jan 19, 2003 at 06:02:31PM -0800, Dan Kegel wrote: All the installshield stuff in the msvc4 installer seems to work -- except the Data Access Objects installer. When you run it, you get to the first screen with a big blue background, but the foreground window never shows up. It's probably there, but invisible, or something. Alt-tab doesn't help, and the blue background is full-screen, so you can't try moving it out of the way. I have to alt-tab and ^C (why that works, I dunno) to get out. Any suggestions? I'm having trouble figuring out how to track this down; win32 gui problems aren't my forte. Catch them in a desktop window for now: Ciao, Marcus Index: documentation/samples/config === RCS file: /home/wine/wine/documentation/samples/config,v retrieving revision 1.37 diff -u -u -r1.37 config --- documentation/samples/config13 Dec 2002 02:26:18 - 1.37 +++ documentation/samples/config20 Jan 2003 06:37:18 - @@ -277,6 +277,20 @@ ;UseDnsComputerName = N ;; sample AppDefaults entries + +; 3 InstallShield versions who like to put their full screen window in front, +; without any chance to switch to another X11 application. +; So just catch them in a desktop window. + +[AppDefaults\\_INS5576._MP\\x11drv] +Desktop = 640x480 + +[AppDefaults\\_INS5176._MP\\x11drv] +Desktop = 640x480 + +[AppDefaults\\_INS0466._MP\\x11drv] +Desktop = 640x480 + ;[AppDefaults\\iexplore.exe\\DllOverrides] ;shlwapi = native ;rpcrt4 = native
Re: Patch for Wine-20030115 GetFreeSpace on Solaris 8 x86
On Fri, Jan 17, 2003 at 06:03:35PM -0500, John Wehle wrote: wine ie5setup reports it can't determine the free disk space. truss shows statfs failed with EOVERFLOW and sys/statfs.h says: * Structure returned by statfs(2) and fstatfs(2). * This structure and associated system calls have been replaced * by statvfs(2) and fstatvfs(2) and will be removed from the system * in a near-future release. This patch allows wine ie5setup to at least startup. A cleaner patch would probably use an explict autoconf check for statvfs in addition to checking for sys/vfs.h. ChangeLog: Fri Jan 17 18:02:37 EST 2003 John Wehle ([EMAIL PROTECTED]) * files/drive.c (DRIVE_GetFreeSpace): Use statvfs on systems which have sys/vfs.h. This will break on Linux, it has have sys/vfs.h but no statvfs. Better use an autoconf check for the 'statvfs' function and use the result. + #ifdef HAVE_SYS_VFS_H Use #ifdef HAVE_STATVFS + struct statvfs info; + #else struct statfs info; + #endif *** 1297,1305 return 0; } ! /* FIXME: add autoconf check for this */ ! #if defined(__svr4__) || defined(_SCO_DS) || defined(__sun) ! if (statfs( DOSDrives[drive].root, info, 0, 0) 0) #else if (statfs( DOSDrives[drive].root, info) 0) #endif --- 1301,1308 return 0; } ! #ifdef HAVE_SYS_VFS_H Dito. ! if (statvfs( DOSDrives[drive].root, info) 0) #else Ciao, Marcus
Re: * Hack * for Wine-20030115 DOSFS_Hash on Solaris 8 x86
On Fri, Jan 17, 2003 at 08:40:30PM -0500, John Wehle wrote: wine photoed reports it can't find GIFIMP32.FLT (and friends) which prevents images from being imported. The trace is: trace:dosfs:DOSFS_GetFullName LC:\\PROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIFIM P32.FLT (last=0) trace:dosfs:DOSFS_FindUnixName /dos,LPROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIF IMP32.FLT trace:dosfs:DOSFS_ToDosFCBFormat (LPROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIFIM P32.FLT, df621770) trace:dosfs:DOSFS_OpenDir /dos ... trace:dosfs:DOSFS_ReadDir Read: long_name: LProgram Files, short_name: (null) trace:dosfs:DOSFS_FindUnixName checking LPROGRA~1LPROG~FBU What happens is DOSFS_Hash hashes Program Files in an unexpected fashion which prevents DOSFS_FindUnixName from realizing it matches PROGRA~1 . The enclosed * hack * allows wine photoed to load images. It is * not * the correct answer. One possible approach is to modify DOSFS_OpenDir_Normal to generate proper short names after it has read all the directory entries. The proper idea is to install the program using WINE too, so you get the same hashes into the registry. Your hack will not work if 2 files hash to the same value. Ciao, Marcus
Re: Reseting X resolution
On Sat, Jan 18, 2003 at 01:15:35AM +, Luis Marques wrote: Hello all, I like to test some DirectX applications from time to time. Problem is that they succed long enough to set the resolution but after that fail. I can Ctrl-C the application and resume working but it's not very practial to work on a 320x200 desktop... How can I restore the resolution? Is there any standard way? Should I just write a few lines of SDL code to set the resolution? Ctrl-Alt-Numpad+ or Ctrl-Alt-Numpad- Ciao, Marcus
Re: FHS vs LSB
On Wed, Jan 15, 2003 at 10:20:29PM -0500, Tom Wickline wrote: In updating the Packagers Guide I plan to replace FHS with LSB any objections ? FHS = http://www.pathname.com/fhs/ LSB = http://www.linuxbase.org/ The FHS is a part of the LSB standard. And we cannot be LSB compliant, we need way more in the matter of system calls and ioctls than LSB allows ;) Ciao, Marcus
Re: html browser for wine (khtml)
On Thu, Jan 09, 2003 at 11:21:18AM -0500, Dimitrie O. Paun wrote: On January 9, 2003 12:14 pm, Alexandre Julliard wrote: I'd prefer to avoid C++, but if there's no other choice then of course we'll have to do it. I'm still hoping that we can find a way to avoid duplicating all that code inside Wine, C++ or not. Well, it seems the only worthy alternatives are Mozilla and KHTML, and they are both written in C++. I am 100% with you on the non-duplicating bit: even if we get something in the tree, it's not going to be maintained, and it will bitrot to fast for words. It would be a huge addition and burden to maintain for the Wine project. Galeon does not include Mozilla -- it uses it. There's got to be a way to use KHTML in a similar manner. Even my first hand approximation (using the Win32 build of Mozilla) seems like a better option than duplicating code. If we get that working, I'm sure we can work with the Mozilla team to find a way of embedding the Linux version. Heck, Galeon does it! Actually there already was a Konqueror / WINE integration already, called reaktivate. It replaced urlmon and provided a IWebBrowser interface. Ciao, Marcus
Re: html browser for wine (khtml)
On Thu, Jan 09, 2003 at 12:28:38PM -0500, Dimitrie O. Paun wrote: On January 9, 2003 01:46 pm, Marcus Meissner wrote: Actually there already was a Konqueror / WINE integration already, called reaktivate. It replaced urlmon and provided a IWebBrowser interface. Sweet! This is exactly what I was hoping for. [...searching for it...] Here's the original announcement: http://dot.kde.org/994747675/ But this seems to be going what cxplugin does. We need the complement of that, don't we? Not sure, it might just work both ways. Will have to go back and check. Ciao, Marcus
Re: Symbol stripping?
On Wed, Jan 08, 2003 at 08:59:39AM +, Mike Hearn wrote: What does gcc prior to 3.1 do with the -gstabs+ flag? If it ignores it, or it's implied anyway, we could just have it always on. If not then I have some bash here that can parse the output of gcc -v and determine whether it's = 3.1, would that be acceptable as a patch to configure.ac? The only other way would be to compile a little test app then run objdump on it to figure out if stabs data was included, but testing the GCC version would be faster. I submitted a patch which adds -gstabs to CFLAGS if necessary. Ciao, Marcus
Re: prevent dereferencing null
On Thu, Jan 09, 2003 at 05:45:00PM -0800, Bill Medland wrote:
On January 9, 2003 03:12 pm, Dimitrie O. Paun wrote:
On January 9, 2003 07:08 pm, Bill Medland wrote:
+if (!tpinfo-chanbuf) {
+ERR(tpinfo has no Rpc Channel Buffer\n);
+return 0;
+}
Is this expected behaviour? If so, there's no need for the ERR msg.
If not, there's no need for the test, we need to fix the root cause...
You are, of course, quite correct.
I don't know what the expected behaviour is; all I know is that dereferncing
the null pointer isn't.
If someone actually understands all that proxy stuff then maybe they can do
something about it.
If not then I guess it is destined to languish unfixed.
I vaguely remember this happening for inter-thread COM, I did not come around
to debug it yet.
return E_FAIL; might be more appropriate too.
Ciao, Marcus
Re: dlls/Makefile.in
On Tue, Jan 07, 2003 at 07:17:38AM -0600, Jeff Smith wrote: From: Marcus Meissner [EMAIL PROTECTED] Some not so compatible versions of make only like this variable in pattern replacement rules, so this might not work on all platforms. I tried looking into this before submitting the patch, but did not come up with anything. Do you know of any *specific* cases? I did not find it again off hand. And I don't see a reason for this change, these entries are generated by a script and who should care if they are longer or not? What script? dlls/make_dlls Ciao, Marcus
Re: problem building tests with msvc6
On Sun, Jan 05, 2003 at 12:13:26PM -0800, Dan Kegel wrote: Trying to build conformance tests on Windows Me with msdev6, but got the following link errors: safearray.obj : error LNK2001: unresolved external symbol _IID_IStorage safearray.obj : error LNK2001: unresolved external symbol _IID_IDispatch safearray.obj : error LNK2001: unresolved external symbol _IID_IUnknown Output\Win32_Wine_Headers/oleaut32_test.exe : fatal error LNK1120: 3 unresolved externals Any suggestions? (Sorry to act so helpless...) Hmm, should be linked against the GUID library. No clue how to do that. Or we could define the IIDs inline again. Ciao, Marcus
Re: but report -- the last line tell me do this
On Mon, Jan 06, 2003 at 06:39:36PM +0800, yf wrote:
[yf@yf 2002]$ wine ./hexin.exe
fixme:ole:CoRegisterMessageFilter stub
fixme:shdocvw:WBPCI2_GetGUID stub: dwGuidKind = 1, pGUID =
{----}
fixme:shdocvw:WBPCI2_GetGUID Wrongly returning IPropertyNotifySink interface
{9bfbbc02-eff1-101a-84ed-00aa00341d07}
fixme:shdocvw:WBQA_QuickActivate stub: QACONTAINER = 0x40760874, QACONTROL =
0x407608b4
fixme:shdocvw:WBPSI_InitNew stub
fixme:shdocvw:WBCP_Advise stub: IUnknown = 0x4183bfe4, connection cookie = 0
fixme:shdocvw:WBOOBJ_SetExtent stub: (0x41f0a940, 1, (0 x 0))
fixme:shdocvw:WBOOBJ_DoVerb : stub iVerb = -5
fixme:shdocvw:WBOOBJ_DoVerb stub for OLEIVERB_INPLACEACTIVATE
fixme:shdocvw:WBOC_GetControlInfo stub: LPCONTROLINFO = 0x4183bf84
fixme:shdocvw:WBOIPO_GetWindow stub HWND* = 0x40760980
fixme:shdocvw:WB_Invoke stub dispIdMember = -518, IID =
{----}
fixme:shdocvw:WBCP_Unadvise stub: cookie to disconnect = 1099153244
fixme:shdocvw:WBCP_Unadvise stub: cookie to disconnect = 1099153168
fixme:shdocvw:WBCP_Unadvise stub: cookie to disconnect = 1
fixme:shdocvw:WBOIPO_InPlaceDeactivate stub
fixme:shdocvw:WBOOBJ_SetClientSite stub: (0x41f0a940, (nil))
fixme:shdocvw:WBOOBJ_Close stub: ()
I get as far, than it fscks up its double byte names.
With what 'LANG' var do you run it?
err:clipping:CLIPPING_UpdateGCRegion hVisRgn is zero. Please report this.
This will do an immediate exit(1); so WINE terminates here. It probably
should not.
Ciao, Marcus
Re: dlls/Makefile.in
On Mon, Jan 06, 2003 at 01:55:26PM -0600, Jeff Smith wrote: Changelog: Make use of the automatic variable $ in dll make rules. advapi32.dll$(DLLEXT): advapi32/advapi32.dll$(DLLEXT) - $(RM) $@ $(LN_S) advapi32/advapi32.dll$(DLLEXT) $@ + $(RM) $@ $(LN_S) $ $@ Some not so compatible versions of make only like this variable in pattern replacement rules, so this might not work on all platforms. And I don't see a reason for this change, these entries are generated by a script and who should care if they are longer or not? Ciao, Marcus
Re: Windows XP conformance test update 1/5
oleaut32/safearray reports 8 failures but the page only shows 4 failures. Simple, I did update these tests after your last run. C:\winetestsoleaut32_test.exe safearray safearray.c:137: Test failed: SAC(20,1,[1,0]), result 8, expected 0 safearray.c:143: Test failed: SAGE for vt 20 returned elemsize 8 instead of expected 0 safearray.c:159: Test failed: copy of SAC(20,1,[1,0]), result 8, expected 0 safearray.c:162: Test failed: SAGE for vt 20 returned elemsize 8 instead of expected 0 safearray.c:137: Test failed: SAC(21,1,[1,0]), result 8, expected 0 safearray.c:143: Test failed: SAGE for vt 21 returned elemsize 8 instead of expected 0 safearray.c:159: Test failed: copy of SAC(21,1,[1,0]), result 8, expected 0 safearray.c:162: Test failed: SAGE for vt 21 returned elemsize 8 instead of expected 0 safearray: 958 tests executed, 0 marked as todo, 8 failures. But these are still the same failures, just twice now. Ciao, Marcus
Re: Patch/workaround for configure problem
On Sun, Jan 05, 2003 at 02:41:07PM -0500, Nathan Boyle wrote: I don't know whether someone is adding or removing a DLL or something[ctl3d doesn't appear to be in the repository], but i had to make the following patch in order to configure and compile the wine sources that i downloaded from CVS a half hour ago[It is more a work-around then a patch] The patch is in plain text below. -dlls/ctl3d/Makefile You need to run 'cvs update -PAd' so you get new directories from CVS. Ciao, Marcus
Re: WinXP conformance test update
On Fri, Dec 27, 2002 at 05:57:18PM -0500, Dave Miller wrote: These tests were run on Windows XP Professional using the latest precompiled binaries. The results of any tests not listed on or not matching http://fgouget.free.fr/wine/tests-en.shtml C:\winetestsoleaut32_test.exe safearray safearray.c:131: Test failed: SAC(20,1,[1,0]), result 8, expected 0 VT_I8 safearray.c:131: Test failed: SAC(21,1,[1,0]), result 8, expected 0 VT_UI8 These results are different for Win2000, there it just returns 0. safearray.c:131: Test failed: SAC(37,1,[1,0]), result 4, expected 0 safearray.c:131: Test failed: SAC(38,1,[1,0]), result 4, expected 0 These have no VARTYPES in our wtypes.idl :/ Does anyone have reference to a newer idl reference? Ciao, Marcus
Re: Mac OS X Port of WineLib
On Thu, Dec 26, 2002 at 09:56:01PM -0500, [EMAIL PROTECTED] wrote: Hi, I dont recall how I stumbled upon Wine and its existance, however I am intersted in recent, if any, devlopments with the porting of Wine to OS X. I checked the Wine site and most of the articles are dated with the lastest date of Nov 2000. A lot has changed in OS X since that time and it appears that a leats a couple of the main issues have been addressed during this time. The main issues which seemed to be posted are as follows: I fixed the Linux/PowerPC port. So any PowerPC processor related issue is ok. Current list of possible issues: - Endianness. Since we are using WineLib, could have resources written in native (big) endian format with wrc. Any external data files such as cursors, bitmaps, sound would have to be converted. The PUT_WORD/GET_WORD macros need byte swapping turned off. (Did I miss anything?) Is ok. - Exception handling, Signal handling code Depends on MacOS X. - Memory alignment issues Should not be a problem. - According to Inside MacOS X: Kernel Environment (A HREF=http://developer.apple.com/techpubs/macosx/Kernel/KernelEnvironment.pdf;http://developer.apple.com/techpubs/macosx/Kernel/KernelEnvironment.pdf/A) pg. 34, Darwin supports Pthreads, many of the POSIX APIs I haven't been able to find any lists of incompatibilities yet, but I am afraid of the word many. WINE needs a different kind of threading, this might be problematic. - Sound Support. Currently done with WineOSS (ties into Linux OSS drivers) Doesn't seem to be a port of OSS to MacOSX. Maybe need to do another layer specific to the Mac(?) Err, we support audio drivers and have several others non-OSS already. No problem here, just implement a MacOS X sound driver. - Must ensure that behaviour of lower level UNIX resources like sockets, threads, files are the way WINE expects it. This might be more difficult. Especially the memory management. - Presence of Assembly language in code will have to be written in C or translated to PowerPC assembly. (assembly is generated in spec.c files, as well as other places like in the server) Is done already, for the normal PPC32 ABI. Good luck. Ciao, Marcus
Re: Wine, Windows.Forms on Linux, GC and segfaults.
On Wed, Dec 11, 2002 at 01:05:32PM -0500, Miguel de Icaza wrote: Hello, The problem is that by the time that Wine has been initialized, using setjmp/longjmp will always lead to a crash. The code in pthreads that performs the longjmp will first try to invoke the pthread cleanup routines, and then invoke longjmp. This never happens. You can't and needn't link with -lpthread. Wine has its own pthread implmentation. I tried your included code and it works just fine unless you link with -lpthread, then it crashes in the same way as in your attached picture. But then you should never link Wine with -lpthread so that is not really a bug. Of course Wine pthread implementation it not in any way complete so some function might be missing and some might only be only partially implemented and of course some might be incorrectly implemented. So please try again without linking with -lpthread. The problem is that this is very hard for us to do as two of the underlying libraries we are using (libmono and libgc) both link against pthread to achieve their threading capabilities. It might be better to investigate what are Wine's requirements for having its own pthread implementation, and have those changed pushed to the maintainers of pthreads. In particular, we are interested in using WineLib, maybe it would be possible to have WineLib use the standard pthread implementation instead of rolling its own? This would be very difficult. WINE implements the Win32 threading/process and synchronisation model. It needs to use the OS native threads so it gets the stack maintenance and the correct handling of the %fs. So WINE cannot change to pthreads without major hacks to the pthread library I guess. Ciao, Marcus
LHashValOfNameSysA for 407
Hi, I have an app here, which uses locale 407, for which we do not implement LHashValOfNameSys yet... It reports: err:ole:LHashValOfNameSysA No hash for LCID 407, returning '0x00424242', please report If someone wants to fix it :) Ciao, Marcus
Re: Wine, Windows.Forms on Linux, GC and segfaults.
On Tue, Dec 10, 2002 at 08:41:34PM -0500, Miguel de Icaza wrote:
Hello,
With the help of Hans Boehm, I have been tracking the problems we
have to run the Windows.Forms code with GC enabled. Turns out that the
problem is not the Boehm code at all, it just exposes a problem that
might be happening elsewhere.
The problem is that by the time that Wine has been initialized,
using setjmp/longjmp will always lead to a crash. The code in pthreads
that performs the longjmp will first try to invoke the pthread cleanup
routines, and then invoke longjmp. This never happens.
In the particular case of Mono, I added a small bit of code before
calling into Boehm's GC, and then I run my app like this:
wine monostub.exe.so
The code snippet is:
jmp_buf buf;
printf (Here\n);
if (setjmp (buf) == 0){
printf (before\n);
longjmp (buf, 1);
} else {
printf (after\n);
}
The code should display:
Here
before
after
But with Wine, I get a crash inside longjmp, after the before is
printed out. I get the Wine Console with the stack trace, but I can not
copy/paste from it, so I have included a screenshot of it.
You currently cannot use the wine libraries together with -lpthread.
WINE already overwrites and reimplements several pthread_ functions
which probably leads to internal confusion and the crash above.
Difficult to solve :/
Ciao, Marcus
Re: lz32 kernel32
On Tue, Dec 10, 2002 at 01:06:54AM -0800, Francois Gouget wrote: I have checked the Wine spec files against the list of APIs exported by the various Windows libraries and started on resolving the discrepancies. One of the (smaller) things I found is that in Win2000 and WinXP the LZ API is implemented in kernel32 and lz32 only contains forwards that point to kernel32. In all other Windows version however, the LZ API is not available from kernel32 and is implemented in lz32. What should we do? Should we have kernel32 import lz32 and forward the LZ functions it? Or should we do like Windows, which means moving the LZ APIs to kernel32, and turn all the entry points in lz32 into forwards pointing to kernel32 like on Windows? If the LZ APIs are exposed from kernel32 ... Then I would say yes. Will the forwarding work for the 16bit version too? Ciao, Marcus
Re: spec file definitions
On Wed, Dec 04, 2002 at 12:21:55AM +0100, Rolf Kalbermatter wrote: I have seen some definitions of functions in a spec file where a string was defined as str or wstr. I do remember that there was an issue with this depending if the string parameter was input only (eg. const) or an input/output parameter. This is only for string parameters which are valid during input. Ciao, Marcus
Re: About picture format.
On Wed, Nov 20, 2002 at 06:59:42PM +0800, yf wrote: ÔÚ 2002-11-20 Èý µÄ 18:13£¬ Patrik Stridvall дµÀ£º 0803 2002-11-20 0605 0 802 15:27050 1 Marcus Meissner 040 70 8080502 On Tue, Nov 19, 2002 at 09:20:40PM +0800, yf wrote: I'm using a application that using 0x0010 picture format. I found that wine only support Bitmap and JPEG picture format. Where can I get some info about it. I want to implement it. Pls give me some hints about it. Where is it trying to use that picture format? In which API call? fixme:ole:OLEPictureImpl_Load Unknown magic 0010 that is wine-20021031/dlls/oleaut32/olepicture.c OK. This only means that the first two bytes in the file is 0x10 0x00. I don't know what file format that is. But if you know what file it is trying to load you can run the Unix command file on it, perhaps it will tell what type of file it is. I used, but file tell: data. That means it don't know yet. Maybe it is not a pic format, but why OLEPictureImpl_Load handle it, I wonder? Can you put that loaded file online somewhere? Or mail me? Ciao, Marcus
Re: About picture format.
On Tue, Nov 19, 2002 at 09:20:40PM +0800, yf wrote: I'm using a application that using 0x0010 picture format. I found that wine only support Bitmap and JPEG picture format. Where can I get some info about it. I want to implement it. Pls give me some hints about it. Where is it trying to use that picture format? In which API call? Ciao, Marcus
Re: vxdcall calling convention
On Mon, Nov 18, 2002 at 04:21:37PM +0100, Patrik Stridvall wrote: Le lun 18/11/2002 à 02:51, Patrik Stridvall a écrit : Corrects this line in winapi_check: win32/device.c:544: kernel32: void VxDCall(DWORD,CONTEXT86 *): calling convention mismatch: cdecl != stdcall I'm not 100% sure this really is a bug. Don't trust winapi_check too much it is very ad hoc. :-) It might however be a bug but I never got around to test it properly. So, have you verified that this really is correct? Well, kernel32.spec references them by stdcall -register -i386. Another API referenced the same way is CommonUnimpStub, and in thunk.c, it is declared as void WINAPI. Is it sufficient checking? I'm not sure, it might be the other API(s) that are wrong or that VxDCall is a special case. That why I haven't dared changed anything. I think it needs to be WINAPI, the __wine_call_from_32_regs assembler thunk does not remove arguments from stack. Ciao, Marcus
Re: kdelnk2desktop.py
On Fri, Nov 15, 2002 at 06:43:19PM -0600, Dustin Navea wrote: I just switched to slackware from Mandrake8 and I was foolin around tryin to see if ther ewas an xchat built with kdelibs and stumbled across kdelnk2desktop.py in my /usr/bin dir. im not sure if it exists in other distors but it could be a replacement for the current wineshelllink on distros that do have it. Anyone wanna look into this or want me to, let me know. ? The name suggests it is just a converter. But we already create both link formats already by our own. Ciao, Marcus
Re: COM Enhancement patch
On Thu, Nov 14, 2002 at 04:35:00PM -0800, WINE wrote: Christian Costa [EMAIL PROTECTED] writes: I've sent a patch for ddraw COM management, I did not have any comments and the patch has been rejected. Could someone tell me if something is wrong or lacking? Well, I was hoping some of the COM experts would comment on that. If I understand it right you are avoiding writing some thunking routines for older interfaces, at the cost of an extra pointer access in every function. I'm not convinced it's a good trade-off, but I'd like to hear other opinions. I do not really see the need for it either. The implementation functions know the interface they get passed, so the offset to the vtable ptr within the object is constant and can very easily be calculated by the compiler. As for increased function sharing and reduced thunks usage... True, but the number of functions is not really annoying or problematic. Ciao, Marcus
Re: Filesystem change notifications
Fam requires portmapper. If not set up properly (i.e. by someone who understands what they are letting loose) portmapper can be a serious security problem. The security community regard the introduction of fam a serious backward step on RH's part. KDE etc might use it but they do not _need_ it. You are also assuming that every distro follows RH's lead which is very definitely not true. Many people are already getting upset about the number of libraries that are required to get some packages to run. GNUCash being a prime example of package use gone mad. Can you suggest a superior alternative? Check up on directory notifications in Linux. A way cool thing. - catch SIGIO ... - fcntl(fd, F_NOTIFY, DN_xxx|DN_yyy); Ciao, Marcus
Re: PATCH: cups dynamical dependency
On Sun, Nov 10, 2002 at 11:18:27PM -0500, Dimitrie O. Paun wrote:
On November 10, 2002 02:40 pm, Marcus Meissner wrote:
Do not link against -lcups directly, but dynamically load it
if present. (just like freetype etc.)
[...]
+#ifdef HAVE_CUPS
+ /* dynamically load CUPS if not yet loaded */
+ if (!cupshandle) {
+ cupshandle = wine_dlopen(CUPS_SONAME, RTLD_NOW, NULL, 0);
+ if (!cupshandle) cupshandle = (void*)-1;
+ }
+#endif
Well, if we do this dynamically, why have this HAVE_CUPS check which is a
compile time check? IMO we should just include a copy of the CUPS headers
that we need, and drop the compile time check altogether.
Actually we would just need 4 lines of function prototypes with char*,
char** and int* arguments, no structures are passed.
In fact, this
check is misleading, as it suggests that we've verified some sort of
compatibility with CUPS which we haven't.
But we did check against at least one set of function prototypes.
We _assume_ that a certain API
is available at runtime, so why pretend we use something that's on the
machine we compile on?
It is the same for freetype.
I can do it the other way easily. I'll send a new patch later this day.
Ciao, Marcus
Re: PATCH: cups dynamical dependency
On Mon, Nov 11, 2002 at 02:26:31PM +0100, Sylvain Petreolle wrote: It is the same for freetype. I can do it the other way easily. I'll send a new patch later this day. Ciao, Marcus Couldn't this be done for all dlls thare loaded inconditionnally by another dlls ? For example comdlg32 loads winspool.drv, even if you don't want to print anything. You could use this patch: Index: dlls/commdlg/Makefile.in === RCS file: /home/wine/wine/dlls/commdlg/Makefile.in,v retrieving revision 1.24 diff -u -u -r1.24 Makefile.in --- dlls/commdlg/Makefile.in18 Oct 2002 23:46:29 - 1.24 +++ dlls/commdlg/Makefile.in11 Nov 2002 20:24:39 - -4,7 +4,8 SRCDIR= srcdir VPATH = srcdir MODULE= comdlg32.dll -IMPORTS = shell32 shlwapi comctl32 winspool.drv user32 gdi32 kernel32 +IMPORTS = shell32 shlwapi comctl32 user32 gdi32 kernel32 +DELAYIMPORTS = winspool.drv ALTNAMES = commdlg.dll EXTRALIBS = $(LIBUUID) Ciao, Marcus
Re: Wine 0.8: VB compatibility !!
On Sat, Nov 09, 2002 at 11:41:44AM -, Ann and Jason Edmeades wrote: I have a VB prog (see www.badcomp.co.uk) which I spent a long time getting working under Wine and fixed all the oleaut32 Var* routines it used. However if you look at that dll, there are still a huge number of stubs. Additionally the date/time handling is (was, anyway) pretty useless. I would strongly recommend if anyone starts writing VB testcases they try and exercise the Variant cases as well as the standard types (...and no, I dont have time!) VB Window Icons dont work in the wine tree - Marcus sent me a fix for OleLoadPictureEx which solves the problem but he never submitted it to the wine tree (I have a copy, but not of the license it was under). Also, Icons containing transparency dont work for me either, but thats not a vb thing, I guess. It has been committed to CVS now. However, most of those VB apps appear to try to load PICTYPE_ICON, which we do not support yet. Ciao, Marcus
Re: [PATCHLET] DeleteFile With Empty Paths
On Thu, Nov 07, 2002 at 02:18:20AM -0800, Ryan Cumming wrote: Hi, KaZaA Lite 2.0 calls DeleteFile with an empty path at shutdown, which triggers ERR(Empty path passed\n). It seems a bit silly to call that an error, so this patch changes the message to a warning. It also does a SetLastError(ERROR_FILE_NOT_FOUND) in that case, which is consistant with Windows XP. Can you also create a testcase for this problem? Ciao, Marcus
Re: Wine 0.8 TODO v0.2
On Thu, Nov 07, 2002 at 07:24:18PM +0100, Joerg Mayer wrote: On Thu, Nov 07, 2002 at 09:30:10AM -0800, Alexandre Julliard wrote: The spec files etc. should not be in the tree, that's right Why shouldn't thy be in the tree? Actually, I prefer to install Software (including self compiled sw) via rpm - it makes it much more comfortable to switch versions and you can be sure that there are no old versions lying around after an update - so I'd be happy if there was a file called suse-8.1.spec or so that I could use to build an rpm from the wine package. Actually you could download ftp://ftp.suse.com/pub/people/meissner/wine/8.1/wine-*.src.rpm, unpack it, drop in a new tarball and rebuild ... Or just use my monthly builds ;) Ciao, Marcus
Re: Fwd: WINE virus thing
On Tue, Nov 05, 2002 at 07:11:53PM -0500, Dimitrie O. Paun wrote: -- Forwarded Message -- Subject: WINE virus thing Date: Tue, 5 Nov 2002 22:33:29 +0100 (MET) From: Marcel Partap [EMAIL PROTECTED] To: [EMAIL PROTECTED] Dear Dimitrie, I am not on the mailing list for wine so please redirect this to the list, thank you very much. I've read the Wine weekly news and would like to help out a bit. About that security thingie and the problem that some apps need manual parameters or something (the user has to do more than click-click) I would recommend following solution: Most Nintendo 64 Emulators use INI-files, in which for each game (ROM Image) the name and shit is listed and the best options specifically for this game. I would recommend to do it exactly like this in WINE: a Application database file with weekly updates (like Antivirus definitions) which contains the names and file attributes of the (tested) application (MD5??!) and eventually the parameters necessary to run the program. Wine could then have a secure mode (turned on by default) in which only applications from the DB (MD5!) can be run and an unsecure mode in which it will run any EXE. This would solve multiple problems at once: ... The database would be huge and a support nightmare, since just everyone would be asking to add md5sums. And they change with every service pack, every subrelease Ciao, Marcus
Re: PATCH: DispCallFunc
On Wed, Nov 06, 2002 at 01:53:40PM -0500, Dimitrie O. Paun wrote:
On November 6, 2002 01:40 pm, Marcus Meissner wrote:
+
+FIXME((%p, %ld, %d, %d, %d, %p, %p, %p)\n,
+ pvInstance, oVft, cc, vtReturn, cActuals, prgvt, prgpvarg, pvargResult +
);
Why is this one a FIXME, and not a TRACE?
Because the function most likely will crash and the user will see that this
function is the problem and we get debug output.
[snip]
+/* FIXME: Must handle pvargResult. How? */
Isn't it better to issue a FIXME here, if pvargResult is not NULL?
I do not think it is supposed to be NULL at all, judging from examples, but
probably yes. I made it a printed message, and more explicit.
Ciao, Marcus
Index: dlls/oleaut32/typelib.c
===
RCS file: /home/wine/wine/dlls/oleaut32/typelib.c,v
retrieving revision 1.77
diff -u -u -r1.77 typelib.c
--- dlls/oleaut32/typelib.c 31 Jul 2002 17:20:01 - 1.77
+++ dlls/oleaut32/typelib.c 6 Nov 2002 19:05:47 -
-4192,6 +4192,52
extern int const _argsize(DWORD vt);
+HRESULT WINAPI
+DispCallFunc(
+void* pvInstance, ULONG oVft, CALLCONV cc, VARTYPE vtReturn, UINT cActuals,
+VARTYPE* prgvt, VARIANTARG** prgpvarg, VARIANT* pvargResult
+) {
+int i, argsize, argspos;
+DWORD *args;
+HRESULT hres;
+
+FIXME((%p, %ld, %d, %d, %d, %p, %p, %p)\n,
+ pvInstance, oVft, cc, vtReturn, cActuals, prgvt, prgpvarg, pvargResult
+);
+argsize = 0;
+for (i=0;icActuals;i++) {
+FIXME(arg %d: type %d\n,i,prgvt[i]);
+ dump_Variant(prgpvarg[i]);
+argsize += _argsize(prgvt[i]);
+}
+args = (DWORD*)HeapAlloc(GetProcessHeap(),0,sizeof(DWORD)*argsize);
+argspos = 0;
+for (i=0;icActuals;i++) {
+ int arglen;
+VARIANT *arg = prgpvarg[i];
+
+ arglen = _argsize(prgvt[i]);
+ if (V_VT(arg) == prgvt[i]) {
+ memcpy(args[argspos],V_UNION(arg,lVal), arglen*sizeof(DWORD));
+ } else {
+ if (prgvt[i] == VT_VARIANT) {
+ memcpy(args[argspos],arg, arglen*sizeof(DWORD));
+ } else {
+ ERR(Set arg %d to disparg type %d vs %d\n,i,
+ V_VT(arg),prgvt[i]
+ );
+ }
+ }
+ argspos += arglen;
+}
+
+FIXME(Do not know how to handle pvargResult %p. Expect crash ...\n,pvargResult);
+
+hres = _invoke((*(DWORD***)pvInstance)[oVft/4],cc,argsize/4,args);
+HeapFree(GetProcessHeap(),0,args);
+return hres;
+}
+
static HRESULT WINAPI ITypeInfo_fnInvoke(
ITypeInfo2 *iface,
VOID *pIUnk,
Index: dlls/oleaut32/oleaut32.spec
===
RCS file: /home/wine/wine/dlls/oleaut32/oleaut32.spec,v
retrieving revision 1.42
diff -u -u -r1.42 oleaut32.spec
--- dlls/oleaut32/oleaut32.spec 8 Jul 2002 19:36:24 - 1.42
+++ dlls/oleaut32/oleaut32.spec 6 Nov 2002 19:05:47 -
-142,7 +142,7
142 stdcall VarAnd(ptr ptr ptr) VarAnd
143 stub VarDiv # stdcall (ptr ptr ptr)
144 stub OACreateTypeLib2
-146 stub DispCallFunc
+146 stdcall DispCallFunc(ptr long long long long ptr ptr ptr) DispCallFunc
147 stdcall VariantChangeTypeEx(ptr ptr long long long) VariantChangeTypeEx
148 stdcall SafeArrayPtrOfIndex(ptr ptr ptr) SafeArrayPtrOfIndex
149 stdcall SysStringByteLen(ptr) SysStringByteLen
Re: A problem with comctl32
On Sat, Nov 02, 2002 at 03:56:11PM -0500, DanteAliegri wrote: Hey, I've come across what appears to be a simple problem in comctl32. When running icq99b, wine was dying in imagelist.c while trying to dereference a null pointer. Upon looking at the file, there was code for returning FALSE if that pointer was null, thus I felt it being null may be a valid choice. I made the attached change, and the problem was fixed. Comments? Index: imagelist.c === RCS file: /home/wine/wine/dlls/comctl32/imagelist.c,v retrieving revision 1.65 diff -u -r1.65 imagelist.c --- imagelist.c 23 Oct 2002 22:19:11 - 1.65 +++ imagelist.c 2 Nov 2002 20:40:53 - -1082,11 +1082,14 HBITMAP hImageBmp, hOldImageBmp, hOldImageListBmp, hOldMaskListBmp, hBlendMaskBmp; BOOL bIsTransparent, bBlend, bResult = FALSE; const HIMAGELIST himl = pimldp-himl; -const INT lx = himl-cx * pimldp-i + pimldp-xBitmap; -const INT ly = pimldp-yBitmap; +static INT lx; +static INT ly; Do not use 'static' here, just INT. Ciao, Marcus
Re: A problem with comctl32
-const INT lx = himl-cx * pimldp-i + pimldp-xBitmap; -const INT ly = pimldp-yBitmap; +static INT lx; +static INT ly; Should this be really static? Can't this function be called reentrant? well, static is no worse than const ;) It is. Your program is no longer threadsafe. Ciao, Marcus
Re: PATCH: ppc fix 2
On Wed, Oct 30, 2002 at 10:13:36AM -0600, Greg Turner wrote: On Wednesday 30 October 2002 07:22 am, Marcus Meissner wrote: Fixed LITTLE_ENDIAN_32_READ macro to at least compile. btw, this seems to imply that even with the parentheses fix, it's still not right... is that the case? You seem like somebody who's up on PPC issues. Note that this is only intended to support UINT32's (I'll make that clearer by changing the macro names in an upcoming patch). The macro appears ok: (*(pchar) = LOBYTE(LOWORD(uint32)), \ *((pchar)+1) = HIBYTE(LOWORD(uint32)), \ *((pchar)+2) = LOBYTE(HIWORD(uint32)), \ *((pchar)+3) = HIBYTE(HIWORD(uint32)), \ It is not byteorder dependend. ... Anyhow, just thinking aloud there, and, I guess, hoping that if I'm getting this all wrong, someone will correct me. My original question is the main one: are the semantics of my macro's wrong, or just the parentheses thing? Huh? Just the parentheses thing was wrong I think. Ciao, Marcus
Re: WINE for PowerPC?
On Sat, Nov 02, 2002 at 05:37:13PM -0600, Adam Ernst wrote: I'm sorry if this is off topic or doesn't belong here. I'm not a developer (at least not in C) so I'll wait a few years while I learn C before I come back and help you guys. But I was wondering... What are the technical issues with putting WINE on the PowerPC? Native PowerPC (using WINELIB) works. For the other issues see the other mails. Ciao, Marcus
Re: Wine securityflaw.
On Thu, Oct 31, 2002 at 11:10:33AM -0300, Raul Dias wrote: My $0.02, I always though of a wine as way to run windows apps better than windows. Better also means more secure for me. A way to make it more secure is to catch key API calls and decide if the application is allowed to run it or not. This would be easy to detect if an application is trying to delete a file, to open a network connection, or anything that could be possible unsafe if not used correct. ... The whole issue can probably addressed by very simple sandboxing: Just use a WINE pseudo user. Then WINE and the windows applications can do only damage within the pseudo user context, which should be harmless. Automated cleanup (like cron based kills or similar) would be easy. Drawback: Does not scale well to a multi user system. Ciao, Marcus
Re: So lets say we do it
On Thu, Oct 31, 2002 at 08:24:28AM -0800, Alexandre Julliard wrote: Dimitrie O. Paun [EMAIL PROTECTED] writes: So the 5% left, install wine, install a Win-app, and play around. Great, it works! You forgot a few things here: As for the SuSE wine RPMS: First it doesn't even start because they don't have a config file. OK, they copy one from somewhere, it doesn't work because the drives are wrong. Been there, done that. Not very good, it is still using winesetuptk which might be too much in way of configuration. Then they don't have the proper registry (winedefault.reg? what's that?) Merged automatically with startup script. Then they finally manage to run the installer but it puts stuff in RunOnce that never gets run so the app doesn't work. Ok, this one is still missing. Then they finally make the app run but can't print anything. Two edged sword. CUPS works fine here, however if all applications are ready to print with WINEPS and winspool.drv is another issue. And when they ask for help they get told to fight the FAQ-O-Matic crap to maybe finally find an answer telling them they are an idiot. Yep. But this one is harder, what do you think needs to be there? So no, I'm not going to make a general public release just yet... Not yet too late for another 'Halloween' release though ;) Ciao, Marcus
Re: PATCH: ppc fix 2
On Wed, Oct 30, 2002 at 07:56:10AM -0600, Greg Turner wrote: On Wednesday 30 October 2002 07:22 am, Marcus Meissner wrote: Hi, Just a bad macro. ciao, marcus Changelog: Fixed LITTLE_ENDIAN_32_READ macro to at least compile. Index: ndr_marshall.c === RCS file: /home/wine/wine/dlls/rpcrt4/ndr_marshall.c,v retrieving revision 1.9 diff -u -r1.9 ndr_marshall.c --- ndr_marshall.c 29 Oct 2002 23:07:33 - 1.9 +++ ndr_marshall.c 30 Oct 2002 13:21:15 - -59,8 +59,8 #define LITTLE_ENDIAN_32_READ(pchar) \ (MAKELONG( \ - MAKEWORD(*(pchar), *((pchar)+1)) \ - MAKEWORD(*((pchar)+2), *((pchar)+3))) + MAKEWORD(*(pchar), *((pchar)+1)), \ + MAKEWORD(*((pchar)+2), *((pchar)+3 #endif /* oops! thanks! strange that this compiles for i386 at all. maybe gcc is automagically fixing the macro for some of us? No, if you look at the define, it is not processed on i386 (protected by ifdef). Ciao, Marcus
