I'm one of the Wine developers, and I just managed to build Putty under Winelib. That is, Putty now runs as a native Linux application.

The interesting part is that I've managed to do so with virtually no changes to the source code, just a few changes to the makefile.cyg file.

Now, my question to you: are you interested in supporting Putty under Wine, as a Winelib app? If so, I can clean up my changes, and send you a patch for the build system to incorporate in your tree.

BTW, the resulting executable is about 500K, so it's not that large, compared to the Windows one at 360K.

Here's a quick status update on PuTTY as a Winelib app:

1. It compiles, links, and runs perfectly (Yay!)
2. I've talked to the PuTTY folks, and they agreed to add Winelib as one of their targets in their build process (provided I do the patch :))
3. I've modified they Makefile-generation Perl scrip to do just that.

Another problem developing Winelibs app while using your Wine tree. Say you have the following:

• a Winelib app you're working on
• a Wine tree you're working on
• you compile wine out-of-tree

Now, say you build your myapp.exe.so OK, and you now want to create a symlink myapp -> winewrapper so you can start your Winelib app. Problem is that winewrapper resides in the source tree, and there is no way for it to figure out where the build tree is, and it needs that.

Possible solution:

• have winewrapper somehow in the Wine build tree. One way to do that is to rename winewrapper to winewrapper.in, and generate winewrapper at build time
• link to the winewrapper in the build tree
• modify winewrapper slightly so that it looks where is resides, and if it's in the wine tree, is should try to use that to run the app.

Alexandre, what do you say?

If Wine was a mature, stable project, I'd agree with you. But it's not. The ability to make a small change in Wine, go back to the Winelib app, and test it, is invaluable. I would have simply given up debugging PuTTY f I had to go through a wine install for every little test and experiment I was making.

But beyond that, the audience for these changes are *Windows* developers. These guys know Win32, and it's probably easier for them to fix a small header problem and submit a patch, rather then complain on wine-devel. These are exactly the guys we want experimenting with Wine to get their apps to work, and for this sort of thing, you have to work out of the tree. I know I always do, I'd waste way too much time to do an install every single time.

If we ask Windows developers to start porting their stuff now, they will run into major problems and they will leave in disgust, with or without your patch.

I agree that fixing Winelib is not the number one priority, but we have to recognize that we won't attract the Windows crowd until we fix it properly. A couple of hacks here and there won't cut it.

And really, I don't think it's necessarily that much work to fix it; the main issue is identifying the problems and defining exactly what we need it to do. And I think the right approach is to have Wine developers like you try to port apps, because you know how to work around the problems; giving that task to a Windows developer at this point is not going to work IMO.

The winspool.drv issue is a lot more serious than the in-tree execution. This one screws things up badly for the PuTTY build system. Should we modify winebuild to try to link with winspool.drv, and if that fails with winspool.dll when -lwinspool is given? (or the other way around, I don't know)

Modern graphics tablets also provide pressure and tilt information, essential for quality graphics editors such as Painter & Photoshop. Currently graphics tablets are treated as mice in wine, and so cannot provide this information to a Win16/32 app. To access pressure & tilt info in Windows, a programmer would use the wintab.dll.

Has anyone attempted to build a wintab.dll for Wine?

I'm interested in attempting an extremely limited implementation for Painter & Photoshop, but don't want to reinvent the wheel.

Assuming nobody has done this what's the first step?

I did send a couple of days ago a first patch about the (n)curses backend to wineconsole Alexandre commented a few implementation issues in it, which may change a bit what I started with and how the wineconsole should behave:

console creation can be invoked from different contexts:

1. the program calls AllocConsole
2. the user starts wine thru wineconsole for his/her (favorite) CUI app (using from command line something like 'wineconsole foo')
3. (N1) the program forks a child with CREATE_NEW_CONSOLE flags set in CreateProcess
4. the program doesn't request anything

on the other hand, wineconsole is now able to handle two types of backend for the user interface:

A. USER: the one already in place

B. Curses: the new one using (n)curses and a regular term for display (N2)

C. no wineconsole support => by default, the windows input & output streams are hooked to stdin and stdout, but we don't provide full console support - cursor motion, screen reading...

now the final question, how to choose between A, B and C. the proposal is to fix the choice with:

1 => A
2 => B
3 => A
4 => C

why such a directive proposal ?

4 => C

is rather natural and doesn't need further explanation (one day, we could envisage to support it no longer, but that's another story)

1 => A

greatly facilitates the console creation (ncurses requires both terminal control and moreover to keep the process group leader running as long as all the children - hooked to the same terminal - are running). Very few programs use AllocConsole (and even use it). The only issue may be with winedbg which may allocate its own console on startup (N3)

2 => B

we could easily add 2 => A too (with some wineconsole parameters). Moreover, if the user wants to have the console in a specific xterm, it's doable with xterm -e 'wineconsole blablabla'

