Does anybody have complete instructions on how to set up a printer to
use in wine? I have tried all of the suggestions with add entries to
the wine.conf file, using the internal driver, etc. I cannot seem to
get wine to see any printers. I use lprng through a print server, so I
do not have any local printers attached. Can anyone help??
Richard
Does anybody have complete instructions on how to set up a printer to
use in wine? I have tried all of the suggestions with add entries to
the wine.conf file, using the internal driver, etc. I cannot seem to
get wine to see any printers. I use lprng through a print server, so I
do not have any local printers attached. Can anyone help??
Richard
The AbiWord win32 0.9 problems I described recently on
wine-users with Codeweavers Preview 4 also happen
with the latest Wine built from CVS this afternoon.
These problems don't happen when run on Windows, nor
when running the native Linux version; they therefore appear
to be Wine bugs.
Details at http://www.kegel.com/wine/abiword0.9/readme.html
I stand ready and willing to apply and test patches,
but might not have time to write any fixes myself.
Thanks,
Dan
--
"I have seen the future, and it licks itself clean." -- Bucky Katt
On Tue, Aug 07, 2001 at 04:15:41PM +0200, Andreas Mohr wrote:
> Hi all,
>
> this patch implements *names* for the most important critical sections.
>
> I simply grew tired of constantly having to look up the crst addresses
> in winedbg whenever there was some crst timeout.
> Yeah, I know, that patch is slightly weird/dirty, but it's useful.
Yup, this patch is weird:
> + TRACE("#1\n");
> + TRACE("#2: %p\n", obj);
Alexandre, please apply it without this crap ;-)
(hmm, I really thought I had properly checked it)
--
Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany
Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/
[Notes 5.0.8]
> The only error message the installer came up with was a dialog saying
> "AddFolderIcon" failed.
The same here.
> I had also understood that there was now a facility to add programs that
> would have installed themselves into the Windows startup menu into the KDE
> menu structure. I am running KDE 2.2 from CVS if it matters. But nothing
> appeared. Had I understood wrong, or do I need to try to do some
> debugging?
Maybe not for all the InstallShield versions: it worked for me for the game
"I-War" (quite old... DirectX 5 I think), with KDE 2.1
Or it could be that the installer crash doesn't help in getting the icon
loaded... :-)
I didn't had time to look into this feature.
Ciao,
Roberto.
I was thinking of ways to get the CLSCTX_LOCAL_SERVER option working in
wine. The only program that uses it , that I know of, is installshield
v6 .. I pretty sure some other people are working on this, but I don't
know that status. (Anyone care to update me?)
There is another problem. It's with the TypeLib information in the
IKernel.exe that comes with InstallShield v6. The TypeLib information is
encoded somehow, any ideas? I was able to get around that problem
because installshield also looks for type information in "ikernel.tlb" .
So I was able to create a .tlb that worked. I also used the reaktivate
typelib patch so the typelib info gets put into the registry.
So the way I understand it is that when CoGetClassObject is called Wine
is suppose to , in this case, execute IKernel.exe . Then IKernel.exe
will CoRegisterClassObject on all needed objects .. One problem is that
the registered class object list isn't shared between the two processes,
so we would need to move that list into the wine server (Right?) .. Then
we would also need to send an instance of the class object to the Wine
server (Yeah??) .. Following that road seems to lead to some messy
address translations for DLL's and whatever else..
Since we have complete control over how IKernel.exe is run, how would
we get the two processes to share memory? Maybe have IKernel.exe execute
in a thread? IKernel.exe doesn't do anything but register it's class
objects .. Would it be possible to treat IKernel.exe as a DLL then run
CoRegisterClassObject for it?
Daniel Walker
Curiously (on the subject of InstallSheild) I have just successfully
installed the latest (5.0.8) Lotus Notes client on a wine system (latest
tarball) and the new Lotus installer is InstallSheild based. It ran
perfectly EXCEPT that the program would not terminate. The Lotus installer
takes over the whole screen, and that went away, but wine never returned to
the command line. As far as I could see there were no messages about locks
or anything.
The only error message the installer came up with was a dialog saying
"AddFolderIcon" failed.
I had also understood that there was now a facility to add programs that
would have installed themselves into the Windows startup menu into the KDE
menu structure. I am running KDE 2.2 from CVS if it matters. But nothing
appeared. Had I understood wrong, or do I need to try to do some
debugging?
Ove Kaaven <ovehk(a)ping.uio.no> on 08/07/2001 07:55:41 AM
To: Rein Klazes <rklazes(a)xs4all.nl>
cc: wine-devel(a)winehq.com (bcc: David Goodenough/DGA/GB)
Subject: Re: CoGetClassObject
On Tue, 7 Aug 2001, Rein Klazes wrote:
> On Tue, 7 Aug 2001 01:12:34 +0200 (CEST), you wrote:
>
>
> >
> > > It couldn't get it from the ikernel.exe because I think
> > > it's encoded somehow (unicode, MultiByte??).
> >
> > It doesn't look encoded, it's just different (it's most likely what is
> > boasted as the "Typelib 2 Format"). Win2000's stdole32.tlb also uses
this
> > new format (it has a "SLTG" signature instead of the old "MSFT").
>
>
> SLTG is the old format, MSFT came later. Wine can (natively) only read
> MSFT.
Allright, but the most important question remains: who will volunteer to
reverse engineer these SLTG typelibs and make Wine able to read them, so I
can concentrate on the actual COM marshaling stuff (which is pretty hard
enough as it is), so we can finally get those @#&% InstallShields up?
Aric Stewart <aric(a)codeweavers.com> writes:
> A full fix would be to make sure we never call the paint function
> directly. However the only time this seems to actually cause a crash is
> with owner drawn. This patch corrected the problem with owner drawn so
> that we do not have to retest everything with buttons.
This seems to defeat the purpose of having the ODA_* constants. Would
it also fix your problem to only do the PAINT_BUTTON when the window
is visible?
--
Alexandre Julliard
julliard(a)winehq.com
Ladislav Sladecek <lsla(a)post.cz> writes:
> If you run the binary in the Windows, you will see two properly sized
> red rectangles on a white background. If you run the same binary in
> Wine, you will see only one large red child but no white parent
> background. If either the CS_PARENTDC or WS_CLIPSIBLINGS gets removed
> from my example, both Windows and Wine give identical results.
Yes, there were a number of problems with the flags handling in
GetDCEx. I think the behavior with the current CVS should now be
correct in all cases; please give it a try.
--
Alexandre Julliard
julliard(a)winehq.com
FIXME:pthread_rwlock_rdlock
FIXME:pthread_rwlock_unlock
what's this, what's causing it and what needs fixing (I'll give it a
look if it's needed) or is it just an old error that dosn't really need
fixing (I can run almost everything I want to and the all show this
error) just intersted
Rob
