Andreas Mohr wrote:
On Wed, May 17, 2000 at 10:29:26AM -0400, michael cardenas wrote:
You could just use abiword, or staroffice, or applixware...
Hmm ???
Obviously this isn't *at all* what he wants...
He's trying to find a way to automatically build .doc files within scripts,
I guess.
On Wed, 17 May 2000, Heiko Nardmann wrote:
Is it possible to use the libwine, maybe some Word DLLs found on an NT
system and to create
a program using both which can create Word documents? Or does no Word
API exist for such a task?
I don't want to start Wine to input text in Word itself
Heiko Nardmann wrote:
But I am not sure whether I could link the Wine lib to my Linux program,
dynamically open Windows DLLs and use functions found within?!
Yes you can, talk to the developer of the XMMS plugin for .VQF files. Check the
list archives.
-Dave
On Wed, May 17, 2000 at 09:20:57PM +0200, Peter Bortas wrote:
I'm planning to spend a few hours debugging a dsound problem of an app
this week, but when I updated from CVS a got a what I suspect is a
ddraw problem earlier in the execution-path instead. It was some time
since I last updated,
In message "Re: ddraw problem?",
"Lionel Ulmer" [EMAIL PROTECTED] writes:
snip
fixme:ddraw:Xlib_IDirectDraw2Impl_QueryInterface (0x4040cba4):interface for IID
{6aae1ec1-662a-11d0-889d-00aa00bbb76a} _NOT_ found!
As far as I can tell from the log, the application is crashing in it's
own code
After some searching, I have found where this app (Wordvu) was hosed; it was when
a fix was done in InitTask16 ; I have found that before the change Wine initialized
the
stack to :
min: 8150
bottom :81b4
top: 4500
After the change
min 814e
bottom 814e
top 4530
Applying this patch to
He's trying to find a way to automatically build .doc files within scripts,
I guess.
I don't really believe Microsoft built that capability into Word.
I don't know whether Word has a real API.
Word offers a object modell over DCOM. But I don't think DCOM is
working within wine or - without
Peter Bortas [EMAIL PROTECTED] writes:
I haven't changed my setup since then, and my config.cache say
ac_cv_header_GL_gl_h=${ac_cv_header_GL_gl_h='yes'}
ac_cv_header_GL_glext_h=${ac_cv_header_GL_glext_h='no'}
ac_cv_header_GL_glx_h=${ac_cv_header_GL_glx_h='yes'}
, but this is just guessing
First, I am running wine 2130. Is there seomthing newer that may fix
the following problem?
The problem is with Windows type dialogs that have tabs on them. While
this works fine under Windows, Wine seems to have a problem.
I have a dialog that has various controls on 5 tabs (dialogs).
Hallo,
after correcting the DOSFS_DoGetFullPathName function, wordview.exe
(word 6 ) still reports that it can't open the file. This boild down
to a call to STGOPENSTORAGE:
Call STORAGE.3: STGOPENSTORAGE(0x073f7460
Call STORAGE.3: STGOPENSTORAGE(0x073f7460
"H:\\tmp\\win95\\wv6\\license.doc",:,0x00040040,:,0x,073f:74f6)
ret=0
43f:8329 ds=073f
trace:ole:StgOpenStorage16
(H:\tmp\win95\wv6\license.doc,(nil),0x00040040,(nil),0,0x40ec192e)
trace:file:CreateFileA
Gerard Patel wrote:
/* Initialize the INSTANCEDATA structure */
pinstance = (INSTANCEDATA *)PTR_SEG_OFF_TO_LIN(CURRENT_DS, 0);
pinstance-stackmin= OFFSETOF( pTask-teb-cur_stack );
-pinstance-stackbottom = pinstance-stackmin; /* yup, that's right. Confused me
too. */
At 10:44 PM 5/18/00 +0200, you wrote:
Ah! I think I see the problem: the pTask-teb-cur_stack points to the
16-bit stack *after* the complete 16-32 thunking stack frame was pushed.
The stackmin/stackbottom fields, however, are supposed to contain the
stack pointer at the point of *call* to
After reading configure.in I see that glext.h is a necessity, while it
wasn't some months ago. I will upgrade Mesa to fix this. Maybe I
should go all the way and get XFree 4.0 while I'm at it?
Well, 'glext.h' is part of the Linux OpenGL ABI version 1.0 (or it
will be as soon as the
I have made a small hack (attached) that tries to adapt my Solaris C
patch to this problem. I havn't for various reason been able to
test it so it might (read: will) not work, but it is better than
nothing I hope.
OK, some comments on the patch :
1) you seem to have generated your
I have made a small hack (attached) that tries to adapt my Solaris C
patch to this problem. I havn't for various reason been able to
test it so it might (read: will) not work, but it is better than
nothing I hope.
OK, some comments on the patch :
1) you seem to have generated your
Patrik Stridvall wrote:
+print '#stdcall_name ":\n"' . " \\\n";=0A=
+print '"\tmovl (%esp), %eax\n"' . " \\\n";=0A=
+print '"\tleal " #argsize "(%esp), %edx\n"' . " \\\n";=0A=
+print '"." #stdcall_name ":\n"' . " \\\n";=0A=
+print '"\tmovl (%edx), %ecx\n"' . "
Patrik Stridvall wrote:
+print '#stdcall_name ":\n"' . " \\\n";=0A=
+print '"\tmovl (%esp), %eax\n"' . " \\\n";=0A=
+print '"\tleal " #argsize "(%esp), %edx\n"' . " \\\n";=0A=
+print '"." #stdcall_name ":\n"' . " \\\n";=0A=
+print '"\tmovl (%edx), %ecx\n"' . "
Well, it seems to me that everyone was mostly
in favor of Wine 1.0.
So, I tried to boil down all of the comments
and create a 'Wine 1.0 project plan'.
I've included it inline below, and I'd appreciate comments.
Thanks,
Jeremy
---
Wine 1.0Task List
19 matches
Mail list logo
