Converting VMS C to Windows C++ or C#

[fdmaxey]

I have been given a project originally written in VMS C. It is
extensive code, with a number of complex algorithms. It also
accesses
an Oracle database via Embedded SQL.

The code is to be ported to a Windows Server 2003 environment. The
database will be ported to Microsoft SQL Server.
I have a couple of choices:
The most ideal choice from a long-term standpoint is to convert the
code to C# and use OLEDB to access the database. Everythings going
to
C#, as far as I can see. I have also used OLEDB in VB applications
so
I am familiar with it. The downside is that there is no "nice"
conversion from unmanaged C code to C#. I see a number of nasty,
unknown gotchas that could pop up. Even if I find a good conversion
package, there would be major work ahead.
The second choice is to convert to C++ and use the standard ODBC
classes (CDatabase, CRecordset) to access the database. This is
somewhat easier, as more of the original code could be carried over.
The downside here is that I'm left with an application that uses a
platform and functions that will be outdated sooner. From what I can
see, ODBC is falling slowly out of use. At least most of the
articles
I see on the internet are at least a year old, most are older. I
could be wrong, though.
The operating constraints for the project are that I have some extra
time in for R&D, but not a huge amount. The same applies to the
budget. The project manager does not want to risk getting bogged
down
trying to get the newest software to work on the old code. Having
converted one project from VB 6.0 to VB.NET a few years back, I can
testify that what looks like a fairly simple conversion usually
isn't.
I would appreciate any recommendations and/or input as to which way I
should go.

[Brian Muth]

My gut tells me that you should simply recompile the C using just the Microsoft C compiler, and not even bother trying to convert to
C++ on the first pass. Concentrate your efforts on the SQL interface. If there is time afterwards, consider touching up the key
parts to C++, and possibly even using the ATL OLE DB Templates. (cf. http://msdn2.microsoft.com/en-us/lib...16(VS.80).aspx)

Nobody is going to thank you for updating to C#/SQLAdapter if you blow your schedule or your budget. Get it running under Windows
Server 2003 is the first priority.

(Just my gut feel.)

Brian

"fdmaxey" <fd*****@yahoo.comwrote in message news:11**********************@v3g2000hsg.googlegro ups.com...

>I have been given a project originally written in VMS C. It is
extensive code, with a number of complex algorithms. It also
accesses
an Oracle database via Embedded SQL.

The code is to be ported to a Windows Server 2003 environment. The
database will be ported to Microsoft SQL Server.
I have a couple of choices:
The most ideal choice from a long-term standpoint is to convert the
code to C# and use OLEDB to access the database. Everythings going
to
C#, as far as I can see. I have also used OLEDB in VB applications
so
I am familiar with it. The downside is that there is no "nice"
conversion from unmanaged C code to C#. I see a number of nasty,
unknown gotchas that could pop up. Even if I find a good conversion
package, there would be major work ahead.
The second choice is to convert to C++ and use the standard ODBC
classes (CDatabase, CRecordset) to access the database. This is
somewhat easier, as more of the original code could be carried over.
The downside here is that I'm left with an application that uses a
platform and functions that will be outdated sooner. From what I can
see, ODBC is falling slowly out of use. At least most of the
articles
I see on the internet are at least a year old, most are older. I
could be wrong, though.
The operating constraints for the project are that I have some extra
time in for R&D, but not a huge amount. The same applies to the
budget. The project manager does not want to risk getting bogged
down
trying to get the newest software to work on the old code. Having
converted one project from VB 6.0 to VB.NET a few years back, I can
testify that what looks like a fairly simple conversion usually
isn't.
I would appreciate any recommendations and/or input as to which way I
should go.

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

fdmaxey wrote:

I have been given a project originally written in VMS C. It is
extensive code, with a number of complex algorithms. It also
accesses
an Oracle database via Embedded SQL.

The code is to be ported to a Windows Server 2003 environment. The
database will be ported to Microsoft SQL Server.

I have a couple of choices:

The most ideal choice from a long-term standpoint is to convert the
code to C# and use OLEDB to access the database.

If you go .NET you will not want to use OLE DB but instead use
the .NET SqlClient.

Everythings going
to
C#, as far as I can see. I have also used OLEDB in VB applications
so
I am familiar with it. The downside is that there is no "nice"
conversion from unmanaged C code to C#. I see a number of nasty,
unknown gotchas that could pop up. Even if I find a good conversion
package, there would be major work ahead.

I think that is correct.

The second choice is to convert to C++ and use the standard ODBC
classes (CDatabase, CRecordset) to access the database. This is
somewhat easier, as more of the original code could be carried over.
The downside here is that I'm left with an application that uses a
platform and functions that will be outdated sooner.

A third option would be to go for managed C++ (C++/CLI is the name
this month I think) as language and .NET SqlClient as database
API.

It should be easier to port to C++ than to C#. You get a good
database API.

You can migrated to C# gradually over the coming years.

Arne

[Charles Churchill]

If you are interested in outside help, Datatek, Inc offers an
automated C/C++ to C# conversion service. We can produce nice clean C#
code and we guarantee our results. Feel free to give me a call or
shoot me an email if you would like more information.

Charles Churchill
Account Executive
Datatek, Inc.
800 536-4835 ext. 145
1 919 425-3145 (international)
ch*******@datatek-net.com