Forcing Common to 64K address boundaries

[Steven_F_1]

Ok, I have seen a lot of posts about this but nothing suggested seems to work.  I am trying to force commons to appear at 64K address boundies  as this will allow me to pass that address to MapViewOfFileEx to bring in a memory mapped file.  I am attempting to emulate the VMS global section mapping process to avoid changing any application source code between the VMS and the Windoze node.

I have tried 10s of permutations of !DEC$ PSECT ALIGN, and !DEC$ ATTRIBUTE ALIGN but nothing puts the common address where I want it.  On the VMS node, this address alignment is accomplished by the Linker, the Visual Studio 2008 linker seems to ignore these attemps to align the addresses.

Any further suggestions are appreciated

using:

Microsoft Visual Studio 2008 Version 9.0.30729.1 SP Microsoft .NET Framework Version 3.5 SP1

Installed Edition: Professional

Microsoft Visual Basic 2008   91605-270-4561165-60743 Microsoft Visual Basic 2008

Microsoft Visual C# 2008   91605-270-4561165-60743 Microsoft Visual C# 2008

Microsoft Visual C++ 2008   91605-270-4561165-60743 Microsoft Visual C++ 2008

Intel(R) Visual Fortran     Package ID: w_fcompxe_2013_sp1.0.103 Intel(R) Visual Fortran Composer XE 2013 SP1  Integration for Microsoft Visual Studio* 2008, 14.0.0063.2008, Copyright (C) 2002-2013 Intel Corporation * Other names and brands may be claimed as the property of others.

Steve

[Steven_L_Intel1]

The Windows object format can't specify alignment that large. Use an allocatable array instead and ATTRIBUTES ALIGN.

[Steven_F_1]

i have tried ATTRIBUTES ALIGN in all kinds of approaches.  It never seems to work or affect the allignment of where the linker positions the object I am trying to align.  I understand that I am trying to make a Windoze POS act like a VMS node, but I do not have the freedom to redesign the data structures away from plain vanilla Fortran Commons which are aligned VIA VMS PSECT statements.  If it cant be done, I guess it cant be done.  Unfortunately, MapViewOfFileEx seems to require a base address on a 64K boundary for it to work.

[Steven_L_Intel1]

It's usually not difficult to move from COMMONs to allocatble module variables. How many variables in the COMMON?

While I would not ordinarily suggest this, look at the "dynamic common" feature of the compiler. This lets you supply your own allocation procedure for what otherwise looks like a COMMON block. You are correct - WIndows is no VMS.

[Steven_F_1]

I dont doubt it is not hard to redesign away from commons.  the problem is I have a common based VMS system with HUNDREDS of variables in various global sections.  I want to be able to move the code back and forth between it and windows without changing much to support the architecture change.  As far as I can tell, I only need to get a common to appear on a 64K boundary then I can use windows file mapping routines to make it all look just like a VMS node.  In this case, an inch is as good as a mile...

[Steven_L_Intel1]

This is why I suggested dynamic common.

[jimdempseyatthecove]

Steven F.

Experiment with a) remove any attempts at alignment in your IVF code. b) create a MASM file that explicitly locates the name of the section for the common (likely a named common in your case) at the origin you desire. I cannot tell you how to do this off hand without doing research. Look at old code examples for specifying where the VGA page frame is located. You may need to insert at lease 1 byte of data, though 0 bytes may work too. c) assemble to .obj (allignCommon.obj) assure this .obj is linked first. The linker tends to concatinate sections. As to if this will cause problems elsewhere I cannot say.

Jim Dempsey