wine-devel December 2002

wine-devel@winehq.org

132 participants
377 discussions

"not enough space in GDI heap" / forking vstlib programs
by Kjetil S. Matheussen 01 Dec '02

01 Dec '02

Hello, as I just announced I'm developing a vst-server, that loads and runs windows vst plugins. But after loading and unloading a lot of plugins, I get lots of "err:local:LOCAL_GetBlock not enough space in GDI heap 01f7 for 24 bytes" errors. I understand that the cause of this error is caused by a memory leak in a windows program. However, in the vst-server, there is no way to control memory leaks in the plug-ins, as those are made by various groups and persons. So is there a way around this error. Doing a fork for each new plug-in perhaps? Is that safe? I want to do that also to avoid having a plug-in crash the vst-server. --

2 2

RE: [RFC] Wine headers
by Patrik Stridvall 01 Dec '02

01 Dec '02

> On November 29, 2002 01:43 pm, Patrik Stridvall wrote: > > On 64 bit platforms we can never get 100% Win32 source compabillity > > because of compiler problems. If fact we can't get 100% > Win64 support > > either for the same reasons so I guess Wine on 64-bit platforms will > > be some kind of pseudo mode. > > Why are you saying that? What about the current difference between the > sizeof(wchar_t), it wasn't such a big deal. Can't we have other flags > in the great tradition of -fwchar-short? It is a little worse that that. The C programming langauge doesn't really specify the sizes of the various integer types. It it up to the ABI. In Win32 the only really problematic difference I the one you meantion above ie the size(wchar_t) problem. It can be "solved" as specified above with -fwchar-short. The price is that you can't call the C library "wchar" functions or for that matter any library functions that depend of wchar. Not that big deal though. In the Win64 ABI Microsoft in it infinity "wisdom" has choosen the type long to be 32 bit instead of 64 bit like in most (all?) Unix API on 64 bit platforms. The Microsoft Win64 choice is called LLP64. That is long long and pointers are 64 bit. The Unix64 choice is called LP64. That is long and pointers are 64 bits. So this means that if we add an option similar to -fwchar-short, say -flong-int or -flong-32bit or whatever we can call we can't call the any library on the platform since it would could ABI problems. :-) So that is why we "never" will support 100% Win64 source compatibillity on 64bit platforms. We can (and presumably) will support a LP64 variant of Win64 but it won't be 100% source compatible.

2 1

RE: [RFC] Wine headers
by Patrik Stridvall 01 Dec '02

01 Dec '02

> The only thing I don't like in my proposal is the win32 name, namely > the 32. I guess Win64 will go in the same namespace, as well as win16. > This is confusing. What about winxx or even better winapi? Windows uses the same header files for both Win32 and Win64. It is Win32 if _WIN32 is defined and Win64 if _WIN64 is defined. On 64 bit platforms we can never get 100% Win32 source compabillity because of compiler problems. If fact we can't get 100% Win64 support either for the same reasons so I guess Wine on 64-bit platforms will be some kind of pseudo mode. So we probably should have the same include directory for Win32 and Win64. As for the name well I think I like "windows" best. > > > plus a bunch of other things (like making it easy to use other > > > headers for the Win32 API, etc). And best of all, it seems to > > > be easily implementable, no? > > > > "mv" is your friend however the CVS versioning doesn't like > it though... > > We don't have to move anything in the tree, just modify where > we install > stuff. Of course, this means that you will not be able to use > your tree > include files in all cases, but I think it's good as a start. Perhaps.

2 1

Fwd: Re: [putty]Winelib support + patch
by Dimitrie O. Paun 01 Dec '02

01 Dec '02

This is a very valid question. Alexandre, do we support generating regular executables for the apps we don't necessarily need the wrapper stuff for initialization purposes? ---------- Forwarded Message ---------- Subject: Re: [putty]Winelib support + patch Date: Mon, 25 Nov 2002 10:17:18 +0000 From: Simon Tatham <anakin(a)pobox.com> To: dpaun(a)rogers.com Cc: putty(a)projects.tartarus.org "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > FYI: the way it works is that instead of compiling the app as an > executable, we generate a .so that's loaded by wine. Now, > wine is simply a one page program that loads the libraries > that the program expects (like kernel, gdi, user), and then > loads the program itself. This is required by some apps which > have C++ static initializers, which expect to be able to call > Win32 functions, and they do so before we get a chance to > initialize them, if we were to have the app load the libs. OK, I've now read the docs and I understand this a bit better now. My next awkward question is: I can see that this is necessary for some apps which have C++ static initialisers, or which load libraries that have C++ static initialisers, but why does that mean it's necessary for PuTTY? PuTTY contains no C++, and as far as I know it uses no libraries _except_ standard Win32 API ones. Surely it should be possible _for these particular applications_ to compile them as standalone binaries? Or does Winelib currently only support doing things the inconvenient way? Cheers, Simon -- Simon Tatham "The distinction between the enlightened and the <anakin(a)pobox.com> terminally confused is only apparent to the latter." ------------------------------------------------------- -- Dimi.

3 5

Texture problems under Wine - more info
by David D. Hagood 01 Dec '02

01 Dec '02

As I've stated in previous mailings, I've started having problems getting HalfLife to run under Wine - while at one time I was able to complete all of HalfLife - Opposing Force running under Wine, now I am unable to get the textures to render correctly. I have more information - I subscribed to Transgaming, downloaded the current WineX, installed HalfLife under it, and it works correctly. So, that would tend to exonerate my libGL, my system, and HalfLife, and leave only Wine as the suspect in the problem. So, the question is "What is the difference between the WineX OpenGL library and the Wine OpenGL library?" I hope to do more research on this over the weekend, but thought I'd post this now in case it rang any bells with somebody else.

2 2

SetWindowHookEx
by steve.lustbader＠philips.com 01 Dec '02

01 Dec '02

My app uses SetWindowHookEx to install a WH_KEYBOARD_LL hook. Currently, the wine implementation tells me "fixme:hook:set_windows_hook system hook WH_KEYBOARD_LL won't work right" when I try to use it. I'd like to implement this so I can get my app to run, but I'm not sure where to start, since I don't know why it "won't work right." Any hints/suggestions? -Steve

3 5

Compilation with -DSTRICT
by Thomas Wickline 01 Dec '02

01 Dec '02

Hello, I just want to say Thank you to all the people who put work into the Compilation with -DSTRICT Tom

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2002