Folks,
Just as I thought 'fine, I'll add the #ifdef, and get it over with', this
thing comes back to haunt me. For the record, I've delete the previous
thread, _and_ the io.h patch from my tree, thinking the issue was put to
rest.
As you can probably guess, I have the io.h problems in wxWindows,
Hi Shachar,
At 23.59 08/01/2003 +0200, Shachar Shemesh wrote:
Hi,
I'll clarify my specific predicament.
It seems that when MoveFileEx is called with MOVEFILE_DELAY_UNTIL_REBOOT
flag, an entry is written into the registry with the file names to rename.
Windows being what it is, a MULTI_SZ
Quoting Alexandre Julliard [EMAIL PROTECTED]:
That's much better than the previous one. I'm not convinced you really
need to build a static list, you might as well have a function to
register a single interface and call it a number of times.
The main reason I used a static list was to make it
On Wednesday 08 January 2003 22:27, Dimitrie O. Paun wrote:
On January 8, 2003 02:11 pm, Hetz Ben Hamo wrote:
Whats the difference? now you don't need QT, so license wise - it's
kosher ;)
But I guess it's still C++, no? I'm not sure if Alexandre will accept
C++ dlls...
Well, last time the
On January 9, 2003 10:44 am, Hetz Ben Hamo wrote:
As for C++ - well, anyone is welcome to look at mozilla code - I'm affraid
that it looks like a big spaghetti, compared to (pretty neat) KHTML code ;)
I'm not saying it's an unreasonable request. All I'm saying is that it would
be a change in
Dimitrie O. Paun [EMAIL PROTECTED] writes:
I'm not saying it's an unreasonable request. All I'm saying is that it would
be a change in policy to accept C++ code in Wine. So you need to take it up
with Alexandre :)
I'd prefer to avoid C++, but if there's no other choice then of course
we'll
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
Dimitrie O. Paun wrote:
#if !defined(__UNIX__) || defined(USE_MSVCRT)
#include io.h
#endif
But this is not all! For example, wxWindows includes stuff like this:
#include sys/unistd.h
#include sys/stat.h
Since they are available in mingw, and cygwin, and in UNIX, but if
I want to use msvcrt they
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
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
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Collapse -w16 into -O as res16.
-w16 can apply to all modes, not only .res, so you would need to
support 'asm16' and 'hdr16' too. It seems cleaner to keep it as a
separate option.
--
Alexandre Julliard
[EMAIL PROTECTED]
On 8 Jan 2003, Dan Kegel [EMAIL PROTECTED] wrote:
I think the issue was that I did not have three identical machines;
the speedup from distributing to three hosts was minimal compared
to just building on the fast machine.
I think the scheduler doesn't handle the case of heterogenous machines
Ooops
Ok, I'll do a make clean next time
Sorry.
On Wed, 8 Jan 2003, Dimitrie O. Paun wrote:
On January 8, 2003 09:18 am, Thai Dang wrote:
if you have troubles during installation (especially with registry
installation failed)
patch -p1 -l patchwine-20021219.diff
Thai,
You've
Dimitrie O. Paun wrote:
On January 8, 2003 02:33 am, Jeroen Janssen wrote:
The attached patch fixes the following problem:
'_wine_ldt_copy' can't be auto-imported when building under cygwin
Jeroen,
Can you please test if the attach patch work?
No, it doesn't work (there was an
Comment about
http://www.winehq.com/hypermail/wine-devel/2003/01/0390.html
| I don't see why it can't be there if we do something like
|
| #ifdef HAVE_SNAZZY_COMPILER
| #define RpcTryExcept __try
| ...
| #else
| #define RpcTryExcept if (1)
| ...
| #endif
|
| People compiling Windows apps under
Dimitrie O. Paun [EMAIL PROTECTED] writes:
So, let's say I do:
#ifndef __UNIX__
#include io.h
#endif
Well, this will not work if I want to compile with msvcrt, because
__UNIX__ will be defined anyway. So what do I have to test for?
I think it would work. What you have to do is something
On 8 Jan 2003, Paul Millar [EMAIL PROTECTED] wrote:
Hi Martin,
On a similar note, I've been investigating OpenMOSIX on and off (mostly
off) for doing distributed compiling. In general, I've found it not
particularly stable (although its improving) and the performance not
particularly
Martin Pool wrote:
On 8 Jan 2003, Dan Kegel [EMAIL PROTECTED] wrote:
I think the issue was that I did not have three identical machines;
the speedup from distributing to three hosts was minimal compared
to just building on the fast machine.
I think the scheduler doesn't handle the case of
On Thu, 9 Jan 2003, Kari Hurtta wrote:
Sendmail 8.12 uses also exception mecanism.
On it's implementation 'try' uses setjmp()
( Look macros include/sm/exc.h -- you can not of course copy these
but that should tell enough that it is doable just plain C )
Sure a try/except mechanism is
Hi John,
John Westerman wrote:
Hi Everybody,
I'm currently trying to compile the basic Win32 Hello world project
that VC6 generates for you using Wine.
My problem is that when I run ./configure -with-wine=/usr/local/wine
It fails with the Message checking for afx.h Could not find the
What would it take to make a static library work for this? Unlike a dll,
that would not have any overhead, would it? I'm a real sucker for
elegance,
you know. :-)
It's possible, but it adds quite a bit of complexity to the build
process, and creates annoying dll dependencies. I'd
On Thu, 9 Jan 2003, John K. Hohm wrote:
[...]
Okay, we'll start with the duplication. :-|
When I prepare a patch including the shared regsvr.h and regsvr.c, should I
include them everywhere they're needed (repeating them in the patch multiple
times), or just add a note like Hey Alexandre, do
John K. Hohm [EMAIL PROTECTED] writes:
When I prepare a patch including the shared regsvr.h and regsvr.c, should I
include them everywhere they're needed (repeating them in the patch multiple
times), or just add a note like Hey Alexandre, do a cp regsvr.[hc] ..., or
maybe should I always
On January 9, 2003 03:09 pm, Rok Mandeljc wrote:
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN
Can you, pretty please, turn off HTML mail? shrug/
--
Dimi.
On January 9, 2003 02:23 pm, Alexandre Julliard wrote:
-w16 can apply to all modes, not only .res, so you would need to
support 'asm16' and 'hdr16' too. It seems cleaner to keep it as a
separate option.
Yes, I know, but we officially don't support Win16. We only need 16-bit
support in a
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Yes, I know, but we officially don't support Win16. We only need 16-bit
support in a handful of places within wine, and there we use only .res.
Again, wrc can be useful for more than simply building Wine. Sure,
that feature is not going to be used
On January 9, 2003 12:12 pm, Alexandre Julliard wrote:
I think it would work. What you have to do is something like:
#ifndef __UNIX__
#include io.h
#else
#include unistd.h
#endif
This so fast! :)
Remember, __UNIX__ is always defined when compiling in Wine, so
we can never include io.h.
LarstiQ wrote:
On Sun, Jan 05, 2003 at 07:18:05PM -0800, Dan Kegel wrote:
snip
I guess I'm aiming at making it easier for Windows folks to
grab the source for the tests from CVS and build them themselves
under Windows.
Furthermore, I'm hoping to write scripts to continuously update
from cvs
On January 9, 2003 04:14 pm, Alexandre Julliard wrote:
But it's here, it works, and it can potentially be useful to
someone someday; there's nothing to gain by removing it.
I really wonder how it can be of use to anyone. There is stuff
to gain: simplicity, less code to maintain and support.
On Wed, Jan 08, 2003 at 09:34:50PM +0100, Jürgen Schmied wrote:
Content-Description: Mail message body
- fixed crash in winamp reported by andreas mohr
Yay !!! That fixed it indeed !
(in other words: I just didn't trust you, so I had to try myself ;-)
Andreas Mohr
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
Francois Gouget wrote:
Hi John,
John Westerman wrote:
Hi Everybody,
I'm currently trying to compile the basic Win32 Hello world project
that VC6 generates for you using Wine.
My problem is that when I run ./configure -with-wine=/usr/local/wine
It fails with the Message checking for afx.h
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Remember, __UNIX__ is always defined when compiling in Wine, so
we can never include io.h. Which begs the question: why do we have
it in msvcrt in the first place? :)
Because not all apps are cygwin apps, and pure Windows apps are of
course not going
On January 9, 2003 12:54 pm, Alexandre Julliard wrote:
You can do that just fine with my solution, all we need is a trivial
unistd.h in the msvcrt headers. Plus this way you also have a chance
to build the app under normal Unix, where you will never have io.h.
OK, cool. What about this patch?
Quoting Alexandre Julliard [EMAIL PROTECTED]:
Please do it in one dll only for now and submit that; once it's tested
and integrated we can start copying it around. Also I'd suggest
Okay. Should I perhaps start with something better-used than comcat (perhaps
ole32) so that testing will be
John K. Hohm [EMAIL PROTECTED] writes:
Are you suggesting that the static data defining which classes and
interfaces to register be located in the same file as the implementation of
the (un)registration functions? That would make copying the implementation
around even more work, since I
On Thu, 9 Jan 2003, Dimitrie O. Paun wrote:
[...]
Remember, __UNIX__ is always defined when compiling in Wine, so
we can never include io.h. Which begs the question: why do we have
it in msvcrt in the first place? :)
Because it's part of the Visual C++ headers for the msvcrt library.
Visual
Dimitrie O. Paun [EMAIL PROTECTED] writes:
On my system (RH 8.0), /usr/include/sys/unistd.h simply does
#include unistd.h
so it works perfectly with this addition. But is this standard?
Should we just add a similar file to include/msvcrt/sys and be
done with it?
Yes, that's probably
Paul Millar wrote:
I'm in the process of extending WRT [1] to include running the conformance
tests on as many Windows platforms as I can get my hands on (which, in
theory should be more-or-less all of them).
I didn't want to say anything until I knew it was feasible, but I've got
most of it
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,
On Thu, 9 Jan 2003, LarstiQ wrote:
On Sun, Jan 05, 2003 at 07:18:05PM -0800, Dan Kegel wrote:
grab the source for the tests from CVS and build them themselves
under Windows.
Furthermore, I'm hoping to write scripts to continuously update
from cvs and run the regression tests, all on
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...
no problem any more with this code when I updated my CVS (aged from
Tuesday morning :) )
black magic ;)
--- Lionel Ulmer [EMAIL PROTECTED] a écrit :
trace:ddraw:Main_DirectDrawSurface_GetAttachedSurface
(0x402a9418)-Looking for caps: 4,0,1,1 output: 0x741ed0
Caps are :
Francois Gouget wrote:
[...]
2. if we tweak things so that the CreateThread is done, then the
resampling will be done by Alsa (or whichever back-end) which will
presumably do it much better than us. howeve rin that case we have to
make the almost never used case work and I'm not sure how well
On January 9, 2003 02:26 pm, Francois Gouget wrote:
Which begs the question: why do we have
it in msvcrt in the first place? :)
Because it's part of the Visual C++ headers for the msvcrt library.
I was just _kidding_ :) Notice the smiley ...
--
Dimi.
Folks,
We have a lot of code in msvcrt headers like so:
#define umask _umask
#define unlink _unlink
#define write _write
This breaks C++ that define a write method in a header,
and then implement it like so:
#include io.h
void MyClass::write(...) { write(...); }
I suggest we turn those
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,
Dont know if this is right or not as you all know I think configure is a little whore.
=P
Maybe this should go somewhere else. I have about 12 or 13 other things that need to
be fixed when
building WINE for Mingw and MSYS and I am tired of doing ./configure
CFLAGS=-D__MINGW__
-D_WINDOWS
On January 10, 2003 12:01 am, Steven Edwards wrote:
+CFLAGS==$CFLAGS -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK ;
Why do you need these defines? In particular, isn't the compiler
defining __MINGW__ and _WINDOWS?
--
Dimi.
--- Dimitrie O. Paun [EMAIL PROTECTED] wrote:
On January 10, 2003 12:01 am, Steven Edwards wrote:
+CFLAGS==$CFLAGS -D__MINGW__ -D_WINDOWS -DWINE_NOWINSOCK ;
Why do you need these defines? In particular, isn't the compiler
defining __MINGW__ and _WINDOWS?
I started using them a while
Dimitrie O. Paun wrote:
Compiling under the SDK using MS tools gives us little value. We already
know that works. If you don't want to spend the cash on MSVC (and not make
MS any richer :)), and are willing to invest some time into it, I suggest
the following path:
1. Get the latest mingw 2.0
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
Dimitrie O. Paun wrote:
I suggest we turn those defines into inlines, like this:
inline int write(int fd, const void* ptr, unsigned int size) { return _write(fd, ptr, size); }
Any other solutions?
Sure, there are two:
0. use a linker alias for _write
1. actually have a function write() that
On January 10, 2003 02:12 am, John Westerman wrote:
My hellotest.spec looks like this:
name hellotest
type win32
mode guiexe
init WinMain
rsrc hellotest.res
import kernel32.lib
import user32.lib - line of failure
None of this stuff resides in the .spec file anymore!
I'm not
On Thu, 9 Jan 2003, Dimitrie O. Paun wrote:
Folks,
We have a lot of code in msvcrt headers like so:
#define umask _umask
#define unlink _unlink
#define write _write
[...]
I suggest we turn those defines into inlines, like this:
inline int write(int fd, const void* ptr, unsigned int
Hi Everybody,
I'm currently trying to compile the basic Win32
"Hello world" project that VC6 generates for you using Wine.
Currently I'm running winemaker like this:
winemaker --nomfc -I/usr/local/wine/include
-L/usr/local/wine/lib
-ikernel32.lib
-iuser32.lib
-igdi32.lib
Francois Gouget [EMAIL PROTECTED] writes:
The strange thing is that the MSVC headers simply define their
prototype, e.g.:
_CRTIMP int __cdecl umask(int);
Yet these APIs are not exported by the msvcrt library or by any other
dll that I know of. And still applications compile and link!
I
Glen Kaukola wrote:
Well I've gotten MinGW and sorta learned my way around it. But now, my
problem is that neither of my windows programming books has makefiles of
any sort. All they have is C++ code. So maybe I should go with my
original plan of compiling stuff with visual studio and seeing
On January 9, 2003 08:38 pm, Alexandre Julliard wrote:
I think you have to link with oldnames.lib for that. We probably have
to provide an oldnames.lib too.
OK, but what do we do now about those defines?
--
Dimi.
On January 10, 2003 01:14 am, Glen Kaukola wrote:
All they have is C++ code. So maybe I should go with my
original plan of compiling stuff with visual studio and seeing if it
runs under wine. Or do you have any other suggestions?
Compiling stuff with visual studio is a first step. But it
On Sun, Jan 05, 2003 at 07:18:05PM -0800, Dan Kegel wrote:
snip
I guess I'm aiming at making it easier for Windows folks to
grab the source for the tests from CVS and build them themselves
under Windows.
Furthermore, I'm hoping to write scripts to continuously update
from cvs and run the
61 matches
Mail list logo