Andreas Mohr wrote:
But don't you think keyboard and joystick might need the same code??
(keyboard has it as well, but with completely different code -- mess)
This could probably be cleaned up.
I have a patch semi-ready which does the same for keyboard/joystick
using the existing scheme.. but
Hi Sylvain, Sami,
What settings are you using for wine? I don't see this problem with WRT,
but I've only recently got it back up and running again.
On a seperate note, some other strange things I've noticed:
One of Monday night's patches seems to have broken a conformance test in
listbox.c
Hi,
During some application testing, we discovered that WinE does not
correctly mimic the WinINet function InternetCrackUrl. The real WinAPI
sets the dwUrlPathLength member of the URL_COMPONENTS structure to
additionally hold the extra info of the given URL if the extra info is
not requested
Dmitry Timoshkov wrote:
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
Shachar Shemesh [EMAIL PROTECTED] wrote:
5. In the future, windows keyboard language APIs will need to be
handled. For those to work, we must be aware of which is the current
keyboard.
This one is just a missing functionality (support for keyboard layouts),
and has nothing to do with
A new tarball of valgrind modified to work with WINE is available from the
valgrind home page:
http://developer.kde.org/~sewardj/
http://developer.kde.org/~sewardj/valgrind-20031012-wine.tar.bz2
this is based on the latest stable valgrind release.
use a current CVS or the latest snapshot of
Dmitry Timoshkov wrote:
Shachar Shemesh [EMAIL PROTECTED] wrote:
The reason I listed it here is because in order for Wine to know what
language the current keyboard is, it will also need to know what's the
current keyboard.
I have thought of two ways for Wine to do that - either it checks
The simple test crashes wine.
And i think many other commands in constructor A() may crash wine.
test.cpp:
#include windows.h
#include stdio.h
class A
{
public:
A();
};
A::A()
{
LoadLibrary(user32.dll); // all ok user32.dll is present
}
A a;
int WinMain(HINSTANCE hInst, HINSTANCE, LPSTR
I have the following setup
mfctest/Makefile - Main make file
mfctest.exe.so - is the wrapper for an mfc gui application
mfctest.dll.so - is the mfc gui application (as generated by the
msvc++ wizard and than winemaker)
msvc/Makefile - make file for mfc stuff missing from msvcrt.dll
Le mer 29/10/2003 à 09:02, flyker a écrit :
The simple test crashes wine.
And i think many other commands in constructor A() may crash wine.
Huh?
Works fine here cross-compiled with mingw.
Even added 2 printf (one to the constructor, the other in WinMain), and
the constructor one is called
Vincent Béron wrote:
Huh?
Works fine here cross-compiled with mingw.
Even added 2 printf (one to the constructor, the other in WinMain), and
the constructor one is called first (as it should be).
Vincent
RedHat 9.0, gcc and winelib.
Of course constructor first.
Boaz Harrosh wrote:
use --wrap in winemaker. Read about this option in the documentation
Thanks. It is work :)
I'm Just exactly now fighting same problems.
See my last post: Help with shared library make files
Note 2 things
A. Initialization order is opposite of msvc++ Last object on the linker
gets to run first. (msvc first on the command line first to initialize)
B. Hard, in gdb (kdevelop), to set a
Hello Robert,
I have a question for my start menu generator, that is almost finished
now...
How do I find the path of the wine start menu? (for me it's
~/c/windows/Start Menu, but for someone else it does not have to be like
that...)
Any help here?
Ypu should use the function
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Shachar Shemesh
Sent: 29 October 2003 13:41
To: Wine Devel
Subject: Forwards exports - anyone?
Hi all,
I noticed in the code that there is a concept called forwad_export.
Does it have anything to do
Robert van Herk [EMAIL PROTECTED] wrote:
I have a question for my start menu generator, that is almost finished
now...
How do I find the path of the wine start menu? (for me it's
~/c/windows/Start Menu, but for someone else it does not have to be like
that...)
I assume/hope you have a
Jason Edmeades [EMAIL PROTECTED] writes:
Michael - See if this helps with your map / figure problems...
Sorry, but it doesn't helped. Also the other ones doesn't helped. The
fixme's
fixme:d3d_surface:IDirect3DSurface8Impl_LockRect
fixme:d3d:IDirect3DDevice8Impl_SetRenderTarget
Hi folks,
I think I hunted down a bug in DOS int21 function 0x5b (my DOS book insists
this is 91 decimal). My older version of wine, 2000821, goes like this:
trace:int21:DOS3Call CREATE NEW FILE 0x00 for X:\TMP41.$$$
trace:file:CreateFileA X:\TMP41.$$$ GENERIC_READ GENERIC_WRITE FILE_SHARE_READ
Hello all
I corrected my last patch after replacing everything
C++ into C.
This patch has been inlined as well as attached as a
ZIP file, so suit yourself.
All reports regaring this patch is to be sent to
subhobrotosinha at yahoo.com with a proper subject
prefixed by IPersistFile patch in the
On Wed, Oct 29, 2003 at 01:24:42PM +0100, Valentijn Sessink wrote:
Hi folks,
I think I hunted down a bug in DOS int21 function 0x5b (my DOS book insists
this is 91 decimal). My older version of wine, 2000821, goes like this:
We also checked Codeweavers Wine for this bug; it seems to be
Hello,
Here goes some notes about how to install installshield 7 programs
with the actual wine releases (sorry, i haven't been able to
Dimitrie O. Paun [EMAIL PROTECTED] writes:
That is to say, both libwine.so and libwine_unicode.so are fubared.
They point to old libs. Shouldn't they just point to the .1 versions?
Yes, and it seems to work fine here. Could you show us the exact
commands you ran and the relevant make output?
On Wednesday 29 October 2003 03:29 pm, Carlos Lozano wrote:
Hello,
Here goes some notes about how to install installshield 7 programs
with the actual wine releases (sorry, i haven't been able to install
without some natives DLLs).
Could you recommend any particular installer that fails to me
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Well, I did a standard build:
configure --with-nptl --silent make -s depend make -s
than installed it (as root):
make -s install
My guess is that ldconfig has messed with the symlinks.
--
Alexandre Julliard
[EMAIL PROTECTED]
Hello All,
Apologies if I'm not posting to the correct location. I am trying to port
our X-Lite (a leading free SIP softphone) application to run under WINE as a
first trial before we obtain the expertise to do a native application.
However, I am running into some issues because our application
Rob wrote:
The show stopper bugs are B1, B2, B3, B4 and B5.
Issue B5, and B7 can be worked around, so they aren't as critical.
B1, B2, B3, and B4 can be fixed by putting a title bar on the application.
(See MAKE_IT_LOOK_LIKE_A_NORMAL_APP_AT_STARTUP in winetest.cpp.)
- B1. Focus does not appear
I apologise for not concentrating; I'm sure that someone has already answered
this but I can't find the answer.
Do the rpms at SourceForge expire?
(I see that the 20030618 for RedHat are no longer there)
I just want to know since if that is the case I will have to start taking
copies.
On the
Could you retry with current CVS, or if you cant, 20031016 ?
So: file handle 0x136 translates to DOS handle 10, and int21 returns
AX=0x000a
My newer version, Wine 20030408, does the following:
snip
I'm not sure, but this bug could also help number 1170, that seems
related
in that
28 matches
Mail list logo
