1

We have some systems in Micro Focus Cobol.Net which we are considering converting to C#.

We have tried opening up the dll's in reflector, but then we just get C code.

Anyone have a recommendation of how to do this?

When I select C# in reflector I get code that looks like this:

        meminit(&(this._MF_OSBLOCK[0]), 0x20, 4);
        this._MF_OSBLOCK[4] = 0x30;
        this._MF_OSBLOCK[5] = 0x30;
        this._MF_OSBLOCK[6] = 0x30;
        this._MF_OSBLOCK[7] = 0x30;
        meminit(&(this._MF_OSBLOCK[8]), 0x20, 30);
        memcpy(&(this._MF_OSBLOCK[0x26]), &(_MF_LITBLOCK[0]), 2);
        int num2 = 0;
        do
        {
            memcpy(&(this._MF_OSBLOCK[40 + num2]), &(_MF_LITBLOCK[0]), 2);
        }
        while ((num2 += 2) < 0xc6);
        memcpy(&(this._MF_OSBLOCK[240]), &(_MF_LITBLOCK[2]), 4);
Shiraz Bhaiji
  • 64,065
  • 34
  • 143
  • 252
  • 2
    Agree with Daniel Hilgarth - Reflector will certainly be able to show C# code, and will not show C code. – Kieren Johnstone Apr 04 '11 at 11:44
  • This looks strange indeed, but it is probably the way Cobol.net produces MSIL according to COBOL language specifications and internal Microfocus recipes. Maybe there is a way to fine-tune microfocus Cobol.NET MSIL generation to something more human redeable ? – Larry Apr 04 '11 at 12:07
  • Yes, use COBOL classes and .Net types (or types that have .Net equivilants).. Then the code generated will be pretty much the same as C# – Stephen Gennard Feb 09 '12 at 14:12

2 Answers2

5

You can safely assume you are looking at C# code, Reflector doesn't have a code converter for C. What you can't assume is that the Cobol compiler is generating sane C# code. It has no obligation in doing so. It can freely use helper functions that are defined in a runtime assembly that's specific to the compiler. Not unlike Microsoft.CSharp.dll.

Getting code that uses helpers with C-like names is not unexpected, C has been the run-anywhere language for a very long time. Compilers not infrequently were language translators, going from Cobol to C in this case and then using a C compiler to generate the platform specific machine code. Write once, run anywhere. Think of C as the IL of the olden days.

You can surely compile and run the generated C# code, be sure to use that Cobol specific assembly reference. You may have to dig it out of the GAC. As far as a running start to get decent C# code, hardly. The differences between the languages are too great.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
1

Opening a .NET dll in Reflector surely doesn't show C code. It might show Managed C++ code, but that can be changed simply by choosing C# in the language combobox in the toolbar.
Consider using the FileDisassembler add in, which allows to create a complete project from the assembly.

Daniel Hilgarth
  • 171,043
  • 40
  • 335
  • 443