Hi, got the same errors here with Wine today CVS,
updated RedHat Gnome system.
--- Sami Aario [EMAIL PROTECTED] a écrit :
Hi,
The conformance tests fail for the 20031016 build on my system with
the following error message:
../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p
Under Windows my program exe file is about 6Mb.
Under Linux and Wine it is about 50Mb (.so file).
It is normal ?
And Wine makes Segmentation fault on initialising global variables of my
program.
#1 0x40bb0116 in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535) at
On Tue, 28 Oct 2003 13:25:53 +0300, Sir flyker scribed thus:
Under Windows my program exe file is about 6Mb.
Under Linux and Wine it is about 50Mb (.so file).
It is normal ?
You probably haven't stripped the binary, so it has full debug symbols in
it. Try using the strip command.
Of course, as we don't actually implement the new XP APIs yet, this is
all rather academic. Still, why not take a look at what we'll be
reimplementing in 2010 ;)
SDK: http://longhorn.msdn.microsoft.com/
Articles/Info: http://msdn.microsoft.com/longhorn
thanks -mike
Hi Alexandre,
I noticed the ChangeLog for the new CXOffice release (congrats on that
btw!) said it now works with all glibc 2.3 variants. Does that mean the
TLS related named pipe breakage we saw earlier is now fixed? If so, do you
know when the fix will be in WineHQ CVS?
thanks -mike
Hi,
I want to propose a possible improvement for the wine (and especially winelib)
documentation on the WineHQ website: I would like each chapter and section to be dated
with the latest release date (like a CVS header etc.), so that the reader knows when
the information has been composed.
Hi,
once again I would like to get your advice on spec files. I now compiled a Windows
application successful against winelib and can link it without problems. However, the
application segfaults immediately when starting wine. I am tracking this back to .spec
files (although I will need to
DWORD SearchPath(
LPCTSTR lpszPath, // address of search path
LPCTSTR lpszFile, // address of filename
LPCTSTR lpszExtension, // address of extension
DWORD cchReturnBuffer, // size, in characters, of buffer
LPTSTR lpszReturnBuffer, // address of buffer for found
Is the HeapAlloc/ReAlloc stuff being tracked anywhere? I think it is
the cause of a lot of problems I have with shell32 under Windows and
ReactOS. Applications linked to wine shell32.dll under Windows2000 run
fine but when you exit they get illigal op's where the memory could not
be read kind of
This has fixed the problem slightly (see message titled Bug in
cxx_frame_handler) - the program now displays:
err:seh:setup_exception stack overflow 592 bytes in thread 000e eip 401c425a
esp 40640db0 stack 0x4054-0x4075
And then exits.
I still believe there is a problem in
On Tue, 28 Oct 2003, Steven Edwards wrote:
Is the HeapAlloc/ReAlloc stuff being tracked anywhere? I think it is
the cause of a lot of problems I have with shell32 under Windows and
ReactOS. Applications linked to wine shell32.dll under Windows2000 run
fine but when you exit they get illigal
Hans Leidekker wrote:
On Mon, 27 Oct 2003, Jakob Eriksson wrote:
Why is this not applied?
Because the problem was with MinGW's import lib, not with Wine's comctl
conformance test. I have submitted a patch to MinGW but it's not applied
yet (it has generated quite a discussion over there
My nightly autobuilder on FreeBSD 5.1 noticed the following warning
introduced yesterday:
signal_i386.c:524: warning: `save_context' defined but not used
signal_i386.c:602: warning: `restore_context' defined but not used
Also, there are two OpenGL warnings left, after most have been fixed
a
I have noticed this bug in wine for some time, (winex has corrected
it btw). It seems that new windows, child windows, and message boxes are
incorrectly handled in wine, when created they are often put at the
bottem of the stack of wine windows and not given focus.
This is bad expecialy
Hi lists,
Winesetuptk 0.7 is at the wine sourceforge page
http://sourceforge.net/project/showfiles.php?group_id=6241
This new version contains an updated winedefault.reg, you don't need to run
regedit winedefault.reg any more, and it's updated to configurate all the
latest and greatest features
Mike Hearn [EMAIL PROTECTED] writes:
I noticed the ChangeLog for the new CXOffice release (congrats on that
btw!) said it now works with all glibc 2.3 variants. Does that mean the
TLS related named pipe breakage we saw earlier is now fixed? If so, do you
know when the fix will be in WineHQ
Le lun 27/10/2003 à 06:05, Mike McCormack a écrit :
Hi Subhobroto,
Vincent Béron wrote:
}
+
//
+char szTemp[MAX_PATH]={0};
...
Please don't use // style comments. Not all C compilers
On Tue, 28 Oct 2003, Alexandre Julliard wrote:
Parts of it are merged already, I'm working on the rest. It still
needs a bit of work because the current implementation in Crossover
depends on a wrapper script that we don't have in WineHQ. Also note
that you will need to use --with-nptl to
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Any developments/news on doing this test dynamically?
Still working on it, I'm hoping to have it working by next release,
but no guarantees...
--
Alexandre Julliard
[EMAIL PROTECTED]
Gerald Pfeifer [EMAIL PROTECTED] writes:
was there any problem with the following patch, or did it just fall
through the cracks? ;-)
Gerald
ChangeLog:
Remove unused variable pipe_client_fd_ops.
Well, either the client side should really use pipe_client_fd_ops, or
pipe_server_fd_ops should
Martin Tröster wrote:
Hi,
- Stdcall vs. cdecl
How do I find out whether a function uses CDECL instead of STDCALL? I found the
information (link lost unfortunately) that entries in the def file like [EMAIL
PROTECTED] are called via STDCALL, whereas in case of testfunc2 without any @
specifying
Le mar 28/10/2003 à 07:48, David D. Hagood a écrit :
I'm playing with 2.6.0-test9 under RH9.0, and Wine just coredumps when I
run it.
This is after a full rebuild of Wine, with a CVS pull of a couple of
days ago.
Does your box uses NPTL? With the older and/or the newer kernel?
Is Wine
Compiled via ./configure with --with-nptl, under 2.6.0-test9
Le mar 28/10/2003 à 21:56, David D. Hagood a écrit :
Compiled via ./configure with --with-nptl, under 2.6.0-test9
Are you sure that 2.6.0-test9 uses NPTL? RH's kernels for RH9 have it,
but I'm not sure about Linus' ones.
Vincent
Martin Tröster wrote:
How do I find out whether a function uses CDECL instead of STDCALL? I found the information (link lost unfortunately) that entries in the def file like [EMAIL PROTECTED] are called via STDCALL, whereas in case of testfunc2 without any @ specifying the space is CDECL. Is this
[EMAIL PROTECTED] wrote:
I sent a patch that looks like yours and it was simply refused !
I wasn't the fisrt...
Because there were no explanations provided except that warning
message. If keyboard input works for you, there is no need to
send a patch.
--
Dmitry.
At least, the detection mismatches should be fixed/explained IMHO.
As it was said already, we will need at some point to comment out
that
FIXME in keyboard.c. If the keyboard input works for you, then I
don't
see what needs to be fixed.
Hi folks,
We have a problem with 'make install' in the libs dir.
More explicitly, after a 'make make install', I have
this in /usr/local/lib:
[EMAIL PROTECTED] unicode]$ ls -l /usr/local/lib/libwine*
-rw-r--r--1 root root 319332 Oct 27 12:01 /usr/local/lib/libwine_port.a
28 matches
Mail list logo
