Dan Kegel wrote:
Q1. What do I have to do to get Wine's builtin rich text DLL to work there?
I tried wine --dll riched32=b, but that didn't help.
there are several version of the richedit DLLs.
riched32 should be version 1.0. what your app requires seems to be
version 2.0 of this DLL.
as of
Folks,
Why do we need to define _FORCENAMELESSUNION to get nameless unions
in oleauto.h? Is this a standard feature, or is it just another Wine
extension? Can someone please check the Windows headers to see how
struct tagVARIANT is defined? Our is as follows:
struct tagVARIANT
{
union
{
Ok, I was under the impression that we want something in so that we can
start working on it.
As this is the way you feel about the current wineboot, I think I'll go
a completely new route. Please let me know your thoughts about the new
proposed process.
In windows, some of the boot operations
Dimitrie O. Paun [EMAIL PROTECTED] wrote:
Here is another problem: we are currently defining the __WINE__ symbol
to signal the headers that we are compiling Wine. This is fine. The
problem that I'm facing is that there are apps (such as wxWindows) that
want to know that they are _compiled_
On Sun, 22 Dec 2002, Dimitrie O. Paun wrote:
Folks,
Why do we need to define _FORCENAMELESSUNION to get nameless unions
in oleauto.h? Is this a standard feature, or is it just another Wine
extension?
It's a standard MS feature, and Wine defines VARIANT exactly like Windows.
Perhaps the
On Sun, 22 Dec 2002, Dimitrie O. Paun wrote:
Folks,
Why do we need to define _FORCENAMELESSUNION to get nameless unions
in oleauto.h? Is this a standard feature, or is it just another Wine
extension? Can someone please check the Windows headers to see how
struct tagVARIANT is defined? Our
On Sun, 22 Dec 2002, Francois Gouget wrote:
On Sun, 22 Dec 2002, Dimitrie O. Paun wrote:
Folks,
Why do we need to define _FORCENAMELESSUNION to get nameless unions
in oleauto.h? Is this a standard feature, or is it just another Wine
extension? Can someone please check the Windows
On Sun, 22 Dec 2002 05:42, Alexandre Julliard wrote:
Robert Lunnon [EMAIL PROTECTED] writes:
I need to introduce a compile time conditional to better facilitate
Solaris, in particular the macro ADDRESS_SPACE_LIMIT in virtual.c.
I understand HAVE_SOLARIS is frowned upon so can anyone
On Sat, 21 Dec 2002, Lionel Ulmer wrote:
On Sat, Dec 21, 2002 at 05:49:23PM +0100, Eric Pouech wrote:
So I was wondering how to debug this ? I tried to attach 'gdb' to it (and it
works) but how do I know which symbols to load (winedbg being a script, wine
having no code except linking
Right, can now ignore my original post, and comment on the following.
Ok, I've sort of found a template for the X11_drv wintab seperation:
The tablate is the direct X drirect draw, and open GL dlls.
These dlls do the following:
X11_drv thread synchronisation
Grab the X device the GDI
On December 22, 2002 04:44 am, Dmitry Timoshkov wrote:
Compiling under Wine should not IMO require defining additional symbols
except probably __WIN32__.
It shouldn't. In theory. But the difference between practice and theory
is that while in theory practice and theory are the same, in practice
On December 22, 2002 06:03 am, Ove Kaaven wrote:
Perhaps you could investigate the mingw headers to see
if they've changed the #ifs around to get around this.
This is how they do it:
#ifdef NONAMELESSUNION
#define __VARIANT_NAME_1 n1
#define __VARIANT_NAME_2 n2
#define __VARIANT_NAME_3 n3
Hallo,
for me it looks as if the same fix as to files/drive.c with regard to the
usage of strtolW versus strtoulW should be applied to
dlls/setupapi/install.c too.
Bye
--
Uwe Bonnes[EMAIL PROTECTED]
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
-
Dimitrie O. Paun wrote:
It shouldn't. In theory. But the difference between practice and theory
is that while in theory practice and theory are the same, in practice
they are different ((c) Larry McVoy) :).
That works great in practice, but it will never fly in theory (anonymous).
Shouldnt it? Breaks the compilation of the vstserver.
Please apply. :)
--
On Sun, 22 Dec 2002, Dimitrie O. Paun wrote:
On December 22, 2002 06:03 am, Ove Kaaven wrote:
Perhaps you could investigate the mingw headers to see
if they've changed the #ifs around to get around this.
This is how they do it:
#ifdef NONAMELESSUNION
#define __VARIANT_NAME_1 n1
#define
Duane Clark wrote:
I am trying to track down a crash when exiting an application. Here is
what I think are relevant parts of the trace. Does it appear that I am
in the right area? Any hints on how to proceed would be appreciated.
I think the problem comes down to this. The application
On Sun, 22 Dec 2002, Dimitrie O. Paun wrote:
[...]
So, my proposal is: let's rename the __WINE__ symbol (as it's
currently used) to something else (__WINESRC__, or whatever,
suggestions welcome), once that's done, define __WINE__ when
__WINESRC__ is not defined (the symbols would be mutually
Duane Clark wrote:
...
At the end of ImageList_Destroy, there is a call to ZeroMemory, which
obliterates the prev and next pointers which had been written there.
Then another COMCTL32_Free call detects the error. At least I assume it
is an error.
And indeed simply commenting out the
On Sun, 22 Dec 2002, Shachar Shemesh wrote:
[...]
What I'm thinking is incorporating the first group into the wine code
itself (I'm thinking the server startup, synchroniously done). For the
second group, create a wineboot program, and have a single option saying
whether the wineserver should
Kjetil S. Matheussen wrote:
Shouldnt it? Breaks the compilation of the vstserver.
Please apply. :)
Please refer to http://www.winehq.org/Docs/wine-devel/patches.shtml for
how to submit future patches.
Change Log: fix for compiling wstserver
Files: tools/winemaker
--
Tony Lambregts
Eric Pouech wrote:
so you're stuck with either using native riched20.dll, or doing lots of
hard work to implement version 1.0 and 2.0
Er, ok, I'll stick with native for now :-)
Q2. Any idea what I'd need to do to get a Windows Explorer going
without actually installing the real Windows
On December 22, 2002 02:22 pm, Francois Gouget wrote:
Maybe you should submit patches to wxWindows and/or MinGW. I think this
could only improve these projects to be more compatible with the Windows
headers...
Well, but of course, I just want to make sure I fix the right thing.
You see, I
Big progress. Turns out the best way to trace these installer splash screens is
wine --debugmsg +exec
since all they do is exec other programs.
The only problem with this button under Wine is that the current working
directory MUST be /mnt/cdrom before starting setup.exe
for the install button
Sylvain Petreolle wrote:
--- Tony Lambregts [EMAIL PROTECTED] a écrit : Jeff
Smith wrote:
What I have so far:
in files/dos_fs.c:1343, drive is receiving the value -1.
at line 1358, this is blindly added to 'A'. As you may
know, in ASCII, 'A' - 1 = '@'.
The problem is that we don't
On December 22, 2002 02:50 pm, Duane Clark wrote:
That area is then freed. When freed, COMCTL32_Free writes prev and next
entries into himl.
Where? COMCTL32_Free() simply calls HeapFree():
BOOL WINAPI COMCTL32_Free (LPVOID lpMem)
{
TRACE((%p)\n, lpMem);
return HeapFree (COMCTL32_hHeap,
With current CVS wine, doing a minimum install of MSVC4
works fine (once you jump through the proper hoops), but
at the very end, I get the dialog box
Setup cannot execute the DDE command 'ActivateProgMan'
Press Abort to to (sic) stop installing shortcuts and continue Setup.
I googled for
wine still needs some polish before it can install msvc4 nicely,
but it can indeed install it, and the installed copy of msdev
appears to work! I used the IDE to create a hello, world
console app, and it compiled and ran perfectly!
The UI seems snappy enough on my dual pentium 650, too.
I'm
28 matches
Mail list logo
