using a 16 bit library

[Mack_Woodard]

Hi,

I am porting over a program written in microsoft fortran v5.1 to intel fortran 10.1. The program relied heavily on a library called spinlab7 by spindrift, which did a lot of graphics, menus, etc. I'd like to just add this library as one to search when I'm linking, but I keep getting lnk1136 "corrupt file...". I know the file isn't corrupt because when I try re-building the program under MS fortran it works. From reading around on the net, it seems this problem may be related to the library being 16 bit. If that's the case, can I set some option in intel fortran to allow it to open this library? I really do not want to convert all of these spindrift routines to equivalent quickwin routines. Any suggestions would be appreciated.

Thanks,

Mack

[jimdempseyatthecove]

Here is a starting place:

http://support.microsoft.com/kb/155763

Jim Dempsey

[Mack_Woodard]

Hi Jim,

i read through the knowledge base article and some of the supporting articles. Even though my library isn't a dll, do you think this approach should still work? I am running my intel compiler under xp 32 bit.

Thanks,

Mack

[Mack_Woodard]

Hi Jim,

There are several tools needed to accomplish this task. A thunk compiler, an assembler, and C++ both 16 bit and 32 bit versions. Wow!! The knowledge base article referenced windows SDK for some of these things. I'm literate in Fortran, and an engineer trying to manage this port but not a windows programmer by trade, and I don't know how or where to get some of these thing from. Any suggestions would be much appreciated.

[Paul_Curtis]

I don't think you will find any way to use an old 16-bit library with IVF (and, btw, IVF10.1 is several years old, you should get a current version). On 16-bit MSDOS machines the most efficient performance came from calling assembler routines which bypassed the opsys in favor of direct memory and hardware-register operations (can't do that any more). Your old library may use this sort of code, or (was your program intended to run under Win3.1/95/98/Me?) equally ancient and no-longer-functional calls to 16-bit Win API functions; such calls would no longer work even with current APIs which continue the original functionality, since the current Windows APIs expect 32 (or 64) bit arguments.