Backwards DLL question

[Mike]

I've seen this sort of answered earlier, but would like to be 100%
sure that it's as unlikely as I suspect it is - can .NET create an
"old-fashioned" dll which can be called by 16-bit programs written in
BC5?

We have a hefty db app created with BC5 which uses an xBase data
store. The idea is that since a single dll routes all access between
the business layer and the xBase engine, they can graft
performance&sca lability onto this relic by swapping out their dll for
one written in .NET which acceses SQL 2k. Existing 16-bit exe's and
dll's would use exactly the same function calls into this new dll and
be none the wiser.

Sounds like wishful thinking to me, but I'm still a newbie when it
comes to .NET - is this even remotely possible? If it was, would
there be be even greater than normal interop costs? And, (OT I know
but just to cover all bases) can even VB6 go backwards like that?

Thanks - Mike

[m.posseth]

Re: Backwards DLL question


Well i might give you an unexpected answer ,,,, ;-)

If you mean with the program language BC5 Borland C++ 5.X then the answer
is yes this should be possible
as C++ 5 is also capable of OLE / COM

but after reading this ( regarding the 16 bit 32 bit interop )

http://support.microsoft.com/default.aspx?scid=kb;en-us;263618

i must conclude that a dll is not possible ( in process ) , however a out
of process server should still be possible so you could write a Activex
executable that can be called this way
however i have never done this myself but it should be possible .

regards

Michel Posseth


<Mike> wrote in message news:0ve4g152et hagvldhf2jr2d3n 2prdqmf70@4ax.c om...[color=blue]
> I've seen this sort of answered earlier, but would like to be 100%
> sure that it's as unlikely as I suspect it is - can .NET create an
> "old-fashioned" dll which can be called by 16-bit programs written in
> BC5?
>
> We have a hefty db app created with BC5 which uses an xBase data
> store. The idea is that since a single dll routes all access between
> the business layer and the xBase engine, they can graft
> performance&sca lability onto this relic by swapping out their dll for
> one written in .NET which acceses SQL 2k. Existing 16-bit exe's and
> dll's would use exactly the same function calls into this new dll and
> be none the wiser.
>
> Sounds like wishful thinking to me, but I'm still a newbie when it
> comes to .NET - is this even remotely possible? If it was, would
> there be be even greater than normal interop costs? And, (OT I know
> but just to cover all bases) can even VB6 go backwards like that?
>
> Thanks - Mike
>[/color]

[Cor Ligthert [MVP]]

Re: Backwards DLL question

Mike,

The major part of your solution will probably have a short livetime.
64-bits operatingsystem s will not anymore be able to use 16-bits programs.

Just as idea

Cor

[m.posseth]

Re: Backwards DLL question

well ,,,

I am already running for half a year on a 64 bit computer as a development
platform ( ACER 1524 WLMI , A64 3400 + , with 1,2 GB mem ,running on
windows server 2003 64 bit )
every customer that i visit is watching at my laptop as if it comes from
Mars ( 64 bit ??? huh ?? does it exist already , can you run it , can you
develop on it for 32 bit etc etc )

so i can say that i am aware of the upcomming 64 bit hype :-) ,,,,,

however i also believe that using COM as a translation layer, is for the
topic starter a nice solution to expand the lifetime of there current
solution for maybe 1- 2 years in the meanwhile they can spent there time
writing a modern solution ( that will probably perform superb in
comparisation to the current prog )

regards

Michel



"Cor Ligthert [MVP]" <notmyfirstname @planet.nl> wrote in message
news:%23lrHtRvo FHA.2976@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> Mike,
>
> The major part of your solution will probably have a short livetime.
> 64-bits operatingsystem s will not anymore be able to use 16-bits programs.
>
> Just as idea
>
> Cor
>[/color]