Do you realize that the only time in our lives when we like to get old is when we're kids? If you're less than 10 years old, you're so excited about aging that you think in fractions." How old are you?" "I'm four and a half!" You're never thirty-six and a half. You're four and a half, going on five!

That's the key.

You get into your teens, now they can't hold you back. You jump to the next number, or even a few ahead.

"How old are you?" "I'm gonna be 16!" You could be 13, but hey, you're gonna be 16!

And then the greatest day of your life... you become 21.

Even the words sound like a ceremony... YOU BECOME 21... YESSSS!!!

But then you turn 30. Oooohh, what happened there? Makes you sound like bad milk. He TURNED; we had to throw him out. There's no fun now, you're just a sour-dumpling. What's wrong? What's changed?

You BECOME 21, you TURN 30, then you're PUSHING 40.

Whoa! Put on the brakes, it's all slipping away. Before you know it, you REACH 50... and your dreams are gone.

But wait!!! You MAKE it to 60. You didn't think you would!

So you BECOME 21, TURN 30, PUSH 40, REACH 50 and MAKE it to 60.

You've built up so much speed that you HIT 70! After that it's a day-by-day thing; you HIT Wednesday!

You get into your 80s and every day is a complete cycle; you HIT lunch; you TURN 4:30; you REACH bedtime.

And it doesn't end there. Into the 90s, you start going backwards; "I was JUST 92."

Then a strange thing happens. If you make it over 100, you become a little kid again. "I'm 100 and a half!"

May you all make it to a healthy 100 and a half!!

With XMas nearing, I thought it was time I made my yearly wish to Santa - that he would let his elves use C++ in WINE.

(Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', and you can make your wishes at 'wine-devel[at]winehq.com'..)

You see, Santa was always so good - he answered people's prayers and got together his obedient elves to run Win32 on Non-Windows platforms!

However, soon many of his elves found out that technologies like MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too complex to be implemented using plain C, and thus developments in those areas were soon in limbo.

But that could be solved using yet another language called C++ - if only Santa would let it be.

Oh please Santa ! Let us adultrate WINE with C++, please.

It's not that we will rewrite everything in C++ once we get the green signal - things like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but what about MFC, COM, OLE ?

Not that I expect to compile native MFC source using WineLib, but at least we can write the runtimes so that native MFC apps can at least run under WINE ?

DirectX oozes of classes,inheritance,abstaction and everything C++ as does OLE, COM and already our implementations have structure object pointers running wild, whereas encapsulation would have done away with it !

As a simple explanation, we might take our 'This' hack wheras C++ would let have us use it as 'this' without even us worrying about it! Also, there are many places in shell32, ole and shwlapi (I cannot comment on DirectX source as I do not have a graphics base at all ..) where initializing a few member variables from a constructor would have done away with some redundancy.

Most of the time we are passing around multilevel pointers when a simple reference would have done:

For example a call like

Stream_LoadString( stm, unicode, &This->sString ); [To 'static HRESULT Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )']

can be made to a simple

Stream_LoadString(sString);

using C++ if we had the prototype rewritten to 'static HRESULT Stream_LoadString(LPWSTR &pstr )' and making it a member function of IStream (and thus the 'IStream* stm' and 'BOOL unicode' would be member variables..)

We have code like that all over the place whenever COM etc comes into play and "That's Not A Good Thing(TM)" !

Please give us the green card - alternately, a new test branch may also be created just to see if C++ would work.All C++ based modfications would goto that tree. If that test branch works and delivers, it maybe merged into the main WINE tree, otherwise if it fails to deliver just remove it after a stipulated period !

If WINE stuck to C only because some platforms do not support C++, then will Win32 apps run on such OS at all ? Things like SPARC do not need MS Apps at all (though SPARC has C++..)

For a expert discussion on C++ please see http://www.research.att.com/~bs/blast.html Microsoft themselves use C++ :

<quote> Microsoft: Literally everything at Microsoft is built using various flavors of Visual C++ - mostly 6.0 and 7.0 but we do have a few holdouts still using 5.0 :-( and some products like Windows XP use more recent builds of the compiler. The list would include major products like:
• Windows XP
• Windows NT (NT4 and 2000)
• Windows 9x (95, 98,

You don't need Santa's permission for that, just go ahead and implement DCOM in C++ and show us how easy it is. I suspect you will quickly realize that the complexity of the problem does not come from having to explicitly pass the this pointer around...

Consider that the reason could be that C++ has too many interoperability problems to solve any within an interoperability project like Wine. Just try to compile something like MFC with g++ and see how well the result would run MSVC++-compiled programs.

Okay, perhaps I should say right away that it won't run, because g++ won't generate VC++-compatible code. In any case, I don't see why MFC should be part of Wine, it's not a core Windows component. There's nothing wrong with having a separate FreeMFC project outside Wine using C++ (and compiling their FreeMFC libs with MSVC++ for the benefit of Wine users)

As for COM/DCOM, having implemented big parts of it myself, I'm not so sure C++ would have helped a whole lot in any case. It's a mess and the only thing you'd achieve with C++ is a different style of mess (a more unreadable one, for starters).

Well done. It took me a significant amount of effort just to get that far in a similar project!

I found a piece of WineLib documentation (sorry: I don't have an appropriate cross-reference handy) that advocates that you write a shim layer between your Linux code and your vendor's DLL.

Basically, regardless of how clever WineLib really is, you still can't statically link an ELF object file against a PE COFF DLL. That's the reason you see undefined symbols---they really are undefined! You can, however, achieve what you want through another layer of indirection! :) Basically, you have to define simple statically-linked definitions for those symbols which merely call through to the dynamically linked versions contained in your vendor's DLL. It works like this:

• the vendor's DLL exports some function
  ReturnType FunctionName(ParameterType)
• you've got to write your own module that wraps this:
  #include <windows.h>
  #include <vendor_dll.h>
  static ReturnType (*FunctionName_pointer) (ParameterType);
  void InitialiseVendorDLL() { /* BE SURE TO CALL THIS SOMEWHERE EARLY */
  HINSTANCE dll;
  dll = LoadLibrary("vendor.dll"); /* N.B. ADD YOUR OWN ERROR CHECKING */
  FunctionName_pointer = GetProcAddress(dll, "FunctionName");
  }
  ReturnType FunctionName(ParameterType p) {
  return FunctionName_pointer(p);
  }

Compile and link against /that/ (or similar specialised for your particular situation), and you're undefined symbols will now have a definition, and your code should work as advertised. At the very least, all this worked for me!

See if I understand what you need:

• vendor.dll (windows binary only)
• myapp.exe.so (winelib application that uses vendor.dll API and compiles against "vendor" header files )

Check that you have done the following

1. wrote a vendor.dll.spec (spec syntax for all functions used from "vendor" headers)
2. compiled a libvendor.def file from above .spec file using winebuild (put libvendor.def in a directory specified by -L)
   <Makefile>
   # libvendor.def generation
libvendor.def: vendor.dll.spec
$(LDPATH) $(WINEBUILD) -fPIC -o $@ --def vendor.dll.spec \
$(vendor_dll_DLL_PATH) $(WINE_DLL_PATH) $(GLOBAL_DLL_PATH) \
$(vendor_dll_DLLS:%=-l%) $(GLOBAL_DLLS:%=-l%)
</Makefile>
3. make a myapp.exe.spec.c using winebuild including "vendor" to the list of needed dlls like kernel32 and advapi32 ... (this was done for you by winemaker Just add vendor at the end of the dlls list)
4. link myapp.exe.so with myapp.exe.spec.o (also done by winemaker)
5. Have vendor.dll available in runtime

Ok I know this going to start YALD (Yet Another Long Discussion) that wont go anywhere right away but......

ReactOS is getting ready to do a major import of the WINE dlls as you guys know due to my repeated cross-postings to Wine-devel and ros-kernel. When we compile rpcrt and ole32 from WINE with some hacks we can make it work under ReactOS but I would like to develop a implementation that works properly without dirty hacking. I dont know much about WINEs rpcss other than whats in the comments of the code and for that matter I dont know much about Windows rpcss. Can we share these components? How are we going to break compatibility by doing this?

Wine doesn't have LPC per se. If ReactOS does, I'd love to see their implementation and talk to you all about stealing it :)

Rpcss (in wine) is really a nasty kludge at this time. It only performs a single function: mapping of endpoints. Eventually, this is where the Running Object Table, the OXID Resolver, and maybe some other things should go. Furthermore, the endpoint mapping is done in completely the wrong way: it uses an arbitrary protocol over named pipes. It is supposed to be using RPC according to a standard interface (maybe there are two standards, though, the MS ORPC one and the ONC RPC one, which are supposed to coexist). That's not particularly important, however, until the wire protocol is fixed.

At the RPC API level, wine appears to support lpc -- but in fact it's using named pipes. The actual LPC API's (NT "Ports") are just do-nothing stubs. Implementing them might be easy; implementing them /well/ would probably require shared memory and be kinda scary. I have designs to do this myself (starting with the poor, easy implementation), but lately I'm not finding the time I want to dedicate to wine development.

Uhh... so in answer to your question, rpcrt4 and rpcss are designed to work together, and shouldn't have too many ugly dependencies (except that rpcrt4 has some ole32 deps for its ndr implementation). For the most part, they only use high-level Windows-y stuff found in kernel32; there may be a few unixisms/wineisms, of course, but compared to other dlls these should be trivial.

My advice: just run the code and see what happens. So long as ROS has working named-pipes, and a few other kernel essentials like critical sections, string atoms, etc, it ought to "just work", deficiencies and all. Just test with "/Oi" midl-generated code, and stick to the supported transports (lpc, ironically, or named pipes), or you will get no love. AFAIK, the only snag you may encounter is if your ole diverges from that of wine.. if that happens, just break the ndr types which require ole32 until you get your ole32 up to speed. Furthermore, you only need rpcss for dynamic endpoints!!! Fixed endpoints will work fine without rpcss. In real-world situations, due to the deficiencies of wine's RPC, there is almost never any reason to invoke rpcss, and it rarely runs.

Sorry to fulfill the prophecy about "YALD (Yet Another Long Discussion) that wont go anywhere right away but......",

My winalsa patch for alsa 1.0 support wasnt commited and there wasnt any feedback fo it. Another winealsa patch was commited after that, should I resubmit mine ?

References:

• http://www.winehq.org/hypermail/wine-patches/2003/11/0342.html
• http://www.winehq.org/hypermail/wine-patches/2003/12/0047.html

+#define ALSA_PCM_OLD_HW_PARAMS_API +#define ALSA_PCM_OLD_SW_PARAMS_API