On Wed, 12 Nov 2003 13:01:01 -0600, you wrote:
is this a bug, or a configuration problem?
This has already been fixed in cvs a couple of weeks ago.
Rein.
--
Rein Klazes
[EMAIL PROTECTED]
On Wed, 12 Nov 2003 18:27:55 +0100, Sir Uwe Bonnes scribed thus:
With VB6/5, most errors happen around Ole/Com, as wine still needs a long
way in that area. Running with the appropriate native DLLs may circumvent
the problem. For migrating, using the native dlls is not a (legal) option
On Tue, 11 Nov 2003 18:15:09 -0800, Sir Dan Kegel scribed thus:
That question, plus all the 'advantages' you list,
indicate that you do indeed intend it to replace
wine-users, at least for some users.
Yes, for those users for whom it's clearly not working (otherwise why are
there so many wine
On Wed, 12 Nov 2003 09:20:13 -0800, Sir Philip Staiger scribed thus:
A general question: Dogwaffle uses COM, ActiveX communication channels (I
don't know much details). Anybody have a feeling if that's a no-no under
Wine?
ActiveX and COM are mostly supported under Wine, if it doesn't work you
Useally forums have an option to notify you when replies were added to a
thread you replied to.
Roderick
On Thursday 13 November 2003 11:52, Shachar Shemesh wrote:
Mike Hearn wrote:
On Tue, 11 Nov 2003 18:15:09 -0800, Sir Dan Kegel scribed thus:
A web interface that let you post to the
With yesterday cvs update, whch adds a glibc-threading detection,
wine doesnt load a _Windows_ program anymore.
Using the RedHat rpm Yarrow kernel, I get :
err:virtual:map_image Standard load address for a Win32 program
(0x0040) not available - security-patched kernel ?
wine: could not load
Hi All,
I somewhat impetuously requested a table for the Wine Project
at the LinuxWorld New York expo, without really thinking
if anyone could man the table.
We'll have a CodeWeavers specific area in another part
of the expo, so we won't really be able to provide
a lot of help (and won't need
On Thu, Nov 13, 2003 at 04:01:43AM -0800, Jon Griffiths wrote:
Hi Marcus,
Can you please explain why VARIANT_ValidateType rejects for
instance VT_SAFEARRAY
variants (and more) with DISP_E_BADVARTYPE?
Why does it handle the whole range VT_HRESULT - VT_CF as invalid
(except
Hi Marcus,
Can you please explain why VARIANT_ValidateType rejects for
instance VT_SAFEARRAY
variants (and more) with DISP_E_BADVARTYPE?
Why does it handle the whole range VT_HRESULT - VT_CF as invalid
(except VT_RECORD) ?
We got one InstallShield regression from this patch (where it
I don't think we want to switch the global flag on every int21 call,
that's fairly ugly IMO. If int21 needs OEM then it should use OEM
explicitly, which is pretty much what it's doing already AFAICS. I see
no reason to change that.
I do think it's as ugly as duplicating all the A = W calls from
Rand Batchelder wrote:
not much
Ok, done. Though it is curious that the administrivia filter didn't
catch this.
Arg! Forgot something basic; January 21-23, 2004,
at Javitz center in New York city.
Jer
On Thu, 2003-11-13 at 16:30, Jeremy White wrote:
Hi All,
I somewhat impetuously requested a table for the Wine Project
at the LinuxWorld New York expo, without really thinking
if anyone could man the
Eric Pouech [EMAIL PROTECTED] wrote:
+static void INT21_ConvertFindDataAtoW(WIN32_FIND_DATAA *dataA,
+ const WIN32_FIND_DATAW *dataW)
+{
+dataA-dwFileAttributes = dataW-dwFileAttributes;
+dataA-ftCreationTime = dataW-ftCreationTime;
+
13 matches
Mail list logo