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&scalability 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]

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...b;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:0v********************************@4ax.com...

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&scalability 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

[Cor Ligthert [MVP]]

Mike,

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

Just as idea

Cor

[m.posseth]

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]" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

Mike,

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

Just as idea

Cor