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 f
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:
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
Co
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 i
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 o
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 (ShowWindow(SW_HID
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 b
I'm trying to debug a problem in which 24-bit .bmps don't display
correctly from a winelib application on a big-endian sparc host when
displaying on a little-endian intel PC. In this case, the image is
garbled, with most of the colors being wrong and a pattern of vertical
stripes over the imag
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 l
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
byte
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 t
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 w
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 por
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 o
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 things?
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! Thos
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
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
using)
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 attach
mportant changes fixing real bugs.
For now, I'd suggest getting them from:
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
workin
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
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 work
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 allocat
Daniel Kegel wrote:
[EMAIL PROTECTED] wrote:
http://bugs.winehq.org/show_bug.cgi?id=2609
[Proposed fix:]
struct rlimit address_limits;
int required_address_space = 1024 * 1024 * 1400; /* 1400M */
getrlimit(RLIMIT_AS, &address_limits);
if (address_limits.rlim_max < required_addre
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 a
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
Francois Gouget wrote:
> On Wed, 4 May 2005, Ivan Leo Puoti wrote:
>> Videos will appear here
>> http://wineconf.geldorp.nl/
> Should they be set up as a BitTorrent?
> I have a good internet connection so I don't mind downloading large
> files but I'm just concerned about the load on your server.
>
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 realloc
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
i
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 whether
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 "norma
"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
"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 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 se
I just ran across an evil little bug in the WINSPOOL_GetPrinter_2 function.
It looks like this type of bug could be hiding in other API functions too.
It causes a segmentation fault because of an unaligned access on Solaris
(sparc).
This function packs a PRINTER_INFO_2 structure and all of its
var
"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 th
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
"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
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
"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 c
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 t
42 matches
Mail list logo
