PAM-NTDOM: Compile Errors

Elrond elrond at
Thu Jul 13 17:30:19 GMT 2000

On Tue, Jul 11, 2000 at 04:26:46AM +1000, Paul J Collins wrote:
> >>>>> "Luke" == Luke Kenneth Casson Leighton <lkcl at> writes:
>     >> I never meant to imply that it was.  Let me give a 
>     >> bit of history here.  Luke and I (and others) have over 
>     >> the months and years had discussions over issues 
>     >> similar to this.  Luke has in the past wanted to make 
>     >> UNIX into NT in every aspect.  Not necessarily from a
>     >> services point of view, but from an architectural 
>     >> point of view.  
>     Luke> both.  the possibility of being able to tell microsoft,
>     Luke> here, install these services on this version of linux, with
>     Luke> these libraries, then hit "compile" on your office msdn
>     Luke> development environment, and you will get a native linux
>     Luke> office suite.
> First of all, Microsoft Office running on a bunch of Windows-emulating
> services (would CSRSS.EXE be one of these?) is not "native".  In a
> similar fashion, a Unix app running on cygwin and using X for its
> display is not really "native" either.  I follow the Wine project a
> little, and the things they have to do in order to run Windows
> binaries lift Wine a large step above being a toolkit.
> Second, I don't understand why this is a useful goal.  Programs such
> as Emacs have had difficulty mixing well with NT (e.g. NT's primitive
> process model; okay "different" process model); why should the
> converse not be true?  And if you follow that approach to NT/Unix
> integration, why not just drop Samba, implement the Win32 API (Wine!)
> the NT system traps and suggest that Microsoft recompile SRV.EXE, et
> al. on Unix?
> Which brings me to my next point.  Office and such rely on a number of
> chunks of software, updated versions of which these applications
> frequently install themselves.  One example that springs to mind is
> the COM/OLE libaries.  Do you reimplement those, or use Microsoft's
> versions?

That's, were wine comes in.

Wine tries to achieve exactly, what Luke asked about above.
They try to provide the complete Win32-API in source-form.
You can already drop in win32-programs, compile them and
then you get a unix-binary, linked against some libraries.
I was even able to compile wine a long time ago on AIX on
an RS/6000. And try to start the provided progman. Well, I
got an error-msg and the amount of patching, that I have
done to get it compiling (well... in those times, I haven't
even thought about sending them a patch...) was quite
disappointing, so I dropped that.

Some weeks ago, I've taken a look at their sources again.
There's quite some interesting stuff in there. Even stuff,
that resembles utility-functions in samba.
And they even have the client-functions, that resemble the
functions that are used in rpcclient.

But: They haven't got the right implementation

Most of these functions are just either fakes or running
funny stuff against the registry...

samba is doing the right thing in this area...

Some cooperation in this area might be of interest... at
least to the wine-developers.


More information about the samba-ntdom mailing list