Conference ucrow::desktop_acms

To carry on with this thread, sort of, I am trying to find out whether
or not I can migrate to NT4. Apologies if this has been clearly
covered before, but I've not been able to get into this notes
conference for several months now.
Anyway, I have a VB4 application running under Windows 95 and using
non-blocking Desktop ACMS V2.2 (Winsock) via an inprocess OLE server
written in VC++4.0 and using 1 byte alignemnt. In other words, VC is
calling Desktop ACMS and not VB4. I am currently in the process of
migrating the whole application to NT4, VB5 and VC++5, and am trying
to find out which versions of Desktop ACMS will support NT4. Am I
correct in assuming that I need to relink my OLE server with the V2.2
ECO1 kit with 4 byte alignment in order to get my application to run
under NT4. If so, can I run the ECO1 software Dlls, but leave the
server kit untouched on OpenVMS? I'm asking this because SEPS97 only
appears to endorse V2.2, so I'm going to have problems getting all the
sites to migrate to ECO1.

Thanks,

Farrell.

    Farrell,
    
    > Am I correct in assuming that I need to relink my OLE server with
    > the V2.2 ECO1 kit with 4 byte alignment in order to get my
    > application to run under NT4. 
    
    That appears to be your best choice, although I do not
    think we have actually tried them against NT V4.0. Since it is your
    DLL that is presenting its interface to VB4, you also might be able
    to link your OLE server against the V2.2 NT client DLLs using 1 
    byte alignment. I would favor trying with the ECO1 DLLs though,
    the way they are built was changed to make them easier to link against.
    
    > If so, can I run the ECO1 software Dlls, but leave the server kit
    > untouched on OpenVMS? I'm asking this because SEPS97 only appears to
    > endorse V2.2, so I'm going to have problems getting all the sites to
    > migrate to ECO1.
    
    Yes you should be able to do that. What is SEPS97? ECO1 is worth
    installing if they are prepared to do it. 
    
    /Tom
    

Tom,

thanks for the reply. I'll try it with 1 byte alignment first,
because I don't want to have to redeclare all my workspaces if I
don't have to. SEPS97 is the replacement for DECStep/EASE, and
states the standard software platform for all Digital Internal
Production machines. If I try and go for a version higher, I'll
probably have to fight each European IS manager!

Thanks,

Farrell.

    Farrell,
    
    Whether the ACMSDI.dll is 1 byte or 4 byte aligned should not impact
    your workspaces as such. They usually have to be 1 byte aligned to
    match the backend ACMS task. All the DLL does is copy the workspaces as
    byte arrays and the code does not have knowledge of the data types that
    make up the workspaces. You should be able to keep your OLE DLL 1 byte
    aligned, if that is what it is, and link against the acmsdi.dll that is
    4 byte aligned. So if that turns out to be needed for some reason it
    might not be as bad as it at first seems. The only structure I know of
    in the public interface acmsdi.h that does not align properly is the
    descriptor like ACMSDI_WORKSPACE_OPT for optimized workspaces. It has
    that awkward byte inside the structure that throws things off. If
    acmsdi.dll is 4 byte and your code is 1 byte aligned you can just add
    some padding bytes to your definition of that structure to fill it out
    in your code so both DLLs see it the same way. In V2.3 there will be a
    pragma around the acmsdi.h definitions to force them to be 4 byte
    aligned even if the  calling application is built 1 byte.
    
    Regards
     Tom

Tom,

many thanks for the help. I padded the ACMSDI_WORKSPACE_OPT workspace,
as below, in the ACMSDI.H

typedef struct {
    unsigned int       length;
    ACMSDI_ACCESS_TYPE access;
    ACMSDI_ACCESS_TYPE padding1;
    ACMSDI_ACCESS_TYPE padding2;
    ACMSDI_ACCESS_TYPE padding3;
    void ACMSDI_PTR_PREFIX *data;
} ACMSDI_WORKSPACE_OPT;

I then relinked my OLE server on 1 byte alignment against the 4 byte
aligned ACMSDI.lib, and, using the 4 byte aligned ACMSDI.DLL &
DI_CNV.DLL, everything seems to be running great.

Thanks,

Farrell.