> On another note, however, I was re-reading the CryptoAPI
> thread and I don't
> think that Vladimir Vukicevic's questions were really
> answered from September
> 3rd.
Can you be a little more specific?
As far using GPL:ed libraries, that is a question that
really can't be properly answered without a real court
case.
Regardless of this if you want any code using a GPL:ed
library in the CVS you need to convince Alexandre to
change his mind.
What other questions are unanswered?
I have Converted WSAIOCTL to use SIOCGETIFCONF ioctl calls rather than parse
/proc which is to linux-centric but I was asked by Francois Gouget to look
at trying to make WsControl unix independent by implementing it using other
windows APIs rather than by using unix calls directly.
Unfortunately this API is a bit of a mess because WsControl can return the
MAC Adress but WSAIoctl doesn't appear to implement that functionality. To
get The MAC Address we then need to make an appropriate UNIX IOCTL call for
which we need the interface name, which isn't available from WSAIoctl either.
There are other ways in windows to getthe MAC address via an SNMP call but
I'm not sure how that is implemented (Possibly with a call back to WSControl)
I don't see then how WSControl can be implemented without the present hacks
and duplicated code between WSAIoclt and WSControl helper functions.
My proposal then would be...
1.)
Separate out all the unix centric helper functions for WSControl and WSAIoctl
into a common ancestor source file with no windows dependencies. This should
remove the ugly socket hack in WSControl, both libraries still end up with
private copies of the common helper functions but since they are all derived
from the same common source file it will at least be encapsulated and easier
to maintain.
2.)
The doco for WSIoctl indicate the encoding for the Ioctl op-code allows for
a "Standard" unix IOCTL to be passed to WSIoctl ostensibly for
FIONREAD,FIONBIO et al, with predictable results. If I were to implement
SIOCGETIFCONF in WsIoctl then this would allow a pass-through so I could get
what I need from the host OS without disturbing current windows programs.
Because windows doesn't define SIOCGETIFCONF whatever we choose for the value
of the op-code might end up being used by Microsoft later, breaking Wine.
(Possible but not very likely)
Opinions ?
I would like to find out if the development of WINE supports it being ported
to Windows 16-Bit OS. Currently, I am developing a Windows Clone and would
very much ike to work on Porting WINE to Win16. However, I am not 100% sure
if the way WINE operates wether it would work.
WINE will work if it is a complete re-written library system that merely
interfaces with the host system. WINE won't work if it serves as a
translater from host system system calls to the guest application.
Any information on this plus a good compiler that is usefull for someone who
knows a bit, but not everything, hopefully one with a good GUI.
Thank-You.
David Scherer, lacroixlucien(a)hotmail.com
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Marcus Meissner <marcus(a)jet.franken.de> writes:
> After last nights CVS commits, the Mousepointer appears not to be visible
> in some applications in both managed and unmanaged mode.
>
> Reproducable for me with sol.exe and winmine.exe (16bit) for instance.
This should fix it I think:
Index: windows/nonclient.c
===================================================================
RCS file: /opt/cvs-commit/wine/windows/nonclient.c,v
retrieving revision 1.84
diff -u -r1.84 nonclient.c
--- windows/nonclient.c 2001/08/24 00:26:59 1.84
+++ windows/nonclient.c 2001/09/14 17:20:00
@@ -1729,7 +1729,8 @@
*/
LONG NC_HandleSetCursor( HWND hwnd, WPARAM wParam, LPARAM lParam )
{
- if (hwnd != (HWND)wParam) return 0; /* Don't set the cursor for child windows */
+ if (hwnd != WIN_GetFullHandle( (HWND)wParam ))
+ return 0; /* Don't set the cursor for child windows */
switch(LOWORD(lParam))
{
--
Alexandre Julliard
julliard(a)winehq.com
Greetings,
Well i know ill get flamed for this but has anyone got IE 5.01 installed on wine? Everytime I try it gives me an
error that "Some programs hasnt finished and that I need to let it finish and restart my computer" Then it closes. So
any ideo on getting any version of IE installed?
Thanks
Nick Hudson
Hi,
After last nights CVS commits, the Mousepointer appears not to be visible
in some applications in both managed and unmanaged mode.
Reproducable for me with sol.exe and winmine.exe (16bit) for instance.
Ciao, Marcus
Bobby Bingham <uhmmmm(a)ameritech.net> writes:
> I think there was a discussion a while back about possibly rewriting the
> "unmanaged" mode (or adding a new mode, I don't recall which) to make it more
> like XMMS, but I can't find it now. This would really help on my system, as
> with KDE 2.2, wine windows are always on top and on every desktop and XMMS
> fits in a little better. I was wondering what the result if any, of that
> discussion was.
I was planning to implement that as part of the new window management
stuff. But this is on hold at the moment while I'm finishing the
shared window handles.
--
Alexandre Julliard
julliard(a)winehq.com
-----Original Message-----
From: Patrik Stridvall <ps(a)leissner.se>
To: 'eric pouech' <eric.pouech(a)wanadoo.fr>; Guy L. Albertelli
<galberte(a)neo.lrun.com>
Cc: Wine Devel <wine-devel(a)winehq.com>
Date: Thursday, September 06, 2001 5:59 PM
Subject: RE: Problem with specmaker
>
>Hmm. Thinking, modifying etc.
>
>What about this?
>
>Index: wine/tools/specmaker/function_grep.pl
>===================================================================
>RCS file: /home/wine/wine/tools/specmaker/function_grep.pl,v
>retrieving revision 1.1
>diff -u -u -r1.1 function_grep.pl
>--- wine/tools/specmaker/function_grep.pl 2001/01/04 19:45:50 1.1
>+++ wine/tools/specmaker/function_grep.pl 2001/09/06 21:50:26
<snip>
No the above patch merely resulted in an infinite loop. After much
consultation with "Perl in a Nutshell", I came up with the following patch.
The header file in question is "shlobj.h".
The patch has two sections. First gets rid of the \n imbeded with the
lookahead for preprocessor statements. The second gets rid of the
ICOM_DEFINE statement (poorly I know) because it has no ";". This seems to
make things work and generate correct headers.
Thanks,
Guy