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.
--
Alexandre Julliard
[EMAIL PROTECTED]
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]
.
--
Alexandre Julliard
[EMAIL PROTECTED]
there will be less
duplication.
--
Alexandre Julliard
[EMAIL PROTECTED]
often, and we probably wouldn't
implement it today if it didn't exist. But it's here, it works, and it
can potentially be useful to someone someday; there's nothing to gain
by removing it.
--
Alexandre Julliard
[EMAIL PROTECTED]
to replicate them in our environment. We need to define a
portable solution that has a reasonable chance of working in all
cases, even including cases that don't exist today. If it requires
tweaking broken apps a bit that's acceptable.
--
Alexandre Julliard
[EMAIL PROTECTED]
the
common functions and the dll-specific stuff; then when you want to do
a new dll you copy a regsvr.c and modify the dll-specific parts. This
also allows simplifying the code for dlls that don't need the complete
support.
--
Alexandre Julliard
[EMAIL PROTECTED]
safer, and it shouldn't break anything.
--
Alexandre Julliard
[EMAIL PROTECTED]
think you have to link with oldnames.lib for that. We probably have
to provide an oldnames.lib too.
--
Alexandre Julliard
[EMAIL PROTECTED]
is to
provide a way to write code that works both on Wine and on the
original platform, so that once you have made it portable you don't
need further changes. In this case the solution is unistd.h.
--
Alexandre Julliard
[EMAIL PROTECTED]
not very elegant to duplicate
it, but it shouldn't be a lot of code anyway.
--
Alexandre Julliard
[EMAIL PROTECTED]
to be Unix compatible, and under Unix access() is in unistd.h. So if
the app needs access() it should include unistd.h; if it needs the
other functions from io.h then it has to use msvcrt because they don't
exist in the Unix libc.
--
Alexandre Julliard
[EMAIL PROTECTED]
. Simply setting the correct WINEDLLPATH should be enough
(and runtest should be doing that already AFAICS).
--
Alexandre Julliard
[EMAIL PROTECTED]
then use the NONAMELESS defines to write more
portable code, without having to duplicate the compiler checks. So the
user's code can do something like:
#include winnt.h
#ifdef NONAMELESSUNION
#define U(x) u.x
#else
#define U(x) x
#endif
--
Alexandre Julliard
[EMAIL PROTECTED]
.
What about all the other things I've mentioned? Should we do anything
about them? And if yes, what?
The extra flag values etc. should be removed, by fixing the code to
not depend on extending the API that way. Of course that's easier said
than done...
--
Alexandre Julliard
[EMAIL PROTECTED]
? ;-)
Yes we should fix it, our headers should have the exact same
dependency graph as the Windows ones.
--
Alexandre Julliard
[EMAIL PROTECTED]
of these the code probably needs to be redesigned to not
require API extensions. I don't know how, each one must be studied in
detail. And there are probably other places where we have added
Wine-specific flags without __WINESRC__ that will need to be fixed
too.
--
Alexandre Julliard
[EMAIL
there; and that
routine can then be called the first time mmap returns such an
address, so that it will work for all platforms that may have that
problem.
--
Alexandre Julliard
[EMAIL PROTECTED]
.
--
Alexandre Julliard
[EMAIL PROTECTED]
a sane API in the first place.
--
Alexandre Julliard
[EMAIL PROTECTED]
Dimitrie O. Paun [EMAIL PROTECTED] writes:
On January 1, 2003 07:40 pm, Alexandre Julliard wrote:
I think __WINE__ is best, let's just rename the internal one. BTW this
Cool, but to what? __WINESRC__? __WINEBUILD__? __WINEINTERNAL__?
It doesn't really matter, just pick the one you prefer
. It's
not 100% compatible, but it should still do the right thing, both with
and without msvcrt.
--
Alexandre Julliard
[EMAIL PROTECTED]
into that.
--
Alexandre Julliard
[EMAIL PROTECTED]
in fixing all the C files. It works
fine the way it is now, the only thing that we need the change is the
exported headers.
--
Alexandre Julliard
[EMAIL PROTECTED]
to deal with all this?
I don't think cygwin is really a big issue, it should be mostly Unix
compatible, and it shouldn't be hard to work around the problems if
any appear. I don't think we need any special infrastructure for that.
--
Alexandre Julliard
[EMAIL PROTECTED]
it...)
--
Alexandre Julliard
[EMAIL PROTECTED]
known structures.
--
Alexandre Julliard
[EMAIL PROTECTED]
things outside of its own prefix. If you
install Wine in a non-standard directory then you need to tell
autoconf about it with the -I option.
--
Alexandre Julliard
[EMAIL PROTECTED]
!
--
Alexandre Julliard
[EMAIL PROTECTED]
many of
these ifdefs in our headers, and many of them could be removed IMO.
--
Alexandre Julliard
[EMAIL PROTECTED]
...
--
Alexandre Julliard
[EMAIL PROTECTED]
time make any difference?
The behavior of SetWindowLong(GWL_HWNDPARENT) depends on the current
parent, so calling it a second time with the same arguments is not
necessarily a nop.
--
Alexandre Julliard
[EMAIL PROTECTED]
things and you shouldn't use the same option for both.
--
Alexandre Julliard
[EMAIL PROTECTED]
be fixed now. Thanks for the note.
--
Alexandre Julliard
[EMAIL PROTECTED]
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Yeah, that's why I said it's a hack. What about a new -F option?
Sure that would be fine.
--
Alexandre Julliard
[EMAIL PROTECTED]
ADDRESS_SPACE_LIMIT so that it's not used for normal allocations.
--
Alexandre Julliard
[EMAIL PROTECTED]
even when not needed will be a serious performance hit.
--
Alexandre Julliard
[EMAIL PROTECTED]
complex
and over-engineered. It has to be a simple application that doesn't
require user interaction or a dozen configuration parameters.
--
Alexandre Julliard
[EMAIL PROTECTED]
Reactos etc.
--
Alexandre Julliard
[EMAIL PROTECTED]
. Actually I have a patch
that does this, I'll merge it in.
--
Alexandre Julliard
[EMAIL PROTECTED]
Uwe Bonnes [EMAIL PROTECTED] writes:
Changelog:
relay32/relay386.c: check_relay_include
Treat whole dlls as advertised
IMO the current behavior is correct. If the documentation says
otherwise it needs to be fixed.
--
Alexandre Julliard
[EMAIL PROTECTED]
at
all; the error message is a bit misleading in that case. And if it
didn't happen before then it's clearly a regression.
--
Alexandre Julliard
[EMAIL PROTECTED]
?
We need to implement them, importing stubs no longer works (but of
course you can do a stub implementation instead ;-)
--
Alexandre Julliard
[EMAIL PROTECTED]
. This avoids
having to do hacks in crtdll that will need to be removed later
anyway.
--
Alexandre Julliard
[EMAIL PROTECTED]
just want to
build the tests only. See below for examples.
That's a feature, it ensures that the tests get run again if the dll
being tested has changed. If you can't build these dlls under mingw,
you can simply create empty files instead.
--
Alexandre Julliard
[EMAIL PROTECTED]
.
--
Alexandre Julliard
[EMAIL PROTECTED]
if it has to be launched manually at
first; we can worry about automating it later.
--
Alexandre Julliard
[EMAIL PROTECTED]
down a lot. makedep doesn't change often enough for this
to be a real problem; and a make clean will fix it anyway.
--
Alexandre Julliard
[EMAIL PROTECTED]
option.
--
Alexandre Julliard
[EMAIL PROTECTED]
a long time ago. The only difference now is that
makedep complains if it cannot find a include and says nothing for
a include, but otherwise they work just the same.
--
Alexandre Julliard
[EMAIL PROTECTED]
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Either way, we need to fix this somehow.
IMO our headers should be fixed, they shouldn't have the msvcrt
prefix.
--
Alexandre Julliard
[EMAIL PROTECTED]
Dimitrie O. Paun [EMAIL PROTECTED] writes:
In which case, shouldn't our includes use instead of ? Using
is not 100% correct, let alone non standard. I know, minor point, but... :)
I guess they should, yes.
--
Alexandre Julliard
[EMAIL PROTECTED]
.
--
Alexandre Julliard
[EMAIL PROTECTED]
outside
of msvcrt, but I certainly don't see any reason to not use excpt.h
along with the Unix headers.
--
Alexandre Julliard
[EMAIL PROTECTED]
the .def file directly and skip
the intermediate step of building a library object file.
Hope this helps...
--
Alexandre Julliard
[EMAIL PROTECTED]
for the time being.
--
Alexandre Julliard
[EMAIL PROTECTED]
in certain (broken) setups, so I think
it's safer to add it.
--
Alexandre Julliard
[EMAIL PROTECTED]
include path if they install Wine in a non-standard directory. This
shouldn't be a common case anyway.
--
Alexandre Julliard
[EMAIL PROTECTED]
, speed penalties, etc.).
Frankly, this ranks about as high on the priority list as the strcat
optimizations in makedep. Are there really no more real problems to
solve that we need to spend so much effort inventing new ones?
--
Alexandre Julliard
[EMAIL PROTECTED]
that the C preprocessor would handle non C code correctly.
--
Alexandre Julliard
[EMAIL PROTECTED]
windres. We don't use all the features in the
Wine building process but that's not a reason for removing them.
--
Alexandre Julliard
[EMAIL PROTECTED]
Dimitrie O. Paun [EMAIL PROTECTED] writes:
I know that wrc does more than windres. I was just asking if some of
these options are superfluous. In particular, do we need to support
win16 resources?
Yes we do, some of our 16-bit dlls have resources.
--
Alexandre Julliard
[EMAIL PROTECTED]
committed that stuff yet...
--
Alexandre Julliard
[EMAIL PROTECTED]
machines, etc.
--
Alexandre Julliard
[EMAIL PROTECTED]
the
macros they have to be put inside one of the standard headers, which
wouldn't be very clean.
--
Alexandre Julliard
[EMAIL PROTECTED]
.
--
Alexandre Julliard
[EMAIL PROTECTED]
, so it would be possible to identify them. But
actually I could hack winebuild to do that itself, and then simply get
rid of the -r option.
--
Alexandre Julliard
[EMAIL PROTECTED]
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Thanks! Alexandre, shouldn't we install these as well?
Yes, the DDK ones should be installed I think. toolhelp.h probably
not, it's a 16-bit thing that Winelib apps are not supposed to use.
--
Alexandre Julliard
[EMAIL PROTECTED]
on that.
--
Alexandre Julliard
[EMAIL PROTECTED]
can find a way to merge everything into winebuild
cleanly.
--
Alexandre Julliard
[EMAIL PROTECTED]
depend on config.h.
--
Alexandre Julliard
[EMAIL PROTECTED]
);
+WCMD_parameter (p, 2+negate+test, s);
This doesn't look right. The number of parameters doesn't depend on
the result of the test.
--
Alexandre Julliard
[EMAIL PROTECTED]
something like:
make clean
make all EXTRADEFS=-DNO_DEBUG_MSGS
--
Alexandre Julliard
[EMAIL PROTECTED]
wave.c
touch wave.ok
err:wave:wodOpen Rate doesn't match (requested 200 Hz, got 48000 Hz)
err:wave:wodOpen Rate doesn't match (requested 200 Hz, got 48000 Hz)
wave.c:145: Test failed: opening the device at 2MHz should fail 0: rc=4
--
Alexandre Julliard
[EMAIL PROTECTED]
then I much prefer the approach of creating
a dummy .o and handling that in the wrapper tool. It's still ugly but
at least it's much less complexity to maintain for such an IMO minor
feature.
--
Alexandre Julliard
[EMAIL PROTECTED]
. But then of course
we should rename it consistently everywhere, not just in wineinstall.
--
Alexandre Julliard
[EMAIL PROTECTED]
support everything we need for that. The
main missing feature is the user interface feedback on the install
progress, but we can probably live without that at first.
--
Alexandre Julliard
[EMAIL PROTECTED]
, you should have some kind of register CLSID
function that takes a CLSID and uses StringFromCLSID or whatever to
create the corresponding registry key.
--
Alexandre Julliard
[EMAIL PROTECTED]
as PE
too.
--
Alexandre Julliard
[EMAIL PROTECTED]
people are going to review the
auto-generated stuff anyway. Just do what's easiest for you.
--
Alexandre Julliard
[EMAIL PROTECTED]
, that's why we should get rid of it all, and
use the exact same include names and dependencies as Windows. Anything
else is a nightmare to maintain.
--
Alexandre Julliard
[EMAIL PROTECTED]
. where should I see the NO_DEBUG_MSGS)
It should be in include/config.h.
--
Alexandre Julliard
[EMAIL PROTECTED]
will generate references into the ELF
GOT so you need to do the fixups there, which is basically what an ELF
loader does. What we do for functions is to make the ELF loader link
to our version of the function, and then jump to the real one; but of
course this cannot work with variables.
--
Alexandre
of the
right size, and then you can use standard strcpy/strcat/sprintf/etc.
without worrying about lengths.
--
Alexandre Julliard
[EMAIL PROTECTED]
.
--
Alexandre Julliard
[EMAIL PROTECTED]
.
--
Alexandre Julliard
[EMAIL PROTECTED]
things down
and makes no difference for the app. We should only add it if/when we
really need it.
--
Alexandre Julliard
[EMAIL PROTECTED]
believe should be possible).
Not only possible, it's already implemented:
apt-get install mingw32
./configure
make crosstest
--
Alexandre Julliard
[EMAIL PROTECTED]
apply
it? After all he took the time to submit it too...
--
Alexandre Julliard
[EMAIL PROTECTED]
of
strcats. And I don't think we need to worry about this kind of
micro-optimizations right now...
--
Alexandre Julliard
[EMAIL PROTECTED]
instead of being
directly under wine/, but it's not too bad. As long as you don't
change anything in the source tree I could be convinced to go along
with that...
--
Alexandre Julliard
[EMAIL PROTECTED]
ELF binary). This also (mostly) solves the Running issues:
you still have a .exe.so file, but you don't really need to worry
about it. You simply run foo and everything works.
--
Alexandre Julliard
[EMAIL PROTECTED]
don't break the current .res support that
wouldn't matter too much I guess.
--
Alexandre Julliard
[EMAIL PROTECTED]
Dimitrie O. Paun [EMAIL PROTECTED] writes:
What happened with this patch by Patrik:
Committed on 11/18...
--
Alexandre Julliard
[EMAIL PROTECTED]
to be done at startup so you need to handle that too. A way
would be to start with +relay, turn it off with wine_dbg_parse_options,
and then turn it on again when needed.
--
Alexandre Julliard
[EMAIL PROTECTED]
Vincent Béron [EMAIL PROTECTED] writes:
Sorry, the last 3 patches were sent to the wrong list. At least they
weren't big.
Alexandre, do you want me to resend them to wine-patches proper?
No need, I grabbed them from here. Just don't do it again g
--
Alexandre Julliard
[EMAIL PROTECTED]
--
Alexandre Julliard
[EMAIL PROTECTED]
*/
DLGWINDOWEXTRA, /* extra */
--
Alexandre Julliard
[EMAIL PROTECTED]
, the values for cp936 byte2 apparently go from
0x40 to 0xfe. Any cp936 experts out there?
--
Alexandre Julliard
[EMAIL PROTECTED]
it again with some linker magic, now that apps no longer link to dlls
directly. That's definitely something we should try to do as part of
the making winelib more user-friendly task.
--
Alexandre Julliard
[EMAIL PROTECTED]
301 - 400 of 1379 matches
Mail list logo
