First - it appears the function name is sufficient to detect that.
Despite that, here are a few nit-picking corrections:
Jerry Jenkins wrote:
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
"Sylvain Petreolle" <[EMAIL PROTECTED]> wrote:
> At least, the detection mismatches should be fixed/explained IMHO.
I think that this topic was explained many times already.
Anyway, here is yet another attempt.
1. Keyboard detection code was introduced in order to make
some picky DOS games (expe
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
lrwxrwxrw
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.
_
"Sylvain Petreolle" <[EMAIL PROTECTED]> wrote:
> To give the subject a second life :
> My French keyboard works without problems today in Wine, and Wine
> refuses to detect it, giving tons of keyboard mismatches when enabling
> +key,+keyboard.
>
> As a result, I put a comment into dlls/x11drv/ke
> 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,
To give the subject a second life :
My French keyboard works without problems today in Wine, and Wine
refuses to detect it, giving tons of keyb
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> STDCALL means PASCAL call format. This means two things, mostly. First
> -
> it means arguments are pushed on the stack left to right instead of
> right to left (no way you can pass printf style variable length
> arguments). The second is that it is th
"Martin Tröster" <[EMAIL PROTECTED]> writes:
> - Stack size and parameters in spec file:
> The def files are, as far as I know, very similar to the spec files:
> they contain the function name (either mangled or not mangled), as
> well as (most of the time) the stack space - format:
> [EMAIL PROTE
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
Compiled via ./configure with --with-nptl, under 2.6.0-test9
<[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.
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 g
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
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
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_op
"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]
I sent a patch that looks like yours and it was simply refused ! I wasn't the fisrt...
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
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
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 Wine
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 o
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 i
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 by
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 f
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 illiga
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 dlls/msvc
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
I have only managed to compile and link MFC with the msvcrt.dll the std
way would not work.
Now the MFC has lots of:
void CleanFoo()
{
}
int init = atexit( CleanFoo ) ;
The call to atexit will in-turn call _lock if we look at _lock.c :
...
/* If the lock doesn't exist yet, create it */
I have Just downloaded and installed a very nice "forms" System. It took me 1
minutes to download and 10 minuets to install (Including reading the
documentation). It has lots of advantages over the http://phorum.org/
system. With e-mail getaways chats and more. Have a look at:
http://phpnuke.or
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 filena
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.
Since I've seen some other apps behaving weirdly this may be a
compatibility issue with 2.6, but I thought I'd see if anybody else has
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 debu
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. Furth
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
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
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.
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 ../.
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 m
Hi,
On Tue, Oct 28, 2003 at 02:53:44AM +0200, Hannu Valtonen wrote:
> License: LGPL
>
> I stumbled upon this when looking at fixing mouse support for Crimson
> lands. According to MSDN DirectInputDevice Unacquire is allowed even for
> devices which haven't been acquired yet.
>
> Changelog:
> -
39 matches
Mail list logo
