···@gubbishwildcard.demon.co.uk (Martin Rodgers) wrote:
> While Unix may not depend so heavily on
> shared libraries, no Windows program can run without using a DLL.
Note there's a big difference between the need to _use_ some existing
DLLs (which I assume the Windows implementations do allow, directly or
via some foreign-language interface and possibly an intermediate layer)
vs. the need to _generate_ DLLs. At least as far as I remember, the
problems you've been talking about have been entirely within the second
area, and not about problems with using Windows' core libraries from
Lisp applications (if necessary via FFIs).
Well, if some Lisp implementation can't directly generate DLLs, and one
can't reasonably convert EXEs (or a bunch of non-linked object files, if
that's what the Lisp implementation happens to generate - I don't know)
to DLLs, an obvious strategy would be to use an EXE in Lisp as the server
process for one or more (depends on typical usage of the code) non-Lisp
programs - including some DLLs not written in Lisp.
You wrote you could do that with sockets or similar means, but it would
be to slow. Now I don't know much Windows internals, but I'd hope it's
not too primitive to allow/support some form of shared memory - which
should be sufficiently quick for all but the most extreme applications
(from what you wrote you don't seem to need a high-volume database with
heavy io rates as Lisp DLL). To cut down synchronization overhead for the
cases where one Lisp server has to work with more than one client (or
equivalently, with several threads from the same client program), such
code should obviously pre-allocate and reserve communication areas to the
performance-relevant threads of the client, thus serializing the access
protocol between one logical client-thread and the respective server
(re-)actions.
Unless Windows is even more primitive than I already thought, something
like the above shouldn't be very hard to do for a professional Windows
programmer, and probably require at least not much beyond C with Windows-
specific and Lisp-implementation-specific parts (though even most of the
communication logic should possibly remain more abstract than this).
Once the technology to do this is understood, generating the partially
application-specific protocol for each respective application semantics
should be simple from Lisp (after all, building a more abstract - and
more comfortably usable - layer on top of specifications is one of the
strenghts of Lisp). Of course, as far as it makes sense, even this form
of marshalling should be done essentially once and for all, with suitable
reflexive protocol specifications - which could be either compiled for
each specific usage, or even interpreted dynamically where that's needed.
Naturally, the C/whatever low-level side of application-specific instances
would also be generated by Lisp from the specification (a _general_ inter-
preter on the client-side may or may not need to be hand-optimized C for
best performance, depending on the complexity and performance-requirements
of your sytem).
If this is designed and implemented well, it may perhaps even be adapted
to other forms of byte-level communication paths than shared memory, and
different run-time data structures of other implementations and even of
other programming languages. (Who knows, somebody might even have done
something similar already, possibly without noticing that it might help
with this problem?)
Sure, doing all this would be more work for you than having someone else
change a Lisp implementation to generate DLLs and do the dirty parts of
primitive-to-high-level data interfaces for you, but it doesn't sound too
hard if the current alternative is not to use Lisp where you'd like to
use it, and if you really have such a big desire to use Lisp as you imply
in your postings here. Whether it would be good for Lisp vendors to do this
and try to become more widely used within the Windows world is a question
which goes far beyond technical discussions (Erik has mentioned some of
the potential problems, which are hardly unrealistic, even if you may not
like the way he phrased it, or don't agree with his evaluation of risks),
and for the most part wouldn't belong in comp.lang.lisp at all - even if
it made sense to discuss some company's business strategies in a public
forum (which I doubt quite strongly, for almost all cases - people don't
have the relevant information, rarely understand the problems with the
required depth, and are likely to evaluate other people's risk differently
from those where they'll have to live with the consequences themselves).
If you have Windows-specific technical questions, the Windows-related
newsgroups should be the relevant target (and you don't even need to
mention any relation of your questions to Lisp over there, preventing
possible "acceptance problems", uninformed flames and language wars).
On the other hand, if only some conceptual hindrance or Lisp-related
technical problem comes up while trying to implement such a solution,
I guess even Erik wouldn't attack you for actually trying to do it,
and might even contribute some helpful advice.
-- Marc Wachowitz <··@ipx2.rz.uni-mannheim.de>
With a mighty <············@trumpet.uni-mannheim.de>,
··@ipx2.rz.uni-mannheim.de uttered these wise words...
> You wrote you could do that with sockets or similar means, but it would
> be to slow. Now I don't know much Windows internals, but I'd hope it's
> not too primitive to allow/support some form of shared memory - which
> should be sufficiently quick for all but the most extreme applications
> (from what you wrote you don't seem to need a high-volume database with
> heavy io rates as Lisp DLL). To cut down synchronization overhead for the
> cases where one Lisp server has to work with more than one client (or
> equivalently, with several threads from the same client program), such
> code should obviously pre-allocate and reserve communication areas to the
> performance-relevant threads of the client, thus serializing the access
> protocol between one logical client-thread and the respective server
> (re-)actions.
Indeed, I've considered this. It could certainly be done, tho
something like this adds time to a project, which is, I suspect, where
the real objection will be. Also, many Windows components use MFC, so
this will require the creation of "proxy" classes to mimic the MFC
classes used in the components. Each proxy would then map calls to its
functions thru the interface (sockets, pipes, memory map & semaphore
or whatever) to the Lisp functions.
While some programmers have the patience to study the internals of the
MFC classes, most of us would prefer not to. It takes time, and it's
very ugly. Even MFC fans might hesitate to do this! When a simpler,
and more importantly, faster solution is available, even a programmer
like myself who would prefer to use Lisp will find resistance from
colleagues and management.
Using Lisp would need to provide a massive time saving to be worth it.
For a large project, this might be so. However, due to the nature of
Windows, what we often find is a collection of small components used
by servers, apps, and Windows itself.
The Lisp approach favours a large monolithic application. The Windows
style of development is increasingly oriented toward the small units
of code refered to as components (OLE, OCX, basic DLL, etc).
> Once the technology to do this is understood, generating the partially
> application-specific protocol for each respective application semantics
> should be simple from Lisp (after all, building a more abstract - and
> more comfortably usable - layer on top of specifications is one of the
> strenghts of Lisp). Of course, as far as it makes sense, even this form
> of marshalling should be done essentially once and for all, with suitable
> reflexive protocol specifications - which could be either compiled for
> each specific usage, or even interpreted dynamically where that's needed.
Sure, once you've spent the time (I've no idea how long this might
take), you could generalise it. You could write a utility that can
read C++ headers and generate C++ code (the proxies) and Lisp (the
Lisp side of the proxies).
Has anyone done this yet? Has anyone even looked into how this might
be done? All I know is that MS keep changing the API, the rules, the
language (VC++ acquires new featurses all the time, and not all of
them will be documented), MFC and anything else they want to. Any task
like this will be a race with MS.
> Sure, doing all this would be more work for you than having someone else
> change a Lisp implementation to generate DLLs and do the dirty parts of
> primitive-to-high-level data interfaces for you, but it doesn't sound too
> hard if the current alternative is not to use Lisp where you'd like to
> use it, and if you really have such a big desire to use Lisp as you imply
> in your postings here. Whether it would be good for Lisp vendors to do this
> and try to become more widely used within the Windows world is a question
> which goes far beyond technical discussions (Erik has mentioned some of
> the potential problems, which are hardly unrealistic, even if you may not
> like the way he phrased it, or don't agree with his evaluation of risks),
> and for the most part wouldn't belong in comp.lang.lisp at all - even if
> it made sense to discuss some company's business strategies in a public
> forum (which I doubt quite strongly, for almost all cases - people don't
> have the relevant information, rarely understand the problems with the
> required depth, and are likely to evaluate other people's risk differently
> from those where they'll have to live with the consequences themselves).
Lisp vendors have good reasons to do this (Harlequin's DylanWorks is a
good example), while lone developers not paid to do this may find it
very hard work, and esp if only their own time is available.
> If you have Windows-specific technical questions, the Windows-related
> newsgroups should be the relevant target (and you don't even need to
> mention any relation of your questions to Lisp over there, preventing
> possible "acceptance problems", uninformed flames and language wars).
You don't think that linking to an EXE like this might sound a little
odd to a Windows developer? It does. There's no reason for a C++
programmer to not use a DLL when a DLL is called for. That's the
beauty of C++ - it behaves the way that C++ programmers expect it to.
We're Lisp programmers, which is why we see it differently. The
problem is that C++ programmers will look at Lisp in the same way that
Lisp programmes see C++ - they'll see something alien.
As I've said before, there are languages not at all dissimilar to Lisp
that have no trouble creating DLLs. When creating a DLL is the obvious
answer to the demand for a DLL, the ugly kludged solution discussed
above will only make Lisp look like a language that uses ugly kludges.
This is exactly what you're saying.
What was it that Richard Bach said? Something like, "If you argue for
your limits, you get to keep them." Why accept a limitation that C++
compilers don't?
> On the other hand, if only some conceptual hindrance or Lisp-related
> technical problem comes up while trying to implement such a solution,
> I guess even Erik wouldn't attack you for actually trying to do it,
> and might even contribute some helpful advice.
There is a big conceptual hindrance here. You and Erik are arguing
against progress - support for a feature that is _expected_ of any
compiler for Windows. Even VB can do it! _VB_. Think about what that
says about Lisp. Lisp can't do something fundamental to Windows, and
yet that VB can.
Your entire arguement is based on a misconception about Windows. Why
work so hard to not use a feature that is vital to Windows software?
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
cybes for 4.5 years, now plain old mcr
Please note: my email address is gubbish