Alexandre Julliard <julliard(a)winehq.com> wrote:
> Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes:
>
> > Appended program uses CxxFrameHandler and crashes in wine with builtin
> > msvcrt, but not with native. Compile as Release version and include the
> MFC
> > dll. Can somebody compile for Alexandre? Alexandre, is this a start or do
> > you need something complete?
>
> That's a start, yes, thanks. I'll need a more complete example with
> nested try blocks, destructors all over the place, typed exceptions,
> etc. to make sure I understand all the compiler internal structures;
> but I can at least try to make that simple case not crash...
Although this may duplicate effort, I am familiar with several strange
combinations of exception handling that I know work with Visual C++ 6.0; I
will put them a test program for you. You can never have too many test
programs, right?
Am Mit, 2002-09-25 um 00.55 schrieb Andrew Bartlett:
> Firstly, it's good to see that winbind is starting to get some interest
> :-)
I have been ignoring it so far, but in the context of the current
inquiries I tried it out and was impressed :-)
> Secondly, don't fall into the trap squid (with my encouragement I might
> add...) fell into - don't use the winbind pipe directly. The winbind
> API is an internal Samba API, and can change without warning.
Hmm - what other APIs are there?
The only libraries that are accessible are nss_winbind and pam_winbind.
Those two already carry us a long way, BUT ...
I started thinking about other options when I found the "wbinfo -n"
call. AFAIK there is no way to obtain equivalent info through PAM/NSS,
simply because these APIs have no concept of a SID. Obviously apart from
the SID there is a lot more information to gather from a PDC. I have not
digged deeply enough into this to be able to enumerate everything, but
think of the different GetUserInfo() calls on NT.
libsmbclient can't be used by wine because it's GPL. And even if we
could use it, it's headers only define calls related to shares and
printing, which is not what I'm currently aiming at.
> As to unicode, I
> have designated one call as being in utf8, to cope with external
> interaction, so it's possible things can happen here.
What matters to wine is that if a call goes like this:
Windows app <-> wine <-> PAM or other API <-> winbind <-> RPC <-> Windows server,
we must ensure that the Unicode string wine receives from the app
reaches the server ungarbled.
Martin
--
Martin Wilck Phone: +49 5251 8 15113
Fujitsu Siemens Computers Fax: +49 5251 8 20409
Heinz-Nixdorf-Ring 1 mailto:[email protected]
D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
Anyone planning on looking into this in the near term? It could be fixed relatively easily in MZ_Exec() if I knew of some way to get the environment variables and their values. I'm not sure if the same kind of fix would apply to fixing CreateProcess().
Chris
>
> From: "Eric POUECH" <Eric.Pouech(a)wanadoo.fr>
> Date: 2002/09/24 Tue PM 04:48:24 EDT
> To: <cmorgan(a)alum.wpi.edu>, <wine-devel(a)winehq.com>
> Subject: Re: another MZ_Exec() problem...
>
> > Inside of MZ_Exec() I call out to CreateProcessA() if the executable is PE. I've set the lpEnvironment parameter of CreateProcessA() to null to have it inherit the environment of the caller but this isn't working correctly. The path and other environment variables aren't being inherited. Ideas on how to either get CreateProcessA() to inherit properly or where I can find the environment settings? I noticed the env_ptr in the parmeter block but I'm unsure if this is what I'm looking for or where to find more information about it.
> moreover, explicit env heritage (ie passed in CreateProcess) is currently bugged
> A+
>
>
>
Szombathelyi György <gyurco(a)freemail.hu> writes:
> Here's my winaspi patches that uses libscg for the scsi transport layer. It
> statically links libscg, which is the part of the cdrtools package (all
> distribution have it).
As far as I can tell libscg is under the GPL, not the LGPL. So we
cannot use it in Wine.
--
Alexandre Julliard
julliard(a)winehq.com
Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> writes:
> Changelog:
> dlls/comctrl32/propsheet.c:
> Hack around write protected in-memory resources
Please let's not add more hacks on top of the existing ones. This
thing needs to be fixed properly once and for all.
--
Alexandre Julliard
julliard(a)winehq.com
Hi,
I noticed recently that Wine was able to do anti-aliasing for font sizes >16
although my Gnome 2 looked nice with anti-aliasing of <16. I started to
look why Wine apps were only anti-aliased for >16, and I came across this:
--- dlls/x11drv/xrender.c.orig 2002-09-29 12:56:27.000000000 +0200
+++ dlls/x11drv/xrender.c 2002-09-29 12:56:56.000000000 +0200
@@ -322,7 +322,7 @@
assert(entry->nrealized == 0);
- if(antialias && abs(plfsz->lf.lfHeight * plfsz->xform.eM22) > 16) {
+ if(antialias && abs(plfsz->lf.lfHeight * plfsz->xform.eM22) > 8) {
pf.depth = 8;
pf.direct.alphaMask = 0xff;
} else {
When I changed this, my Notes was much nicer to work with. I presume there
is a reason why anti-aliasing was off, but I would reconsider that
decision. You can look for yourself on these 2 screenshots:
http://dag.wieers.com/Screenshot-2.pnghttp://dag.wieers.com/Screenshot-3.png
Especially look at the widgets.
Thanks for your feedback, (please Cc: because I'm not subscribed)
-- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ --
«Any errors in spelling, tact or fact are transmission errors»
> Look reasonable?
No. Command tail is not null terminated so you
cannot use strlen. DOS exec function "load and exec"
is synchronous so you should return to caller only
after created process has finished. In addition
to hFile lead found by Ove Kaaven, you are leaking
handles in PROCESS_INFORMATION. Using fixed size
buffer for full command line without sanity checks
is a bad idea and will cause problems sooner or later.
And, finally, you are ignoring long command lines
from DOS program stored in CMDLINE environment
variable. (I have already exchanged private email with
Chris Morgan about this; DOS programs can be passed
command tails longer than 126 characters using CMDLINE
environment variable. Similarly, DOS programs may pass
long command lines to programs they execute.)
--
Jukka Heinonen <http://www.iki.fi/jhei/>
Hello,
the conversion of HICON to void* seems to be a hard one ... while trying
to do that i found that msdn dosn't know anything about
include/cursoricon.h, it seems to be an internal header and therefor
should go to dlls/user/ or at least to include/wine. I could do a patch
for that.
An other question: in windows/cursoricon.c there are some internal
functions, that are using a HGLOBAL for a HICON or HCURSOR. I would
change that to HICON because HCURSOR is compatible to HICON and HGLOBAL
seems too generic (HGLOBAL is a HANDLE and thus wont catch any handle
conflicts).
bye
michael
--
Michael Stefaniuc Tel.: +49-711-96437-199
System Administration Fax.: +49-711-96437-111
Red Hat GmbH Email: mstefani(a)redhat.com
Hauptstaetterstr. 58 http://www.redhat.de/
D-70178 Stuttgart
jau(a)iki.fi (Jukka A. Ukkonen) writes:
> I complained about this matter a week or two ago, and got
> the pretty asocial answer: "This list is for patches only."
> So, no ideas, no discussion.
Discussions go to wine-devel. You can also send patches to wine-devel
if you want to discuss them.
> I have also an imgact_wine() function as an extension for
> FreeBSD kernel to recognise win/dos binaries and start wine
> (or any other windows emulator selectable by a sysctl()
> variable), if the kernel has been compiled with the USER_LDT
> option.
If you are doing the kernel part too, why don't you pass the
interpreter as argv[0]? That's the way binfmt_misc does it under
Linux, and it's a lot more useful since you can use anything you want
as interpreter, you are not limited to specially modified apps.
--
Alexandre Julliard
julliard(a)winehq.com