3 => A

here again it's easier to deal with. if trying to run a curses backend, we should ensure that two different wineconsoles are not currently hooked to the same terminal

If you have any comments, speak up now !!

So, I tried to force Pegasus Mail to load winsock explicitly using the -Z 128 option:

$wine winpm-32 -Z 128

but wine comes back with 'Unknown option -Z'.

I'm not quite sure how these are getting parsed

Options for the win-programm should be given after a blank "--" E.g.

$wine -- winpm-32 -Z 128

Doh. It's even in the Pmail KB article below, and I didn't see it.

Pegasus Mail TCP/IP works after reading the following KB article from pmail: [ LINK ]

I think if you don't start Pmail the first time with the -Z 128, it sets an option to never load it.

If the application directly or indirectly loads GDI32.DLL or USER32.DLL it also load the x11drv with the result above if DISPLAY isn't set.

In addition to the ttydrv (as you meantion above) you can use VNC like:

vncserver :1
export DISPLAY=:1

I am thinking about some netapi32 improvements where I'd need to call the functions of the getpw/getgr family: getpwnam(), getpwent(), getgrent(), etc.

Configure checks for the "pwd.h" header and getpwuid(). Must I add more checks for all the functions I use, or is it ok to assume that getpwuid() presence implies getpwnam() presence?

Good question. I'm don't think we have any policy concerning this. Perhaps we should have.

One thing that you shouldn't assume is for example that if a function exists its reentrant variant exists as well.

For example that fact getpwnam exists doesn't imply that getpwnam_r exists. And yes, you really should use the reentrent variant if present as well as having an alternative implementation if not.

As to the implict existance question: I'm not sure. First of all, to answer the related question: Should you have a alternative implementation for defined(HAVE_GETPWUID) && !defined(HAVE_GETPWNAM)?

IMHO the answer is no. It is not worth the effort to support hypotetical platforms unless we can verify the existance of one.

To return to the original question: I suggest that we should detect the presence or absence of ALL function we use that is verified not to exist on some platform and have for example code

1. Definitions
1. Object Classes

   An object class is a structure wich defines the data of an object and all the interfaces that act on the object data

   Example :

   struct ObjectClass {
   
   INTERFACE 1;
   INTERFACE 2;
   ............
   INTERFACE N;
   
   DATA;
   } ;
   
   typedef struct ObjectClass ObjectClass;

2. Objects

   An object is a instance of an object class.

   Example :

   An object is created as follows :
   
   ObjectClass* object = malloc(sizeof(ObjectClass),...)

3. Interfaces

   An interface is a way for an application to interact with an object. It contains a pointer to a virtual table plus some other data than can help objects management.

   An interface is a structure, which is used internally, that can be defined with the INTERFACE macro :

   #define INTERFACE(iface) \
   struct { \
   
   iface interface; \ /* VTABLE */
   LPVOID object; \ /* pointer to the object the interface belongs to */
   
   }

   To add a field to the interface, just add it in this macro.

   For example, we could embed the version number inside an interface or a magic number to check if the interface's pointer points to a real interface. And, off course, modify some macros or create new ones to make use of them.

2. Implementing COM objects
3. Declaring a COM object with multiple interfaces

   To declare interfaces in a COM object the ICOM_VFIELD_MULTI must be used for each interface as shown below:

   struct IDirect3DImpl
   {
   
   /* IUnknown fields */
   ICOM_VFIELD_MULTI(IDirect3D);
   ICOM_VFIELD_MULTI(IDirect3D2);
   ICOM_VFIELD_MULTI(IDirect3D3);
   ICOM_VFIELD_MULTI(IDirect3D7);
   DWORD ref;
   /* IDirect3D fields */
   IDirectDrawImpl* ddraw;
   LPVOID private;
   
   };

4. Creating an object

   Just declare an pointer to an object and allocate the memory for it. Example:

   IDirect3DImpl* object = malloc(sizeof(IDirect3DImpl),...)

5. Initializing interfaces

   It is done with the ICOM_INIT_INTERFACE(object_pointer, interface_name, virtual_table)

   ICOM_INIT_INTERFACE(object,IDirect3D, VTABLE_IDirect3D);
ICOM_INIT_INTERFACE(object,IDirect3D2,VTABLE_IDirect3D2);
ICOM_INIT_INTERFACE(object,IDirect3D3,VTABLE_IDirect3D3);
ICOM_INIT_INTERFACE(object,IDirect3D7,VTABLE_IDirect3D4);

6. Retrieve an object from within an interface's function

   If we consider the function :

   IDirect3D_AddRef(IDirect3D iface,.......)

   To retrieve a pointer to an object within the function, both followings macro are used :

   1) ICOM_OBJECT(object_class,iface)

   This macro return an pointer to the object, the value is of object_class* type

   Example:

   IDirect3DImpl* d3d = ICOM_OBJECT(IDirect3DImpl,iface);

   2) ICOM_THIS_OBJECT(object class,iface)

   It simply declares a This pointer and initialize it with the object address.

   IDirect3DImpl* This = ICOM_OBJECT(IDirect3DImpl,iface);

