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
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
I have posted my question for compiling Wine in solaris x86 for 2 weeks,
seems no anybody even has a bit interest.
Do you guys hate solaris? :)
I checked almost all the documents and faq, except it mentioned wine works
with Solaris, there almost have no other info for it at all.
Does anybody has even a suggestion for me? pls don't tell me nuke my
solaris. :)
>>>>> "Medland," == Medland, Bill <Bill.Medland(a)accpac.com> writes:
Medland,> I am not very comfortable with this one but strange as it may
Medland,> seem it solves the problem. I'd love to know why.
Medland,> <<diff13.txt>> Bill Medland (medbi01(a)accpac.com) Prevents
Medland,> excessive clipping in SysListView32.
Medland,>
Medland,>-static inline int perfect_graphics(void)
Medland,>+static int perfect_graphics(void)
Medland,> {
Medland,> static int perfect = -1;
Medland,> if (perfect == -1)
Medland,>
Some C-Expert is requested here, but I suspect that in the old function the
variable "perfect" was created in every instantiation of the
"perfect_graphics" inlined function. Could you perhaps try to declare the
"perfect" outside the inlined function, like
static int perfect = -1;
static inline int perfect_graphics(void)
Bye
--
Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Getting back to what we are and are not allowed to do..
Suppose I am looking at a low-level function that I believe is only
75%-complete (the most important 75% of course and no disrespect meant to
those who have got it that far).
One of the problems with it is it is not totally clear EXACTLY what the
function should do in some of its more esoteric modes.
To me the first task is to define what it should do and that should be part
of the documentation of the function.
The particular function currently does not have any true documentation
within the code; the best documentation of what it does is the code itself,
and the best documentation of what it should do is the MSDN description of
the function.
1. Should the function be completely defined in its header in the source
code (which will probably make the header twice as large as the function)
or should the details be put somewhere else.
2. Are we walking into copyright danger if the Wine documentation of the
function is clearly based on the MSDN documentation, even if we acknowledge
that.
3. Are we interested in that level of documentation?
Bill
David Hagood <wowbagger(a)sktc.net> writes:
> To be done: the file descriptor is never closed under normal
> circumstances - this might be a problem if a Wine app is opened and
> accesses the stick, as the file descriptor will be open until that
> process terminates. If this is viewed as a problem, it would be a simple
> matter to add a device close function to the Wine driver to close the FD.
Shouldn't this be done in the driver DRV_OPEN/DRV_CLOSE calls then?
Any joystick experts out there?
(BTW please use diff -u to generate patches, the default diff format
is unreadable).
--
Alexandre Julliard
julliard(a)winehq.com
Jukka Heinonen <jhei(a)iki.fi> writes:
> Storing old windows procedure in struct x11drv_win_data
> would remove the worst race, but unless window
> procedure update is atomic, it would not remove
> all races.
Since you have the window locked when changing the wnd proc the update
will be atomic. The only problem I see is that your wnd proc might get
called to process some other message, but you can solve this by having
it chain to the previous wnd proc for all messages except the special
one.
--
Alexandre Julliard
julliard(a)winehq.com
Now I finally made a wine , :)
But I can't get any program to excute so far, mostly It is like
bash-2.03# wine --winver win95 sol.exe
err:seh:UnhandledExceptionFilter Couldn't start debugger (debugger/winedbg
134639312 24)
(2)
Read the Wine Developers Guide on how to set up winedbg or another debugger
or
bash-2.03# wine --winver win98 icq2000b.exe
err:win32:do_relocations Standard load address for a Win32 program not
available -
patched kernel ?
err:win32:do_relocations FATAL: Need to relocate
F:\export\home\ericw\system\icq2000b.exe, but no relocation records present
(stripped
during link). Try to run that file directly !
wine: can't exec 'icq2000b.exe': error=21
This wine seems taste not good, :)
Francois Gouget wrote:
> On Thu, 26 Jul 2001, EriK W wrote:
>
> > > What does not work? Do you have unicode/libwine_unicode.so or not?
> > > Does the following command run or does it say it cannot find
> > > libwine_unicode.so?
> > >
> > I does have the libwine_unicode.so
> > but it just don't go to ~unicode directory to search for it, it always
> > report " can't find it in /usr/local/lib" I don't know why, I am using
bash,
> > so I just simply copied libwine_unicode.so over to make it happy.
>
> I was wondering if it was the shell not exporting the environment
> variable or something. Since you're using bash it should be all fine.
> So you have to figure out why setting LD_LIBRARY_PATH does not work.
> It's supposed to work. I'm 99.9% sure I did use it on Sparc Solaris so I
> really don't see why it would not work on Solaris x86. Plus
> LD_LIBRARY_PATH is such an important thing that it would be very
> surprising if it really did not work and nothing else was broken in your
> system.
>
> Did you try specifying an absolute path like:
> LD_LIBRARY_PATH=/export/home/system/wine-20010629/unicode
./tools/winebuild/winebuild
>
> What does 'echo $LD_LIBRARY_PATH' normally say? Is it empty?
>
> [...]
> > take it out?
> > Can I do that by commenting "
> > LIBPROGRAMS = \
> > debugger/winedbg" ?
>
> The following patch should do that nicely:
>
> --- cut here ---
> Index: Makefile.in
> ===================================================================
> RCS file: /home/wine/wine/debugger/Makefile.in,v
> retrieving revision 1.24
> diff -u -r1.24 Makefile.in
> --- Makefile.in 2000/12/29 05:38:00 1.24
> +++ Makefile.in 2001/07/27 01:39:15
> @@ -3,7 +3,7 @@
> TOPOBJDIR = ..
> SRCDIR = @srcdir@
> VPATH = @srcdir@
> -MODULE = winedbg
> +MODULE = #winedbg
>
> C_SRCS = \
> break.c \
> --- Makefile.orig Thu Jul 26 19:03:36 2001
> +++ Makefile Thu Jul 26 19:00:53 2001
> @@ -3,7 +3,7 @@
> TOPSRCDIR = ..
> TOPOBJDIR = ..
> SRCDIR = .
> -MODULE = winedbg
> +MODULE = #winedbg
>
> C_SRCS = \
> break.c \
> --- cut here ---
>
> --
> Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/
> Broadcast message : fin du monde dans cinq minutes, repentez vous !
> It also puts the 'make_opengl' script in line with the latest
> modification
> to the spec file. It also changes the OPENGL32.@ to OPENGL.@
> as per Patrik's
> modifications in 'make_opengl'.
Arrgghhh! I just saw that I didn't do the same change in the script
as in the .c files (I didn't run the script, since it worked badly
last time I tried with my OpenGL files). Braino. :-(
It should of course be OPENGL32.@ not OPENGL.@.
The .c files was correct as they were.
Sorry to cause you problems but can you fix the script and
rerun on your OpenGL files and resubmit.
> PS: god I hate Perl... I may well rewrite 'make_opengl' in
> Python one of
> these days :-)
Whats wrong with Perl?
I write applications sometimes in Perl and sometimes in Python,
and I like them both and a dislike somethings about each
language as well.
Of course Perl is a little more difficult to learn but still.
PS. You will se one of the advantages of Perl if you add
use strict;
at the top of the script. Of course after that you will have to
declare all variable to it keeps the number of bugs down.
> > In short, please apply it, they facillitates using the
> > winapi tools alot and might make more people actually
> > use them. They don't hurt anything.
>
> The problem is if we make it part of the default make install all Wine
> distributions will include these non-functional (from the user POV)
> scripts, and I don't think this is a good idea.
That is true.
> So I have applied it
> but it doesn't run by default; developers who want it should run make
> install in the tools/winapi directory.
Ah, of course. Good idea. Thanks.
This brings to mind the fact that three different kinds of "users":
1. Ordinary users
2. Wine/Winelib developers
3. Winelib application developers
that need different kinds of tools installed.
Not that I have any good solution to the problem.
And not something that really is a problem either.
Is was just something that occured to me.
Oh well. Never mind.
