> No, if it's an LPSTR it has to point to an ASCII string.
I mean, when im assigning pszProvName is it acceptable to convert
provname from unicode to ascii and then assign provname to
pszProvName?
/* convert provname to ascii */
pProv->pVTable->pszProvName = provNameA;
On Thu, 02 Sep 2004 19:14:
On Wednesday 01 September 2004 11:22 pm, you wrote:
> On Wed, 1 Sep 2004, Patrick Goupell wrote:
> > The bug description mentions looking at the *.c and *.cpp source looking
> > for main, WinMain and DllMain. Looking at the *.h source and looking
> > for #pragma comment(lib, 'foo.lib').
> >
> > I
James Hawkins <[EMAIL PROTECTED]> writes:
>> You cannot change exported types.
>
> I didnt think so, but is it acceptable to make a cast from w->a when
> writing to this struct? I'll write it out and send it back through.
No, if it's an LPSTR it has to point to an ASCII string.
--
Alexandre Ju
> You cannot change exported types.
I didnt think so, but is it acceptable to make a cast from w->a when
writing to this struct? I'll write it out and send it back through.
On Thu, 02 Sep 2004 17:12:57 -0700, Alexandre Julliard
<[EMAIL PROTECTED]> wrote:
> James Hawkins <[EMAIL PROTECTED]> write
James Hawkins <[EMAIL PROTECTED]> writes:
> --- include/wincrypt.h18 Aug 2004 23:51:04 - 1.22
> +++ include/wincrypt.h1 Sep 2004 01:11:45 -
> @@ -175,7 +175,7 @@
> DWORDdwProvType;
> BYTE*pbContextInfo;
> DWORDcbContextInfo;
> -LPSTRp
Another approach would be to rework wininet to use
SSPI (implemented in secur32.dll), and to write an SSP
for SSL and TLS. You could write one that uses NSS if
you like, or another that uses OpenSSL or GnuTLS.
Not sure how "fun" that would be though .
--Juan
__
Hi,
Seems like I found out which flags causes trouble with the scrollbars and
the mouse's scrollwheel: building wine without -fomit-frame-pointer flag
makes it work right.
This fixes my problem
( http://article.gmane.org/gmane.comp.emulators.wine.devel/23780 ) and
seems to fix (at least for me) th
Steven Edwards wrote:
> LOCATIONS="/usr/lib/mozilla /usr/lib/mozilla-* /usr/lib/firefox-*
> /usr/lib/netscape /usr/lib/firefox /usr/local/netscape
> /usr/local/mozilla /usr/local/firefox /opt/mozilla /opt/netscape
> /opt/MozillaFirebird /opt/firefox"
In Gentoo is under /usr/lib/MozillaFirefox, but
--- Mike Hearn <[EMAIL PROTECTED]> wrote:
> LOCATIONS="/usr/lib/mozilla /usr/lib/mozilla-* /usr/lib/firefox-*
> /usr/lib/netscape /usr/lib/opera /usr/lib/MozillaFirebird
> /usr/lib/firefox /usr/local/netscape /usr/local/mozilla
> /usr/local/MozillaFirebird /usr/local/firefox /opt/mozilla
> /opt
(Don't look at the date in the directory, it actually is the cvs version
as of 2004/08/26)
I only changed the #if on line 3042.
change the DEBUG_Printf into a FIXME, that'll do it
I moved the PayPal link below the CodeWeavers link. This should avoid
any future confusion.
There is not a "null" href in the code. I have no idea where you are
seeing one.
On Tue, 2004-08-31 at 21:03, [EMAIL PROTECTED] wrote:
> On Mon, Aug 30, 2004 at 12:37:50PM -0400, Tom wrote:
> > Jeremy Newm
Chris Rankin a écrit :
Hi,
I am almost running an old DOS-based application using
wineconsole, but I am constantly being bombarded by
FIXME messages from the DOSVM's Int33 calls for "Show
mouse cursor" and "Hide mouse cursor".
I have tracked the relevant code down to
dlls/winedos/int33.c, but don't
On Thu, 02 Sep 2004 10:38:35 -0700, you wrote:
> Rein Klazes <[EMAIL PROTECTED]> writes:
>
> >> And does
> >> that call generate a WM_NCPAINT message?
> >
> > No.
> >
> > I have uploaded a +relay,+message,+win snip (300 KB) of the log at
> > http://home.wanadoo.nl/wijn/tmp/wine2.log.bz2
>
> OK
Rein Klazes <[EMAIL PROTECTED]> writes:
>> And does
>> that call generate a WM_NCPAINT message?
>
> No.
>
> I have uploaded a +relay,+message,+win snip (300 KB) of the log at
> http://home.wanadoo.nl/wijn/tmp/wine2.log.bz2
OK, I see, it seems GetUpdateRect doesn't behave exactly like
GetUpdateR
Mike Hearn wrote:
Other solution is just to detect this and ask the user to rerun Wine
as root. I don't think that'd be a big deal.
But then that brings up the issue of users not being able to run wine
merely because they don't have root access, i.e. users on a Linux system
in a business environm
Robert Shearman wrote:
Mike Hearn wrote:
I wouldn't trust it. An app just misbehaving can trash important
parts of your filesystem. Suid root is just a bad idea, windows being
linux aware or not. Just for mild amusement I think someone being
funky got a windows virus to work under wine if I reca
Can you have a look at the bug #2302. This is not regession but my
problem sounds very similar. In the program no scrollbars are shown. I
have tried the native comctrl as well. The picture shows how the dialog
should look like.
Yours,
Nicolai
Am 01.09.2004 um 18:52 schrieb Alexandre Julliard:
-
Mike Hearn wrote:
I wouldn't trust it. An app just misbehaving can trash important parts
of your filesystem. Suid root is just a bad idea, windows being linux
aware or not. Just for mild amusement I think someone being funky got
a windows virus to work under wine if I recall correctly.
Sure. Do
On Thu, 2 Sep 2004, Hans Leidekker wrote:
[...]
> That's strange, just yesterday I cross compiled all tests
> without any error.
It's libuuid.a which was not up-to-date on my system. And 'grep
CLSID_CMultiLanguage ole32.dll.so' shows a match but apparently this is
no where the symbol is defined an
--- Mike Hearn <[EMAIL PROTECTED]> wrote:
> It'd be a tragedy to reimplement all that of that
> code because of GPL vs
> LGPL concerns.
I agree. Andrew Bartlett did too in an email he sent
me. The reason I've backed off from this is that it's
hard to do correctly, and anything less than
complet
Well yes its a standalong project but most people only have it if they
installed mozilla. I think the best way to do it if we were going to go
down the NSS route would be to add a few lines of magic to the wine
script and detect the mozilla path at runtime. I think we could do a
short version of wh
Mike Hearn wrote:
> I think it's better to depend on an actual library, as opposed to a
> component of another application. Maybe if Mozilla split it out into a
> separate project with separate releases, packaging etc, it might be
> better. Maybe they already have ...
I think they have, also if the
Hi,
--- Mike Hearn <[EMAIL PROTECTED]> wrote:
> I think it's better to depend on an actual library, as opposed to a
> component of another application. Maybe if Mozilla split it out into
> a
> separate project with separate releases, packaging etc, it might be
> better. Maybe they already have
Mike Hearn wrote:
I wouldn't trust it. An app just misbehaving can trash important
parts of your filesystem. Suid root is just a bad idea, windows being
linux aware or not. Just for mild amusement I think someone being
funky got a windows virus to work under wine if I recall correctly.
Anyway, i
A better solution is to use the Mozilla Network Security Services
(NSS). NSS is everywhere mozilla is and is much more mature.
Yes, that's another approach. Gaim did this though and then implemented
support for GnuTLS as well, because having a chat program depend on a
web browser was a bit odd an
I wouldn't trust it. An app just misbehaving can trash important parts
of your filesystem. Suid root is just a bad idea, windows being linux
aware or not. Just for mild amusement I think someone being funky got a
windows virus to work under wine if I recall correctly.
Sure. Don't have to be funk
Hi,
--- Mike Hearn <[EMAIL PROTECTED]> wrote:
> The downside is that while OpenSSL is frequently going to not be
> found
> as it's the wrong version, GnuTLS is also not widely installed by
> default so it might not get us much in the short term.
A better solution is to use the Mozilla Network S
The OpenSSL library we use in wininet/netconnection.c is a very unstable
library, with somewhat odd licensing as well. By unstable I'm talking
about the interfaces it exports: unfortunately they break backwards
compatibility very frequently with the result that a build of Wine
compiled on one s
Samba has already documented the protocol and if it wasn't for licensing
issues it would be very easy to port it into Wine.
Well, how easy is very easy? What I meant is that it's unlikely to be
something you could do quickly unless you were familiar with the code in
question.
It'd be a tragedy
Mike Hearn wrote:
Named pipes is ncalrpc yes? This OPC thing sounds more like a network
protocol.
Sorry, I understand now. We use local named pipes to implement (local)
DCOM internally but ncalrpc on windows is actually implemented using
NT ports. So named pipes via SMB/CIFS ... yeah, I doubt w
On Thursday 2 September 2004 13:26, Francois Gouget wrote:
> Running make crosstest in dlls/mlang/tests I get:
>
> i586-mingw32msvc-gcc mlang.cross.o testlist.cross.o -o
> mlang_crosstest.exe -lole32 -lgdi32 -lkernel32 -lntdll -luuid
> mlang.cross.o(.text+0x469e): In function `func_mlang':
> /ho
Running make crosstest in dlls/mlang/tests I get:
i586-mingw32msvc-gcc mlang.cross.o testlist.cross.o -o
mlang_crosstest.exe -lole32 -lgdi32 -lkernel32 -lntdll -luuid
mlang.cross.o(.text+0x469e): In function `func_mlang':
/home/fgouget/wine/dlls/mlang/tests/mlang.c:618: undefined
reference to `I
Named pipes is ncalrpc yes? This OPC thing sounds more like a network
protocol.
Sorry, I understand now. We use local named pipes to implement (local)
DCOM internally but ncalrpc on windows is actually implemented using NT
ports. So named pipes via SMB/CIFS ... yeah, I doubt we could do that
an
On Thursday 02 September 2004 04:12 am, Mike Hearn wrote:
> Or can named pipes go over the wire as well? If so that's a bit scary
> ... what sort of protocol would they use?
Named pipes use SMB/CIFS over NetBIOS, IIRC
On Wed, 01 Sep 2004 19:39:25 -0700, you wrote:
> Rein Klazes <[EMAIL PROTECTED]> writes:
>
> > This has the effect that a program that like agent does this:
> >
> > case WM_PAINT:
> > if( GetUpdateRect(hWnd, ...) {
> > hdc = BeginPaint(hWnd,...);
> >
> > }
> >
> > causes a lot of:
- only DCOM over TCP is likely to be supported. DCOM
over named pipes definitely wouldn't be.
Named pipes is ncalrpc yes? This OPC thing sounds more like a network
protocol.
Or can named pipes go over the wire as well? If so that's a bit scary
... what sort of protocol would they use?
thanks -
36 matches
Mail list logo
