I've been chasing a bug for a few days, and finally have a good idea of
what is going on. When a program brings up a modal dialog box in
response to a WM_KILLFOCUS message, the program will freeze. I've
attached a simple test case, all boilerplate except for:
case WM_KILLFOCUS:
On 6/16/2011 10:49 AM, Ken Thomases wrote:
On Jun 16, 2011, at 9:09 AM, Eric Frias wrote:
I've been chasing a bug for a few days, and finally have a good idea of what is
going on. When a program brings up a modal dialog box in response to a
WM_KILLFOCUS message, the program will freeze
Keyur Pujara wrote:
I am contemplating to port a complex windows
application using winelib over Solaris/SPARC. In one
of the emails in wine-devel list, I saw that there may
be following issues in the process:
* byte endianness
* alignment issues
* pointer size
* must not use x86 assembly
Robert Muller wrote:
Dee Ayy wrote:
| As a newbie, the statement It can be found in the programs
subdirectory.
| had me lost.
[...]
At this point, the sentance that gave you problems could be modified to
say: It can be found in the programs subdirectory of the wine source.
There is one
Alexandre Julliard wrote:
Eric Frias [EMAIL PROTECTED] writes:
here is one other part that is out-of-date: the procedure described
won't create the 'notepad2' script.
winegcc should create the script. If it doesn't it's probably because
winemaker is not invoking it correctly
I've noticed a few problems running wine apps against Hummingbird's
Exceed X server on Windows. The two problems I noticed are:
- The top-level window's title bar is blank, instead of containing
the application's title. And,
- When you take a visible dialog box, hide it
Phil Krylov wrote:
Messed colors and vertical stripes? Similar to
http://www.froq.net/mirage/mirage1.png ?
No, I get rather like this:
http://newstar.rinet.ru/~phil/Screenshot-StarLing-for-Macintosh.png
The StarLing image may be similar, but I think you're both looking at
different
Phil Krylov wrote:
However, I don't think there are a lot of programs using these
APIs... I mean, let's implement it one or another way and wait till some
such programs break (when ported to big-endian machines;) and see how exactly
they will break and fix it then.
True... and probably even
Due to little-endian/big-endian differences, winelib on Sparc can't read
windows metafiles generated on a PC (or on Wine on x86), and conversely
PCs can't read metafiles created on a Sparc. It looks like there are a
few ways this could be fixed, and I wanted to make sure we don't go
about it
Phil Krylov wrote:
I have submitted a patch that fixes creation of on-disk _enhanced_ metafiles
a few days ago:
http://article.gmane.org/gmane.comp.emulators.wine.patches/23393
Thanks for the pointer, I hadn't seen that patch.
It byteswaps EMF records just for writing to disk. Adding
James Hawkins wrote:
On 2/7/06, Eric Frias [EMAIL PROTECTED] wrote:
I think I submitted a version
of this patch a year or two back, but it wasn't accepted.
You should add a unit test for this case in Wine's test suite. It
would be pretty easy to write, and it would verify
Dan Kegel wrote:
Hi Wei Li,
I could not find the info regarding what operating systems (such as AIX 5L v5.2, HP-UX 11i, Solaris Release Level 9) will Winelib run on non-x86 machines.
There's no reason in principle it couldn't run on AIX or HP/UX.
Some work has been done on an HP/UX
Troy Rollo wrote:
winegcc from the current WineHQ produces assembly output for SPARC systems
that cannot be processed by the assembler.
I've attached the patches we're using for winebuild on SPARC. This
fixes both of the problems you're encountering. I'm not sure if the fix
is the right
Marcus Meissner wrote:
On Wed, Oct 26, 2005 at 11:01:51AM -0700, ssawai wrote:
On several places we use third-party components that use native pthreads
from which we receive callbacks in different pthreads.
Is it possible to use Wine/pthread mix? What would be the preferred way
of doing
We're working on setting up an environment to cross-compile a winelib
application (initially from x86 linux to sparc solaris). To do this, we
need a cross-compiling version of winebuild which will generate the
assembly code for the target architecture instead of the build architecture.
I see
Alexandre Julliard wrote:
I think the right way is to get rid of the #ifdefs, but not by pushing
them into the .spec.c file but my making the target a run-time
option. I've been meaning to do this for a while now, I was just
waiting for someone to actually need that feature ;-)
Fantastic!
Eugene Aksenov wrote:
I have a small MFC app ported to winelib which uses MFC compiled with winelib.
Really, it is just an App-Wizard generated application.
I always have a crash of the application after printing. The page is printed ok but after that the app crashes.
[...]
Did anybody meet a
Chuck Hall wrote:
Started to go through this and found something intresting. lwp.h does
exist and is found, so HAVE_SYS_LWP_H is defined. The test for
_lwp_create fails. Looking a bit deeper I found that the lwp.h for
Solaris 9 is different from the one in Solaris 10 (which is what I am
:
http://www.winehq.org/hypermail/wine-patches/2004/11/author.html
under 'Eric Frias'. There aren't too many.
That said, I'm not convinced those patches will be enough to get it
working. I've been working on merging in all of my patches to the
latest wine here, and there were a few
Chuck Hall wrote:
On Wed, 25 May 2005, Eric Frias wrote:
I'll be trying to get the current wine running this afternoon; I'll post
something when it's working.
I look forward to hearing how this turns out.
It actually went more smoothly than I expected. I've attached a patch
Chuck Hall wrote:
I have heard that people are using Wine on Solaris. I would like to know
if they are using Wine on the SPARC version or the x86 version of Solaris?
I'm using it on the Sparc version, with Solaris 7 and 8. Winelib only,
of course, none of the emulation stuff is going to
Chuck Hall wrote:
I should have mentioned what tools I'm using and the why I sent the patch.
I am using the native Sun assembler and linker. The Sun assembler does
not understand the .previous so that is the reason for the patch.
Makes sense. If you get the Sun assembler to work, we should
Mike Hearn wrote:
On Thu, 19 May 2005 17:46:28 -0400, Eric Frias wrote:
I'll get a patch ready once I understand a bit more of what is going on
that is causing wine to reserve this memory.
It's probably blocking off the top 3rd quarter of the address space to
prevent the kernel allocating memory
I just ran into bug 2609:
http://bugs.winehq.org/show_bug.cgi?id=2609
which is that wine fails to initialize when the user has a ulimit for
virtual memory (address space) set to less than around 1300MB. This is
something wine could test for and issue a warning. I know this isn't
technically
James Hawkins wrote:
On 5/5/05, Troy Rollo [EMAIL PROTECTED] wrote:
Precisely. WINE is not just for running apps compiled for Windows - it's also
for making the Windows API available under UNIX. For this second application,
users need to (at a minimum) be seeing UNIX paths (and not Windows paths
Mark Greenbank wrote:
Still trying to compile wine for Solaris 10 but this time I'm getting
a message during the build that virtual memory has been exhausted.
I traced this to an xrealloc call requesting a realloc of 0 size;
could this be correct?
I've seen this bug before. The behavior of
I'm trying to get winelib working on a platform whose X server doesn't
have native support for TrueType fonts. I've configured wine with
freetype, but it never seems to display the TrueType fonts. I don't
have xfsft or xfstt installed.
Should I expect this to work? I don't understand
Huw D M Davies wrote:
If you've got this, then it means Wine is happily using FreeType. In
this case Wine will (by default) render the fonts itself and display
them via the X RENDER extension. This means that it'll not use X11
font mechanisms at all. If Wine can't use the RENDER extension then
Mike Hearn wrote:
On Tue, 04 Jan 2005 11:22:00 -0500, Dan Notestein wrote:
Btw, if anyone is interested we also have another module which
can be used to convert the windows-style drive letters returned
by the common dialogs into unix-style paths (if you want to use
these paths will normal file
Dmitry Timoshkov [EMAIL PROTECTED] wrote:
This won't compile with older C compilers, you are mixing data
declarations
with code.
Good catch, that slipped right past me. A corrected patch is attached.
Eric
dialogex-revisited.diff
Description: Binary data
Juan Lang [EMAIL PROTECTED] wrote:
Somewhere, for some reason, our client code was calling
PeekMessage(NULL, ...), basically asking windows to
discard a single message without returning it. From the
MSDN docs, this seems like an illegal use of the function,
but Windows does the right
Juan Lang a écrit :
Yikes. That's a bad one. The trouble is MS loves
this sort of return value. Even if the dll itself
doesn't dereference an unaligned pointer, the caller
might depending on how things are layed out. The
trouble is i386 allows unaligned memory access, so we
don't see
Jia L Wu [EMAIL PROTECTED] wrote:
It seems that I have to write a spec file for each dll to import(and
export) functions provide by other dlls. However, since they all written
in c++ and what need to be imported can either be class or class method,
and parameters can be class either. SO I
From: Boaz Harrosh [EMAIL PROTECTED]
Not happy and is a bit out of dated but it Looks it could still work
today.
[...]
Thanks for the suggestion! Even if it isn't elegant, it sounds like it will
work (and is very close to what we were doing with the older wine). I might
even be able to coax
Boaz Harrosh [EMAIL PROTECTED] wrote:
[...] so I'm curious where all of the time is spent.
Most definitely the Linux-shared loader. It took ages. The code is heavy
C++ code full of templates with weak symbols, inline virtual functions,
and plain horizontal code structure. almost any thing you
Firewall/[EMAIL PROTECTED] writes:
I guess my main question is: why is so much assembly needed there - can
some or all of it be replaced by C code (at least on platforms where you
never need to interact with real windows libs - like sparc/solaris and
pa-risc/hpux)?
I'm afraid I won't be a lot
Alexandre Julliard [EMAIL PROTECTED] wrote:
Eric Frias [EMAIL PROTECTED] writes:
I'm curious how much work would be involved in fixing [multiple
displays]
correctly.
Basically you need to change the window management code in the server
to support multiple window hierarchies, and create one
Alexandre Julliard (julliard_at_winehq.org) wrote: We don't support having
the same user run from different displays at the same time. I don't think
that's a common setup at all.
It probably is not a common setup, but Boaz isn't the only person to have
been bitten by this. It has happened both to
38 matches
Mail list logo
