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: & should be the escape for & 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
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: 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
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: 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-commit&id=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 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: PATCH: dlls/commdlg/printdlg.c add casts
> > No, L"x" 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: L"Success\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 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, L"x" 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: 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 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: 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: 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
+
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 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: 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-dbg>bt
> 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: 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 happy > 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: Wine dependancies
On Mon, Mar 03, 2003 at 05:08:58PM +, Mike Hearn wrote: > Just as a quick continuation from Dans mail, I thought I'd find out what > libs Wine actually required, at least on my build. > > Running: > > ( for f in *.so; do ldd $f | sed 's/ =>.*//'; done ) | sort | uniq > > in the $prefix/lib/wine/ directory produced the following list: > > The inclusion of libgcc_s and libstdc++ is from the Direct3D code I > think, I didn't realise there were deps on the c++ libs. > Otherwise, it's a remarkably short list. I think maybe quite a few of > the libs are detected at runtime, I know there was a patch to make You missed libXrender.so, libfreetype.so, libjack.so, libcups.so, (libcrypto.so, libssl.so), which are loaded dynamically :) libfreetype.so is also pulling the C++ libraries. > instance, there is no dependancy on libjack. The other libs are fairly > standard and would be present on almost all installations. A few, like > the C++ libs and ncurses aren't a part of the LSB and at present would > need to be statically linked. I think the C++ libraries are going to be in LSB. Also we currently access glibc lowlevel code, which does not help in portability. 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: 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: 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: 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: 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: 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
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
> 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 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: 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: infinite loop in msvcrt dll
On Sun, Feb 02, 2003 at 09:27:23PM +0100, Michael Stefaniuc wrote: > 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 I think our Unimplemented exception just gets confused with msvcrt exception handling. Not a large problem. 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: 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: 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
> world.
>
> 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
...
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 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: 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 => L"Misc 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=L"AdvMICR" > 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: 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: 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: 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: 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 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: 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: 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 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: * 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 L"C:\\PROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIFIM > P32.FLT" (last=0) > trace:dosfs:DOSFS_FindUnixName /dos,L"PROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIF > IMP32.FLT" > trace:dosfs:DOSFS_ToDosFCBFormat (L"PROGRA~1\\COMMON~1\\MICROS~1\\GRPHFLT\\GIFIM > P32.FLT", df621770) > trace:dosfs:DOSFS_OpenDir "/dos" > ... > trace:dosfs:DOSFS_ReadDir Read: long_name: L"Program Files", short_name: (null) > trace:dosfs:DOSFS_FindUnixName checking L"PROGRA~1 " L"PROG~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: 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: 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: 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: 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: 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: ole:_copy_arg TKIND_INTERFACE unhandled
On Tue, Jan 07, 2003 at 10:54:34AM +0100, Uwe Bonnes wrote: > Hallo, > > it seems that the Altera Quartus installation of > quartusii_22_web_edition.exe using IKernel doesn't work because of an > unhandled interface: > trace:ole:ITypeInfo_fnGetRefTypeInfo (0x4428f470) hreftype 0x0001 loaded SUCCESS >(0x4428bda0) > trace:ole:ITypeInfo_fnGetTypeAttr (0x4428bda0) > fixme:ole:_copy_arg TKIND_INTERFACE unhandled. > trace:ole:ITypeInfo_fnRelease (0x4428f470)->(1) > trace:ole:VariantCopy (0x4443c020, 0x4443df18), vt=9 > trace:ole:VariantClear (0x4443c020) > > the full --debugmsg +ole log is about 40 MByte and I can make it available > on request. The unhandled interface happens at about 84% of the log. > > The installation files from Altera (about 120 MByte) can be downloaded after > registration for free from > http://www.altera.com/products/software/pld/products/quartus2/sof-quarwebmain.html > > I would be please if tthe installation could be made working. I will have a look at it. 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: 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: 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: 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: 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: CorelDraw 4 almost working
On Sun, Jan 05, 2003 at 11:17:33AM -0500, Dimitrie O. Paun wrote: > On January 4, 2003 09:20 am, Claudiu Costin wrote: > > Is someone kind enough to implement them just as > > little stubs, just to not have CorelDraw crashed? > > This functions need aditional functionality to > > be implemented or these are "standalone"? > > Give this a try, and let me know if it helps: It won't... > -4 stub DLLGETCLASSOBJECT > +4 pascal DllGetClassObject(ptr ptr ptr) OLE32_DllGetClassObject No, the function should return a 16bit interface, not a 32bit one. > -49 stub OLESETCLIPBOARD > -50 stub OLEGETCLIPBOARD > +49 pascal OleSetClipboard(ptr) OleSetClipboard > +50 pascal OleGetClipboard(ptr) OleGetClipboard These are getting passed pointers to 32bit interfaces, but need 16bit ones. 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:\winetests>oleaut32_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: 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" > (HREF="http://developer.apple.com/techpubs/macosx/Kernel/KernelEnvironment.pdf";>http://developer.apple.com/techpubs/macosx/Kernel/KernelEnvironment.pdf) > 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: 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:\winetests>oleaut32_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: 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: Modifying registers
On Wed, Nov 27, 2002 at 03:26:22PM +0100, Fabian Cenedese wrote: > Hi > > Is there already a possibility to view/set the actual program counter in > winedbg? I couldn't find anything in the manual. And it's not possible to > work with EIP. This would be useful e.g. to jump over some unwanted code > or call a function a second time. > Generally, is there a way to modify registers? Must be obvious but I'm blind. set $eip = 0x42424242 Dito for the other registers. 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: RFC: console & curses
On Tue, Nov 19, 2002 at 09:38:02PM +0100, Eric Pouech wrote: > I did send a couple of days ago a first patch about the (n)curses > backend to wineconsole > Alexandre commented a few implementation issues in it, which may change > a bit what I started with and how the wineconsole should behave: > > console creation can be invoked from different contexts: > 1/ the program calls AllocConsole > 2/ the user starts wine thru wineconsole for his/her (favorite) CUI app > (using from command line something like 'wineconsole foo') > 3/ (N1) the program forks a child with CREATE_NEW_CONSOLE flags set in > CreateProcess > 4/ the program doesn't request anything > > on the other hand, wineconsole is now able to handle two types of > backend for the user interface: > A/ USER: the one already in place > B/ Curses: the new one using (n)curses and a regular term for display > (N2) > C/ no wineconsole support => by default, the windows input & output > streams are hooked to stdin and stdout, but we don't provide full > console support - cursor motion, screen reading... > > now the final question, how to choose between A, B and C. the proposal > is to fix the choice with: > 1 => A > 2 => B > 3 => A > 4 => C > > 2 => B we could easily add 2 => A too (with some wineconsole > parameters). Moreover, if the user wants to have the console in a > specific xterm, it's doable with xterm -e 'wineconsole blablabla' Hmm, what is wrong with A for all the first 3 cases? Even the IDA Disassembler now likes the USER based console. Otherwise ok. 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 Fri, Nov 15, 2002 at 09:53:33AM +0100, Lionel Ulmer wrote: > > > 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. > > Well, in the other case, the thunked interface will also have a performance > trade-off as it will introduce extra pointer arithmetic and function calls > on each COM call. Of course, the 'dominant' one will not have any > performance penalty at all. > > > As for increased function sharing and reduced thunks usage... > > True, but the number of functions is not really annoying or problematic. > > Well, in some cases like in D3DDevice where you have 34 methods that are > shared between different interfaces, it starts to get a little bit annoying > to write 34 thunks :-) > > In any case, for the moment I rewrote most of the COM part for the Direct3D > code using Christian's patch (as it made my life much easier :-) ). Now, if > it won't go into the tree, I could add thunking to it (should not be that > hard). Just take a decision soon so as to not have a 11 klines patch lying > in my tree for too long... If this makes your work easier I would just say go for it. 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: 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: 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: 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: 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: [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: 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;i@ -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: 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
