My Error or vf6.6B Bug?

My Error or vf6.6B Bug?

The attached zip file illustrates a dll problem which I have been unable to resolve. The first 3 files are used to construct a dll containing a module c_record. In this, there is an array which should be imported into programs which use the module.

The fourth file is used to create a simple console project which should import the array. However, this does not happen. When I use the *.mod file created for the dll in the console project link path, I get that it is unable to resolve the external reference.

The fifth file is a binary which should be legible by the console project program (sample data) if all goes well in the compilation.

Oddly, there are other dll's in the suite of programs which I have been trying to compile which seem to me to be very similar in the relevant particulars: arrays within a module contained in a dll which need to be accessed by console projects. And these other dll applications do not give rise to the noted difficulty.

So do others get the same trouble or am I just not performing the importation properly?

13 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

My first attempt at posting with attachment failed to get the attachment to take. Let me try again:

FWIW, I played with your code for a while but I didn't manage to get it working. I made an (almost) compilable workspace out of it -- attached, but only because guys from support will be happier with complete working sample. I suggest you send it to

Side comment: this is definitely not a way I'd do it. The whole point of dlls is to have encapsulation, but instead you're trying to share unit numbers, arrays, and as a result you have to share .mod and .lib files as well -- IMNSHO the end result will be a hardly manageable mess of .dlls, .mods and .libs spread accross your disk or local network. Instead, I would pass file name to the dll, and use the Array as an argument -- no need to link against DLL version of RTL, no need to copy .mod files, no discoveries of compiler bugs :-) (It could be a bug, but guys from support will know better).


A side note of my own: sharing unit numbers across DLLs is a dangerous area - it has caused/is causing us endless headaches. Because the FRT controls the open units there are only a very specific set of circumstances where this will work. I'd advise you to avoid doing it if you can.

A couple of comments (I haven't looked at the example).

Sharing unit numbers with a DLL works as long as both the DLL and the EXE are linked to the DLL form of the run-time library. Nonetheless, I'd go further and say that sharing variables with DLLs is a dangerous area - it is easy to unknowingly be using a local copy of the variable. It is much better to have a callable interface into the DLL to set and get values.

Importing and exporting variables not in COMMON from DLLs is new to the compiler, and it took us a while to get it right. I think we may have made some fixes after 6.6B was released - do send an example to vf-support and we'll take a look.


Retired 12/31/2016

Hello Steve,

This example was originally sent to customer support. Lorri was handling it while you were away. First sent in late August, it has undergone a couple of iterations since. However, I did not think the example could be simplified much further and still reveal the apparent anomaly.

Your point about the local copy within the console project main program is indeed what I experienced until Lorri told me how to include the *.mod files generated in the dll compilation (rather than recreating them for the console project). So that advice better localized the problem - but did not resolve it for me.

Notwithstanding the comments from others, it would be a downer to have all our programs using the dll create their own copy of the fairly large arrays we hoped to pass. The dll in question contains routines which read data blocks produced by an application software package. These data blocks are from binary files with variable length fortran records. The dll routines typically place data in what were common block arrays for processing by the calling programs. They also position the programs in specific sequential positions in the binary files.

All these programs were written in F77 originally and converted on a VMS system to F90 using the software package SPAG. During this conversion, many common blocks became modules. Perhaps your advice is to reverse that process in selective cases? In any event, the sharing of unit numbers would be essential since the dll routines and the main programs must both read the same binary files.

For the record, the support reference for this query is #CVF18768. Development work for the past few months has used static libraries for all the programs, setting aside dll's. I would like to resume their use now if feasible.

I feel inclined to comment on the folowing -- this is the second time in last few days I hear something similar here:

Notwithstanding the comments from others, it would be a downer to have all our programs using the dll create their own copy of the fairly large arrays we hoped to pass.

I'm not sure whether this is a misconception in mind or just a badly formed statement; even if the latter, I must add few comments. When you pass an array through argument-list, neither a copy nor any kind of memory duplication is involved (except in some special cases which I wouldn't elaborate now). Dllexporting only routines and passing arrays through argument lists is my idea of clean interface. Performance penalty is negligible.

During this conversion, many common blocks became modules. Perhaps your advice is to reverse that process in selective cases?

The approach I suggested above has a disadvantage when there are many variables to be passed -- long arg-lists become clumsy. However, even then it would be a good idea to pack them into (arrays of) derived TYPEs (especially now when CVF supports ALLOCATABLE components) and share only type declaration modules between exe and dlls. Thus, my advice for your question above would be just to repack ex-commons into TYPEs. TYPEs are far easier to handle than groups of arrays.

In any event, the sharing of unit numbers would be essential since the dll routines and the main programs must both read the same binary files.

As for sharing unit numbers, now I see why you need it. Offhand, I would still prefer the approach with many different files instead of one big, "browsable", but I understand that it could require a major rework at best.



I looked at the ZIP file you posted here, but it is incomplete - not all the sources needed to compile are provided - and I can't tell from it what you are trying to do. There's no project files, I can't even tell what you're building. The ZIP you sent to Lorri is the same.

Let's take this back to vf-support - please send there, with #CVF18768 in the subject line, a ZIP file of a complete workspace with EXE and DLL projects that demonstrates the problem you're encountering. Try to keep it to the minimum of variable export/import. I'll work with you from there.


Retired 12/31/2016

Steve, you could take the one from my previous post -- it has two projects with dependencies set, both producing output in project directory root, with correctly set include path and RTL set to DLL, single threaded. The problem seems to be that variable ARRAY from a module doesn't get imported, because an underscore somehow gets in the way -- I'm not very familiar with exporting/importing variables either.

You are very perceptive. Steve has identified a linker bug which was indeed related to the underscore.

I have noted what you sent to Steve lest I have a future query of the same sort. It was not obvious to me what they would like to see. Thanks for your help.

I've been playing with this some more. I have two examples which are almost identical - one works, the other doesn't. I haven't yet gotten to the bottom of it.

The linker is playing games here...


Retired 12/31/2016

Ok, I figured it out. Tom's problem was caused by EQUIVALENCEing the exported variable. The compiler doesn't properly DLLIMPORT EQUIVALENCEd variables from modules. I suggested putting the variables in a COMMON and DLLIMPORTING the COMMON - that works.


Retired 12/31/2016

Thank-you for your suggestions. There are historic organizational consistency reasons why I would like to proceed as I have done. The programs originate on a VMS platform where linking was all static. Perhaps, the structure will need bigger than the obvious upheavals to work optimally on a windows platform. But I'll do that reluctantly - at least until all our QA cross-checks between platforms have established the transition.

It sounds as if you have had much the same result as I did with the program as written. So far, I have had no problems with sharing unit numbers. And, indeed, I had another dll which does much the same things and seems to "get away with them". No doubt there is a subtle difference of application which eludes me.

Leave a Comment

Please sign in to add a comment. Not a member? Join today