be
autodetected most of the time so it shouldn't matter much.
But at least it would be nice if we could configure the winver from the
~/.wine/config file.
Is there any reason not to do it?
No, it's done now g
--
Alexandre Julliard
[EMAIL PROTECTED]
options.
Does gdb really support 16-bit pointers now? Otherwise I don't see
how you can step through 16-bit code. And even if 16-bit binaries are
not really important, support for 16-bit pointers definitely is.
--
Alexandre Julliard
[EMAIL PROTECTED]
that strncpy will fill the buffer with nulls if the string is too
short. I doubt that Windows does that, though it may be a good idea to
check for it in your test too.
--
Alexandre Julliard
[EMAIL PROTECTED]
idea to support the
NT winhlp32 too; I don't think we should try to support Win98 type
message passing.
--
Alexandre Julliard
[EMAIL PROTECTED]
a problem, or maybe it isn't.
Has anybody a clue if this error is important?
It's not, that's why it is only a warning. In cases where it's a real
problem you will get the same message as error, not as warning.
--
Alexandre Julliard
[EMAIL PROTECTED]
.
--
Alexandre Julliard
[EMAIL PROTECTED]
Eric Pouech [EMAIL PROTECTED] writes:
Alexandre, will you accept a patch of this kind (it still
can be enhanced, like storing the message id) ?
Only if there is evidence that Windows does it this way.
--
Alexandre Julliard
[EMAIL PROTECTED]
changes to allow
using wildcards in there so that it's a bit easier to configure. I'm
open to other suggestions, but I don't think disabling the
functionality is the way to go.
--
Alexandre Julliard
[EMAIL PROTECTED]
of concept but it was not meant to be applied as is.
--
Alexandre Julliard
[EMAIL PROTECTED]
for
you. Sure, if we can make it easier we should (and I believe the
wildcards should help), but we should not sacrifice functionality for
such exotic cases.
--
Alexandre Julliard
[EMAIL PROTECTED]
...
Anyway, something like ' --dll */comctr32=b ' that would defeat _any_
native comctl32 from loading is good too.
That's basically what my patch will do.
--
Alexandre Julliard
[EMAIL PROTECTED]
want to scare your
users with dozens of meaningless errors. That's not good.
--
Alexandre Julliard
[EMAIL PROTECTED]
a message box
or something like this. The user should not be required to start Wine
from an xterm to be able to figure out what's going on.
--
Alexandre Julliard
[EMAIL PROTECTED]
that the mingw linker should be doing this automatically.
--
Alexandre Julliard
[EMAIL PROTECTED]
be to not
use them, otherwise we won't find such problems. And the
GetSysColorPen and wvsprintf exports really need to be fixed if we
ever want to use Wine dlls under Windows.
--
Alexandre Julliard
[EMAIL PROTECTED]
change, but your code may be used in other
products where reporting problems to you is not the appropriate thing
to do. Just say please report this and let users figure out where to
report it.
--
Alexandre Julliard
[EMAIL PROTECTED]
-with-no-decorations mode I mentioned, but there
are much larger problems with that to be solved first.
--
Alexandre Julliard
[EMAIL PROTECTED]
strncmpiW
strstrW
+ strtolW
+ strtoulW
+ utf8_mbstowcs
+ utf8_wcstombs
+ wctype_table
--
Alexandre Julliard
[EMAIL PROTECTED]
Dimitrie O. Paun [EMAIL PROTECTED] writes:
And I thought stderr was unbuffered...
Not under Windows apparently.
--
Alexandre Julliard
[EMAIL PROTECTED]
what you'll need to fix, your
patch is only hiding the problem.
--
Alexandre Julliard
[EMAIL PROTECTED]
Dustin Navea [EMAIL PROTECTED] writes:
any chance you could
apply the mask until a real solution is found (and
submitted)?
I see that you are new around here ;-)
--
Alexandre Julliard
[EMAIL PROTECTED]
for other platforms, for instance if you
want to run a Wine dll under Windows. There are not used under the
standard Wine.
--
Alexandre Julliard
[EMAIL PROTECTED]
to libwine.
Yes, exactly. Dlls are linked against libwine the same way they are
linked against the C library, using the standard ELF linking.
--
Alexandre Julliard
[EMAIL PROTECTED]
out
there, so any attempt at changing it will only result in major
confusion. And we would have to start using winehq.org email addresses
too, which would likely double the amount of spam we get g
--
Alexandre Julliard
[EMAIL PROTECTED]
general solution at some point that will again enable
global config files. At the moment if you want that behavior you have
to create a symlink from ~/.wine/config to some global config.
--
Alexandre Julliard
[EMAIL PROTECTED]
in the Wine developer's guide
instead.
--
Alexandre Julliard
[EMAIL PROTECTED]
configure and make
--
Alexandre Julliard
[EMAIL PROTECTED]
a
drive for /usr/local/bin (except if you want to launch real Unix
binaries from there too).
--
Alexandre Julliard
[EMAIL PROTECTED]
the right way would be to put that functionality in
libwine_unicode, and follow the naming convention that we are using
there (for instance wcstol would be strtolW). This way we are sure the
prototypes won't conflict.
--
Alexandre Julliard
[EMAIL PROTECTED]
away for dll separation anyway.
--
Alexandre Julliard
[EMAIL PROTECTED]
a note to wine-devel at the same time so that
other developers can jump in if they know the solution.
--
Alexandre Julliard
[EMAIL PROTECTED]
.
--
Alexandre Julliard
[EMAIL PROTECTED]
.
This should be fixed by my latest patch too. At least it seems to work
for me when cross-compiling, I have sucessfully built winemine.exe
with mingw (you need to remove ntdll and libwine from the link to make
it work, I'll try to fix that shortly).
--
Alexandre Julliard
[EMAIL PROTECTED]
is to simply redefine the
necessary structure ourselves; this way it works with all kernels even
if you don't have the proper headers on the build machine.
--
Alexandre Julliard
[EMAIL PROTECTED]
someone who cares takes the trouble
to make it work again. It's not like there is a huge public demand for
that language g
--
Alexandre Julliard
[EMAIL PROTECTED]
Steven Edwards [EMAIL PROTECTED] writes:
If I need to build libwine with my port even though I don't really need
a libwine.dll I can, it just is a little waste of time.
You definitely need a libwine.dll. It's used for the portability
routines.
--
Alexandre Julliard
[EMAIL PROTECTED]
of LGPL-ed code relicensed
in exchange...
Last we heard it was to be exchanged against the ALSA driver...
--
Alexandre Julliard
[EMAIL PROTECTED]
.
--
Alexandre Julliard
[EMAIL PROTECTED]
, or for
Transgaming.
--
Alexandre Julliard
[EMAIL PROTECTED]
in the mingw/VC++ port.
I'm not sure I understand the problem. wrc generates .res files that
should work just fine with MS VC or windres. Why doesn't this work?
--
Alexandre Julliard
[EMAIL PROTECTED]
time a binary file
changes.
--
Alexandre Julliard
[EMAIL PROTECTED]
no longer download a 500Kb Wine-xxx.diff.gz and need to download
the 7Mb Wine-xxx.tar.gz instead. It basically makes the .diff.gz files
useless for upgrading.
--
Alexandre Julliard
[EMAIL PROTECTED]
to ship binary files for that.
--
Alexandre Julliard
[EMAIL PROTECTED]
Andriy Palamarchuk [EMAIL PROTECTED] writes:
Alexandre,
do we really want to install winemine Wine
application by default?
Sure, why not?
--
Alexandre Julliard
[EMAIL PROTECTED]
.
--
Alexandre Julliard
[EMAIL PROTECTED]
message that is sent
from the FocusOut event handler. I'm not sure why it doesn't work in
your case.
--
Alexandre Julliard
[EMAIL PROTECTED]
handled by the filesystem functions. You don't need to
do anything.
--
Alexandre Julliard
[EMAIL PROTECTED]
complete lpr implementations.
Of course there's also the possibility that some systems might have a
working lpr and a broken lp... It may be a better idea to make this
configurable.
--
Alexandre Julliard
[EMAIL PROTECTED]
without warrnings/errors from
stupid MAX_PATH. If someone has a better way please cvs diff -u me =)
I have committed a different fix that I think should work too, please
give it a try. We should be 100% Windows-compatible now so if it still
doesn't work I'd say the problem is in Mingw.
--
Alexandre
building a def or looking for
imports. I was going to have a look at the loader/winedump code for
ideas but I thought I would ask here first.
Why does it need to look for imports when building the .def file?
I thought I had fixed that.
--
Alexandre Julliard
[EMAIL PROTECTED]
with LP: not CUPS:. At the winspool level
we should probably use the cups API as Huw mentioned.
--
Alexandre Julliard
[EMAIL PROTECTED]
).
--
Alexandre Julliard
[EMAIL PROTECTED]
Steven Edwards [EMAIL PROTECTED] writes:
Is this a mingw problem? If so I wil go talk to them, if not then it
just needs
This before the MAX_PATH define.
IMO it's a mingw problem, stdlib.h is not supposed to define MAX_PATH,
only _MAX_PATH.
--
Alexandre Julliard
[EMAIL PROTECTED]
. The
alternative would be to retire FILE_GetUnixHandle, or maybe move the
shutdown flags handling into wine_server_handle_to_fd.
--
Alexandre Julliard
[EMAIL PROTECTED]
the overlapped attribute, this must be fixed.
It would be better to use TlsAlloc for that, winsock ideally shouldn't
depend on the internal thread structure (dll separation again...)
--
Alexandre Julliard
[EMAIL PROTECTED]
are this:
users need to set $LD_LIBRARY PATH
No, WINEDLLPATH is correct. You must *not* set LD_LIBRARY_PATH to
$libdir/wine, nor add it to ld.so.conf. ld.so will never load
libraries from that directory, only Wine does, and it uses WINEDLLPATH
for that.
--
Alexandre Julliard
[EMAIL PROTECTED]
. At least that's how it's done under Windows.
--
Alexandre Julliard
[EMAIL PROTECTED]
a complete relay trace too.
--
Alexandre Julliard
[EMAIL PROTECTED]
_MAX_DRIVE
+#include stdlib.h
+#endif
+
Why do you need stdlib.h in wingdi.h? It's not there under Windows.
--
Alexandre Julliard
[EMAIL PROTECTED]
Michael Cardenas [EMAIL PROTECTED] writes:
do these patches include his fixes from today?
Not yet, coming up soon.
--
Alexandre Julliard
[EMAIL PROTECTED]
in standard Windows
headers since the app using them may not have a configure script.
--
Alexandre Julliard
[EMAIL PROTECTED]
tested if you run with the wrong version.
The right way is to always call the function no matter the version,
and check that the call either succeeds as expected, or fails in the
way that it's supposed to fail on a platform that doesn't support it.
--
Alexandre Julliard
[EMAIL PROTECTED]
that
was specified with --prefix (which shouldn't happen with
wineinstall).
--
Alexandre Julliard
[EMAIL PROTECTED]
and native dlls. But it's better to
avoid it if possible.
--
Alexandre Julliard
[EMAIL PROTECTED]
you can also compile it to support
both 0.5 and 0.9 if you have all the necessary headers, and detect
which version to use at run-time. If this is not possible we need two
separate drivers, otherwise it won't be possible to build a binary
package that works for everybody.
--
Alexandre Julliard
in the server, you
must store a pointer to the object and allocate a handle when
returning it to the application. Handles are only valid in one process
so they cannot be part of a server object that is potentially shared
between several processes.
--
Alexandre Julliard
[EMAIL PROTECTED]
Uwe Bonnes [EMAIL PROTECTED] writes:
The wine executable now doesn't understand OPTIONS any more. It is
nescessary to give options in the WINEOPTIONS environment variable. Is this
intended?
No, stupid typo on my part. Should be fixed now.
--
Alexandre Julliard
[EMAIL PROTECTED]
That's more or less the plan yes. We are slowly getting there. I have
not moved everything yet because it's not yet clear where everything
will go (most notably for the ntdll/kernel proper separation) and I
don't want to move things twice given CVS weaknesses in that area.
--
Alexandre Julliard
?
We can't. User messages cannot pass data around, WinHelpA will need to
do that differently. The best way to find out how is probably to watch
winhlp32 with a message spy under Windows.
--
Alexandre Julliard
[EMAIL PROTECTED]
will contain
thousands of individual tests and you won't be able to come up with
meaningful names for them anyway. For the same reason, I don't think
displaying every successful test is really useful. Traces are a much
better way to see what's going on IMO.
--
Alexandre Julliard
[EMAIL PROTECTED]
but you can simply copy the code.
--
Alexandre Julliard
[EMAIL PROTECTED]
you want to load the native. And note that you can already
specify a full path in the load order config so you could use that to
solve the problem in your case.
--
Alexandre Julliard
[EMAIL PROTECTED]
it and
continue. We have to unload the dll and its dependencies in that case;
but that's not entirely trivial to do.
--
Alexandre Julliard
[EMAIL PROTECTED]
think that it should be possible to make the dlls
more independent by doing more work in the server; but we should
probably finish the implementation first and then we can start
cleaning things up.
--
Alexandre Julliard
[EMAIL PROTECTED]
to configure them
separately.
--
Alexandre Julliard
[EMAIL PROTECTED]
to be
officially exported from ntdll).
--
Alexandre Julliard
[EMAIL PROTECTED]
to get them some more testing. And it is very important that the tests
behave exactly the same under Windows and Wine so that any difference
can be found. If we start having different code paths on different
platforms we can never be sure that we are actually testing the same
thing.
--
Alexandre
on the application and on the Windows version of the
native dlls. There isn't a single configuration that works better in
all cases.
--
Alexandre Julliard
[EMAIL PROTECTED]
this.
--
Alexandre Julliard
[EMAIL PROTECTED]
are the
most strict.
--
Alexandre Julliard
[EMAIL PROTECTED]
other ways of
attacking the problem?
I'd suggest a -debugmsg +loaddll to see what version of wininet.dll is
getting loaded. I suspect Wine is loading a native one that doesn't
have InternetGetConnectedState.
--
Alexandre Julliard
[EMAIL PROTECTED]
. The platform must be used
exclusively for todo tests, not for changing the test behavior. And
backslashes should work fine under Wine too.
--
Alexandre Julliard
[EMAIL PROTECTED]
.
--
Alexandre Julliard
[EMAIL PROTECTED]
take care of that. Do you have a make that requires this?
If so there are many other places we need to fix too.
--
Alexandre Julliard
[EMAIL PROTECTED]
right now though.
--
Alexandre Julliard
[EMAIL PROTECTED]
/graphical mode, including winedbg - it still work as a unix console
though
I've added a quick hack to fix this for now.
--
Alexandre Julliard
[EMAIL PROTECTED]
searching through
LD_LIBRARY_PATH compared to WINEDLLPATH and the default $prefix
lookup. The runtest script should be fixed now, if you see this
problem in other cases make sure your LD_LIBRARY_PATH and WINEDLLPATH
point to the same Wine installation.
--
Alexandre Julliard
[EMAIL PROTECTED]
handling.
You should try the CVS tip, this is done differently now (won't
necessarily work better though...)
--
Alexandre Julliard
[EMAIL PROTECTED]
call LoadCursor.
And LoadCursor on system cursors is not supposed to fail so there is
no need to handle that case; if it fails it's a bug that should be
fixed.
--
Alexandre Julliard
[EMAIL PROTECTED]
are going to
change. It will probably be fixed at some point, but there's no need
to worry about it for now.
--
Alexandre Julliard
[EMAIL PROTECTED]
the cursor. This is
also used by ShowCursor().
--
Alexandre Julliard
[EMAIL PROTECTED]
.spec.c files on Windows? All you should
need is a .def file, and maybe a small hack for the debug channels
declarations.
--
Alexandre Julliard
[EMAIL PROTECTED]
fix
no matter what g
--
Alexandre Julliard
[EMAIL PROTECTED]
that are mostly in
place now, which is what I mean by saying it is finished.
--
Alexandre Julliard
[EMAIL PROTECTED]
version doesn't match...
so, it seems you'll be removing this test after the protocol
freeze (or at least that the protocol version returned in
init_thread is greater the frozen protocol version)
Yes.
PS: any answer on the reasons for not applying the toolhelp patch?
Working on it...
--
Alexandre
can't really separate the PE loader
from the rest of ntdll since it needs to interface with memory
management etc. You could write a separate PE loader but then it
couldn't be used to load real Window apps.
--
Alexandre Julliard
[EMAIL PROTECTED]
and the mmap area
starts at the 1Gb mark on Linux. It shouldn't be too hard to work
around this limitation, I will give it a try.
--
Alexandre Julliard
[EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
ChangeLog:
dlls/shlwapi/path.c:
Lawson Whitney [EMAIL PROTECTED]
Protect PathIsUNCServerShare from bad lpszPath.
Windows doesn't seem to do this. The bad pointer probably comes from
an earlier bug.
--
Alexandre Julliard
[EMAIL PROTECTED]
). The size limit is necessary to ensure
forward compatibility and should not be changed.
--
Alexandre Julliard
[EMAIL PROTECTED]
don't. If you really want to do something about it, consider working
on dll separation so that we can finally put all dlls in the right
place.
--
Alexandre Julliard
[EMAIL PROTECTED]
701 - 800 of 1379 matches
Mail list logo