7. Sharing functions between multiple interfaces

   In the case where a function does no have to do specific actions depending on the interface, you can share directly a function.

   Example :

   If we consider the function :

   IDirect3D_AddRef(IDirect3D iface,.......)

   The different virtual tables would be :

   VTABLE_IDirect3D = {......,IDirect3D_AddRef,....);
VTABLE_IDirect3D2 = {......,XCAST()IDirect3D_AddRef,....);
VTABLE_IDirect3D3 = {......,XCAST()IDirect3D_AddRef,....);
VTABLE_IDirect3D7 = {......,XCAST()IDirect3D_AddRef,....);

   Note that this is possible because the ICOM_OBJECT can retreive the object's pointer without knowing the interface involved.

8. Thunking interface

   Interface thunking enable changing from one interface to another.

   The following macro COM_INTERFACE_CAST(impltype, ifnamefrom, ifnameto, ifaceptr) performs this task.

   • impltype = object class
   • ifnamefrom = interface type we have
   • ifnamefrom = interface type we want
   • ifaceptr = pointer to the interface to cast
   • return = pointer to the casted interface

   Interface thunking is a another way to shared a single function across different interfaces but as shown below this is required only when structures must be translated, interfaces returned casted or to handle prototype change :

   Example:

   You want to share the IDirect3D_CreateDevice across all IDirect3DX interfaces (with X above 1 because a device in Direct3D is created in a different way).

   IDirect3D2_CreateDevice(IDirect3D2* iface,.....) is the only one implementation of the function.

   The others are thunks to the IDirect3D2_CreateDevice.

   IDirect3D3_CreateDevice(IDirect3D3* iface, .....,LPDIRECT3DDEVICE3 *lpdevice, LPUNKNOWN lpUnk)
{
IDirect3DDevice3 *dev;
IDirect3D_CreateDevice(ICOM_INTERFACE_CAST(IDirect3DImpl,IDirect3D2,IDirect3D3,iface),.....,&dev);
*lpdevice = ICOM_INTERFACE_CAST((IDirect3DImpl,IDirect3D3,IDirect3D2,device)
}

IDirect3D7_CreateDevice(IDirect3D7* iface, .....,LPDIRECT3DDEVICE7 *lpdevice)
{
IDirect3DDevice2 *dev;
IDirect3D_CreateDevice(ICOM_INTERFACE_CAST(IDirect3DImpl,IDirect3D2,IDirect3D7,iface),.....,&dev);
*lpdevice = ICOM_INTERFACE_CAST((IDirect3DImpl,IDirect3D7,IDirect3D2,dev)
}

   Here, we have to deal with a returned interface and a prototype change.

   The VTABLE should be:

   VTABLE_IDirect3D2 = {......,IDirect3D2_CreateDevice,....);
VTABLE_IDirect3D3 = {......,IDirect3D3_CreateDevice,....);
VTABLE_IDirect3D7 = {......,IDirect3D7_CreateDevice,....);


   Note that there are few functions that need this, for the others, thunks are not necessary and the way described in e) must be preferred.

9. Getting an specific interface of an object

   With the ICOM_INTERFACE(implobj, ifacename) macro, any interfaces can be retreive from an object.

   • implobj = pointer to the object
   • ifacename = interface name we want
   • return = pointer to an interface

   Example:

   IDirect3DImpl* object;

............

IDirect3D3* iface_d3d3 = ICOM_INTERFACE(object,IDirect3D3)

10. Calling an COM object functions from another

    If a function is shared across multiple interfaces, you should write:

    IDirect3D3_CreateDevice(IDirect3D* iface,.....) { ICOM_THIS_OBJECT(iface); ................. IDirect3D_AddRef(ICOM_INTERFACE(This,IDirect3D),.....); ................. }

    If you know the nature of iface (i.e. thunking is used or the function is used in only one interface), you can write :

    IDirect3D3_CreateDevice(IDirect3D* iface,.....) { ICOM_THIS_OBJECT(iface); ................. IDirect3D3_AddRef(iface,.....); ................. }

Sort of, the problem is that Wine doesn't support apartments yet, so it doesn't try to keep track of the threads that has called CoInitialize.

Code to support apartments was part of a large code drop (sent to rewind-patches) a long time ago, along with a pile of rpcrt4 code, however this apartment code was never merged into Wine, and the rpcrt4 pieces was only merged recently when Greg Turner took an interest in it. And I don't really expect that COM apartment code to get merged in before proper interface marshalling (which is largely rpcrt4's job) is working either, though I suppose the pieces that keep track of them (so that CoInitialize gives the right return value) could be merged if someone wanted to.