Jeff,
Janet and I just looked at the DLLs on her Windows system for EPICS base 3-14.12.1 on both win32-x86 and windows-x64.
Here is what we found with dumpbin /exports
- Functions are are defined with both epicsShareFunc and epicsShare API are decorated on win32-x86 and undecorated on windows-x64.
- Functions that are defined with epicsShareFunc but not epicsShareAPI are undecorated on both architectures.
Can you please repeat this test on your end? I would be very surprised if you find undecorated names on win32-x86 for functions defined with both epicsShareFunc and epicsShareAPI.
Mark
________________________________
From: Jeff Hill [mailto:[email protected]]
Sent: Fri 10/21/2011 10:10 AM
To: Mark Rivers
Cc: [email protected]
Subject: RE: windows-x64 problem
Perhaps there is a difference in how you are building the DLL. In base the
dll link looks like this. We are not specifying a .def file.
link /nologo /subsystem:windows /dll /LTCG /incremental:no /opt:ref /release
/version:3.15 /fixed:no /debug /implib:xxx.lib /out:xxx.dll
xxx.obj ..\..\..\..\lib\win32-x86\yyy.lib ..\..\..\..\lib\win32-x86\zzz.lib
..\..\..\..\lib\win32-x86\Com.lib ws2_32.lib
> Do you know how to see the output of the C
> preprocessor in Visual Studio?
The "compiler command line" cl.exe /E switch copies the result from the C
preprocessor to stdout ( only ms would name their compiler executable cl.exe
:).
Yes, the issues with the C preprocessor can be a bit complicated especially
when you have dll's that call dll's that call dll's. I just now realized
that the previous example I sent is subtly flawed. See the corrected version
below. Note the "#include "shareLib.h" added in the example. This is
necessary to force epicsShareFunc and epicsShareAPI to change from import
(for the mutex in libCom) to export for the function "exported". This
mistake is a common problem with successfully exporting the function when
there are many DLLs BTW.
/*
* this is my dll's header
*/
ifndef xxxh
#define xxxh
#include <cstdio>
#include <exception>
#include <typeinfo>
#ifdef epicsExportSharedSymbols
# define epicsExportSharedSymbols_xxxh
# undef epicsExportSharedSymbols
#endif
#include "epicsMutex.h"
#ifdef epicsExportSharedSymbols_xxxh
# define epicsExportSharedSymbols
#endif
#include "shareLib.h"
epicsShareFunc unsigned epicsShareAPI exported ();
#endif // ifndef xxxh
/*
* this is my dll's source file
*/
#include <cstdio>
#include <exception>
#include <typeinfo>
#include "epicsEvent.h"
#define epicsExportSharedSymbols
#include "xxx.h"
unsigned epicsShareAPI exported ()
{
}
Jeff
______________________________________________________
Jeffrey O. Hill Email [email protected]
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA FAX 505 665 5107
Message content: TSPA
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925
> -----Original Message-----
> From: Mark Rivers [mailto:[email protected]]
> Sent: Friday, October 21, 2011 8:37 AM
> To: Jeff Hill
> Cc: [email protected]
> Subject: RE: windows-x64 problem
>
> Hi Jeff,
>
> My library is using epicsShareFunc and epicsShareAPI. But for some reason
> it is exporting decorated symbols on 32-bit unless I also use a .DEF file.
> That disagrees with the MSDN documentation
>
> http://msdn.microsoft.com/en-us/library/bb687850.aspx
>
> and with your message below, so perhaps I'm doing something wrong. I'll
> investigate further.
>
> Do you know how to see the output of the C preprocessor in Visual Studio?
> My library is using some fairly complex macros, and I want to make sure
> that in the end my code is ending up with __declspec(dllexport) and
> __stdcall.
>
> Thanks,
> Mark
>
>
> -----Original Message-----
> From: Jeff Hill [mailto:[email protected]]
> Sent: Friday, October 21, 2011 9:30 AM
> To: Mark Rivers
> Cc: [email protected]
> Subject: RE: windows-x64 problem
>
> Mark,
>
> In base we generally don't use the .DEF file mechanism for exporting
> symbols. Instead have a look at libCom/misc/shareLib.h. To export a symbol
> from a dll the code below illustrates the general pattern. This approach
> has
> its negatives, but at least we don't have to maintain the DEF file. This
> approach appears to be working also on 64 bit systems. There are two
> issues.
>
> 1) exporting the symbol - use epicsShareFunc
> 2) pascal calling mechanism for visual basic and others - use
> epicsShareAPI
>
> /*
> * this is my dll's header
> */
> ifndef xxxh
> #define xxxh
>
> #include <cstdio>
> #include <exception>
> #include <typeinfo>
>
> #ifdef epicsExportSharedSymbols
> # define epicsExportSharedSymbols_xxxh
> # undef epicsExportSharedSymbols
> #endif
>
> #include "epicsMutex.h"
>
> #ifdef epicsExportSharedSymbols_xxxh
> # define epicsExportSharedSymbols
> #endif
>
> epicsShareFunc unsigned epicsShareAPI exported ();
>
> #endif // ifndef xxxh
>
> /*
> * this is my dll's source file
> */
> #include <cstdio>
> #include <exception>
> #include <typeinfo>
>
> #include "epicsEvent.h"
>
> #define epicsExportSharedSymbols
> #include "xxx.h"
>
> unsigned epicsShareAPI exported ()
> {
> }
>
> Jeff
> ______________________________________________________
> Jeffrey O. Hill Email [email protected]
> LANL MS H820 Voice 505 665 1831
> Los Alamos NM 87545 USA FAX 505 665 5107
>
> Message content: TSPA
>
> With sufficient thrust, pigs fly just fine. However, this is
> not necessarily a good idea. It is hard to be sure where they
> are going to land, and it could be dangerous sitting under them
> as they fly overhead. -- RFC 1925
>
>
> > -----Original Message-----
> > From: Mark Rivers [mailto:[email protected]]
> > Sent: Thursday, October 20, 2011 4:28 PM
> > To: [email protected]
> > Cc: [email protected]
> > Subject: FW: windows-x64 problem
> >
> > Jeff,
> >
> > I'm having a problem with DLLs on 64-bit Windows. I am building a DLL
> > that will be called from IDL (similar to calling from Visual Basic).
> The
> > DLL must have undecorated names for the entry points. For 32-bit
> Windows
> > we have been using a .DEF file to achieve this, and it works fine.
> > However, when we build for 64-bit Windows the names are undecorated by
> > default, and I get a whole bunch of warnings if I use the .DEF file.
> >
> > This is in the EPICS extension ezcaIDL. If I delete the .DEF file then
> > 64-bit Windows builds fine, but the 32-bit build has decorated names and
> > so does not work.
> >
> > Have you seen this problem. Are we doing something wrong?
> >
> > link /nologo /subsystem:windows /dll /LTCG /incremental:no /opt:ref
> > /release /MACHINE:X64 /manifest /implib:ezcaIDL
> > .lib /out:ezcaIDL.dll /def:../ezcaIDL.def ezcaIDL.obj
> > ..\\..\\..\\lib\\windows-x64\\ezca.lib ..\\..\\..\\lib\\windows-
> > x64\\EzcaScan.lib H:\\epics\\base-3.14.12.1\\lib\\windows-x64\\ca.lib
> > H:\\epics\\base-3.14.12.1\\lib\\windows-x64\\Com.lib ws2_32.lib
> > advapi32.lib user32.lib
> > ezcaIDL.obj : warning LNK4197: export 'EzcaMonitorQueue_Zero' specified
> > multiple times; using first specification
> > ezcaIDL.obj : warning LNK4197: export 'EzcaMonitorQueue_Clear' specified
> > multiple times; using first specification
> > ezcaIDL.obj : warning LNK4197: export 'EzcaMonitorQueue_Add' specified
> > multiple times; using first specification
> > ezcaIDL.obj : warning LNK4197: export 'EzcaMonitorQueue_Get' specified
> > multiple times; using first specification
> >
> > Thanks,
> >
> > Mark
> >
> >
> >
> >
> >
> > ________________________________
> >
> > From: Mark Rivers
> > Sent: Thu 10/20/2011 5:15 PM
> > To: Janet Anderson
> > Subject: RE: windows-x64 problem
> >
> >
> > Hi Janet,
> >
> > No, IDL does not work with the decorated names. I built with no .DEF
> > file. That creates undecorated names on 64-bit, but decorated names on
> > 32-bit.
> >
> > Now I assign the environment variable to the 64-bit DLL and run the 64-
> bit
> > version of IDL. It works.
> >
> > H:\epics\extensions_devel\src\ezcaIDL>set
> > EZCA_IDL_SHARE=H:\epics\extensions_devel\bin\windows-x64\ezcaIDL.dll
> >
> > H:\epics\extensions_devel\src\ezcaIDL>"c:\Program
> > Files\ITT\IDL\IDL81\bin\bin.x86_64\idl.exe"
> > IDL Version 8.1, Microsoft Windows (Win32 x86_64 m64). (c) 2011, ITT
> > Visual Information Solutions
> > IDL> t = caget('13BMD:m1', v)
> > IDL> print, t, v
> > 0 -8.4500098
> >
> >
> > Now I assign the environment variable to the 32-bit DLL and run the 32-
> bit
> > version of IDL. It fails.
> >
> > H:\epics\extensions_devel\src\ezcaIDL>set
> > EZCA_IDL_SHARE=H:\epics\extensions_devel\bin\win32-x86\ezcaIDL.dll
> >
> > H:\epics\extensions_devel\src\ezcaIDL>"c:\Program
> > Files\ITT\IDL\IDL81\bin\bin.x86_64\idl.exe" -32
> > IDL Version 8.1, Microsoft Windows (Win32 x86 m32). (c) 2011, ITT Visual
> > Information Solutions
> > IDL> t = caget('13BMD:m1', v)
> > % CALL_EXTERNAL: Error loading sharable executable.
> > Symbol: ezcaIDLGetCountAndType, File =
> > H:\epics\extensions_devel\bin\win32-x86\ezcaIDL.dll
> > The specified procedure could not be found.
> > % Execution halted at: CALL_EZCA 113
> H:\idl_user\epics\ezcaIDL.pro
> > % CAGETCOUNTANDTYPE 324
> > H:\idl_user\epics\ezcaIDL.pro
> > % CAGET 479
> H:\idl_user\epics\ezcaIDL.pro
> > % CALL_EZCA 111
> H:\idl_user\epics\ezcaIDL.pro
> > % CAINIT 1666
> H:\idl_user\epics\ezcaIDL.pro
> > % $MAIN$
> >
> > So the linker must produce the undecorated names for IDL to be able to
> > find them. That is why we used the .DEF file originally. What's
> strange
> > is that the for 64-bits it creates undecorated names by default, and
> > generates warnings if we supply a .DEF file.
> >
> > Mark
> >
> >
> > ________________________________
> >
> > From: Janet Anderson [mailto:[email protected]]
> > Sent: Thu 10/20/2011 1:33 PM
> > To: Mark Rivers
> > Subject: Re: windows-x64 problem
> >
> >
> > Hi Mark,
> >
> > I think it might be ok for the x86 names to be decorated and the x64
> name
> > to have no decoration.
> > Does the x86 dll work when created with NO def file? I thinks that the
> x86
> > decorations are different than x64decorations.
> >
> > Janet
> >
> > Mark Rivers wrote:
> >
> > Hi Janet,
> >
> > Something is strange here. I only get the warnings when I build for
> > windows-x64, not when I build for win32-x86.
> >
> > I then tried renaming ezcaIDL.def as you suggested. The eliminates
> > the warnings. On windows-x64 the ezcaIDL.dll file looks fine, it is
> > exporting the correct symbols:
> >
> > H:\epics\extensions_devel\src\ezcaIDL>dumpbin /exports
> > ..\..\bin\windows-x64\ezcaIDL.dll
> > Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
> > Copyright (C) Microsoft Corporation. All rights reserved.
> >
> > Dump of file ..\..\bin\windows-x64\ezcaIDL.dll
> > File Type: DLL
> > Section contains the following exports for ezcaIDL.dll
> > 00000000 characteristics
> > 4EA05FBD time date stamp Thu Oct 20 12:51:57 2011
> > 0.00 version
> > 1 ordinal base
> > 53 number of functions
> > 53 number of names
> > ordinal hint RVA name
> > 1 0 00060A50 EzcaAddMonitorArray
> > 2 1 00060760 EzcaCheckMonitorArray
> > 3 2 000608E0 EzcaClearMonitorArray
> > 4 3 0005FFC0 EzcaDebug
> > 5 4 00060D70 EzcaGetArrayEventValues
> > 6 5 00060DF0 EzcaGetArrayTypeCount
> > 7 6 00060EB0 EzcaGetArrayValues
> > 8 7 00060F80 EzcaGetError
> > 9 8 00060820 EzcaGetMonitorArray
> > 10 9 0005FFA0 EzcaInit
> > 11 A 000600F0 EzcaMonitorQueue_Add
> > 12 B 00060090 EzcaMonitorQueue_Clear
> > 13 C 00060160 EzcaMonitorQueue_Get
> > 14 D 00060030 EzcaMonitorQueue_Zero
> > 15 E 00061130 EzcaMonitorScan_Add
> > 16 F 00060B70 EzcaMonitorScan_Clear
> > 17 10 00060B40 EzcaMonitorScan_Get
> > 18 11 00060AE0 EzcaMonitorScan_Zero
> > 19 12 00060260 EzcaPendEvent
> > 20 13 00060BD0 EzcaPutArrayEventValues
> > 21 14 00060CA0 EzcaPutArrayValues
> > 22 15 00060190 EzcaSearchList
> > 23 16 0005FF80 EzcaSetPendTime
> > 24 17 00061090 EzcaTimeStamp
> > 25 18 00060000 EzcaVersion
> > 26 19 00060290 ezcaIDLAutoErrorMessageOff
> > 27 1A 000602B0 ezcaIDLAutoErrorMessageOn
> > 28 1B 000610B0 ezcaIDLClearMonitor
> > 29 1C 00060310 ezcaIDLDebugOff
> > 30 1D 00060330 ezcaIDLDebugOn
> > 31 1E 00060350 ezcaIDLEndGroup
> > 32 1F 00060480 ezcaIDLEndGroupWithReport
> > 33 20 00060730 ezcaIDLGet
> > 34 21 00061110 ezcaIDLGetControlLimits
> > 35 22 00060590 ezcaIDLGetCountAndType
> > 36 23 00060370 ezcaIDLGetEnumStrings
> > 37 24 00060650 ezcaIDLGetErrorString
> > 38 25 000610F0 ezcaIDLGetGraphicLimits
> > 39 26 00060710 ezcaIDLGetPrecision
> > 40 27 00060500 ezcaIDLGetRetryCount
> > 41 28 000606F0 ezcaIDLGetStatus
> > 42 29 00060520 ezcaIDLGetTimeout
> > 43 2A 000606D0 ezcaIDLGetUnits
> > 44 2B 00060570 ezcaIDLNewMonitorValue
> > 45 2C 000606B0 ezcaIDLPerror
> > 46 2D 00060620 ezcaIDLPut
> > 47 2E 000605F0 ezcaIDLPutOldCa
> > 48 2F 000610D0 ezcaIDLSetMonitor
> > 49 30 00060540 ezcaIDLSetRetryCount
> > 50 31 00060550 ezcaIDLSetTimeout
> > 51 32 00060360 ezcaIDLStartGroup
> > 52 33 000602D0 ezcaIDLTraceOff
> > 53 34 000602F0 ezcaIDLTraceOn
> > Summary
> > 17000 .data
> > 8000 .pdata
> > 22000 .rdata
> > 2000 .reloc
> > 1000 .rsrc
> > 6E000 .text
> > H:\epics\extensions_devel\src\ezcaIDL>
> >
> > Note the exported names are undecorated. However, the win32-x86
> > version is no good, the names are decorated. These were built on the
> same
> > machine, same compiler, just changing the EPICS_HOST_ARCH and which
> > vcvarsall.bat file was invoked. So it looks like the .def file is
> needed
> > on 32-bit, but should not be used on 64-bit. Why?
> >
> >
> > H:\epics\extensions_devel\src\ezcaIDL>dumpbin/exports
> > ..\..\bin\win32-x86\ezcaIDL.dll
> > Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
> > Copyright (C) Microsoft Corporation. All rights reserved.
> >
> > Dump of file ..\..\bin\win32-x86\ezcaIDL.dll
> > File Type: DLL
> > Section contains the following exports for ezcaIDL.dll
> > 00000000 characteristics
> > 4EA05FF7 time date stamp Thu Oct 20 12:52:55 2011
> > 0.00 version
> > 1 ordinal base
> > 53 number of functions
> > 53 number of names
> > ordinal hint RVA name
> > 1 0 00049660 _EzcaAddMonitorArray@8
> > <mailto:_EzcaAddMonitorArray@8> <mailto:_EzcaAddMonitorArray@8>
> > 2 1 00049590 _EzcaCheckMonitorArray@8
> > <mailto:_EzcaCheckMonitorArray@8> <mailto:_EzcaCheckMonitorArray@8>
> > 3 2 00049620 _EzcaClearMonitorArray@8
> > <mailto:_EzcaClearMonitorArray@8> <mailto:_EzcaClearMonitorArray@8>
> > 4 3 00048F60 _EzcaDebug@8 <mailto:_EzcaDebug@8>
> > <mailto:_EzcaDebug@8>
> > 5 4 000497E0 _EzcaGetArrayEventValues@8
> > <mailto:_EzcaGetArrayEventValues@8> <mailto:_EzcaGetArrayEventValues@8>
> > 6 5 00049830 _EzcaGetArrayTypeCount@8
> > <mailto:_EzcaGetArrayTypeCount@8> <mailto:_EzcaGetArrayTypeCount@8>
> > 7 6 00049880 _EzcaGetArrayValues@8
> > <mailto:_EzcaGetArrayValues@8> <mailto:_EzcaGetArrayValues@8>
> > 8 7 000498D0 _EzcaGetError@8 <mailto:_EzcaGetError@8>
> > <mailto:_EzcaGetError@8>
> > 9 8 000495E0 _EzcaGetMonitorArray@8
> > <mailto:_EzcaGetMonitorArray@8> <mailto:_EzcaGetMonitorArray@8>
> > 10 9 00048F40 _EzcaInit@8 <mailto:_EzcaInit@8>
> > <mailto:_EzcaInit@8>
> > 11 A 00049040 _EzcaMonitorQueue_Add@8
> > <mailto:_EzcaMonitorQueue_Add@8> <mailto:_EzcaMonitorQueue_Add@8>
> > 12 B 00049000 _EzcaMonitorQueue_Clear@8
> > <mailto:_EzcaMonitorQueue_Clear@8> <mailto:_EzcaMonitorQueue_Clear@8>
> > 13 C 00049090 _EzcaMonitorQueue_Get@8
> > <mailto:_EzcaMonitorQueue_Get@8> <mailto:_EzcaMonitorQueue_Get@8>
> > 14 D 00048FC0 _EzcaMonitorQueue_Zero@8
> > <mailto:_EzcaMonitorQueue_Zero@8> <mailto:_EzcaMonitorQueue_Zero@8>
> > 15 E 000499B0 _EzcaMonitorScan_Add@8
> > <mailto:_EzcaMonitorScan_Add@8> <mailto:_EzcaMonitorScan_Add@8>
> > 16 F 00049700 _EzcaMonitorScan_Clear@8
> > <mailto:_EzcaMonitorScan_Clear@8> <mailto:_EzcaMonitorScan_Clear@8>
> > 17 10 000496E0 _EzcaMonitorScan_Get@8
> > <mailto:_EzcaMonitorScan_Get@8> <mailto:_EzcaMonitorScan_Get@8>
> > 18 11 000496A0 _EzcaMonitorScan_Zero@8
> > <mailto:_EzcaMonitorScan_Zero@8> <mailto:_EzcaMonitorScan_Zero@8>
> > 19 12 00049160 _EzcaPendEvent@8 <mailto:_EzcaPendEvent@8>
> > <mailto:_EzcaPendEvent@8>
> > 20 13 00049740 _EzcaPutArrayEventValues@8
> > <mailto:_EzcaPutArrayEventValues@8> <mailto:_EzcaPutArrayEventValues@8>
> > 21 14 00049790 _EzcaPutArrayValues@8
> > <mailto:_EzcaPutArrayValues@8> <mailto:_EzcaPutArrayValues@8>
> > 22 15 000490C0 _EzcaSearchList@8
> > <mailto:_EzcaSearchList@8> <mailto:_EzcaSearchList@8>
> > 23 16 00048F20 _EzcaSetPendTime@8
> > <mailto:_EzcaSetPendTime@8> <mailto:_EzcaSetPendTime@8>
> > 24 17 00049910 _EzcaTimeStamp@8 <mailto:_EzcaTimeStamp@8>
> > <mailto:_EzcaTimeStamp@8>
> > 25 18 00048F90 _EzcaVersion@8 <mailto:_EzcaVersion@8>
> > <mailto:_EzcaVersion@8>
> > 26 19 00049180 _ezcaIDLAutoErrorMessageOff@8
> > <mailto:_ezcaIDLAutoErrorMessageOff@8>
> > <mailto:_ezcaIDLAutoErrorMessageOff@8>
> > 27 1A 00049190 _ezcaIDLAutoErrorMessageOn@8
> > <mailto:_ezcaIDLAutoErrorMessageOn@8>
> > <mailto:_ezcaIDLAutoErrorMessageOn@8>
> > 28 1B 00049930 _ezcaIDLClearMonitor@8
> > <mailto:_ezcaIDLClearMonitor@8> <mailto:_ezcaIDLClearMonitor@8>
> > 29 1C 000491C0 _ezcaIDLDebugOff@8
> > <mailto:_ezcaIDLDebugOff@8> <mailto:_ezcaIDLDebugOff@8>
> > 30 1D 000491D0 _ezcaIDLDebugOn@8
> > <mailto:_ezcaIDLDebugOn@8> <mailto:_ezcaIDLDebugOn@8>
> > 31 1E 000491E0 _ezcaIDLEndGroup@8
> > <mailto:_ezcaIDLEndGroup@8> <mailto:_ezcaIDLEndGroup@8>
> > 32 1F 00049300 _ezcaIDLEndGroupWithReport@8
> > <mailto:_ezcaIDLEndGroupWithReport@8>
> > <mailto:_ezcaIDLEndGroupWithReport@8>
> > 33 20 00049560 _ezcaIDLGet@8 <mailto:_ezcaIDLGet@8>
> > <mailto:_ezcaIDLGet@8>
> > 34 21 00049990 _ezcaIDLGetControlLimits@8
> > <mailto:_ezcaIDLGetControlLimits@8> <mailto:_ezcaIDLGetControlLimits@8>
> > 35 22 00049400 _ezcaIDLGetCountAndType@8
> > <mailto:_ezcaIDLGetCountAndType@8> <mailto:_ezcaIDLGetCountAndType@8>
> > 36 23 00049210 _ezcaIDLGetEnumStrings@8
> > <mailto:_ezcaIDLGetEnumStrings@8> <mailto:_ezcaIDLGetEnumStrings@8>
> > 37 24 000494A0 _ezcaIDLGetErrorString@8
> > <mailto:_ezcaIDLGetErrorString@8> <mailto:_ezcaIDLGetErrorString@8>
> > 38 25 00049970 _ezcaIDLGetGraphicLimits@8
> > <mailto:_ezcaIDLGetGraphicLimits@8> <mailto:_ezcaIDLGetGraphicLimits@8>
> > 39 26 00049540 _ezcaIDLGetPrecision@8
> > <mailto:_ezcaIDLGetPrecision@8> <mailto:_ezcaIDLGetPrecision@8>
> > 40 27 00049360 _ezcaIDLGetRetryCount@8
> > <mailto:_ezcaIDLGetRetryCount@8> <mailto:_ezcaIDLGetRetryCount@8>
> > 41 28 00049520 _ezcaIDLGetStatus@8
> > <mailto:_ezcaIDLGetStatus@8> <mailto:_ezcaIDLGetStatus@8>
> > 42 29 00049380 _ezcaIDLGetTimeout@8
> > <mailto:_ezcaIDLGetTimeout@8> <mailto:_ezcaIDLGetTimeout@8>
> > 43 2A 00049500 _ezcaIDLGetUnits@8
> > <mailto:_ezcaIDLGetUnits@8> <mailto:_ezcaIDLGetUnits@8>
> > 44 2B 000493E0 _ezcaIDLNewMonitorValue@8
> > <mailto:_ezcaIDLNewMonitorValue@8> <mailto:_ezcaIDLNewMonitorValue@8>
> > 45 2C 000494E0 _ezcaIDLPerror@8 <mailto:_ezcaIDLPerror@8>
> > <mailto:_ezcaIDLPerror@8>
> > 46 2D 00049470 _ezcaIDLPut@8 <mailto:_ezcaIDLPut@8>
> > <mailto:_ezcaIDLPut@8>
> > 47 2E 00049440 _ezcaIDLPutOldCa@8
> > <mailto:_ezcaIDLPutOldCa@8> <mailto:_ezcaIDLPutOldCa@8>
> > 48 2F 00049950 _ezcaIDLSetMonitor@8
> > <mailto:_ezcaIDLSetMonitor@8> <mailto:_ezcaIDLSetMonitor@8>
> > 49 30 000493A0 _ezcaIDLSetRetryCount@8
> > <mailto:_ezcaIDLSetRetryCount@8> <mailto:_ezcaIDLSetRetryCount@8>
> > 50 31 000493C0 _ezcaIDLSetTimeout@8
> > <mailto:_ezcaIDLSetTimeout@8> <mailto:_ezcaIDLSetTimeout@8>
> > 51 32 00049200 _ezcaIDLStartGroup@8
> > <mailto:_ezcaIDLStartGroup@8> <mailto:_ezcaIDLStartGroup@8>
> > 52 33 000491A0 _ezcaIDLTraceOff@8
> > <mailto:_ezcaIDLTraceOff@8> <mailto:_ezcaIDLTraceOff@8>
> > 53 34 000491B0 _ezcaIDLTraceOn@8
> > <mailto:_ezcaIDLTraceOn@8> <mailto:_ezcaIDLTraceOn@8>
> > Summary
> > 13000 .data
> > 14000 .rdata
> > 8000 .reloc
> > 1000 .rsrc
> >
> > Thanks,
> > Mark
> >
> >
> > ________________________________
> >
> > From: Janet Anderson [mailto:[email protected]]
> > Sent: Thu 10/20/2011 10:29 AM
> > To: Mark Rivers
> > Subject: Re: windows-x64 problem
> >
> >
> >
> > Hi Mark,
> >
> > I think you may not need the ezcaIDL.def file. Try renaming it and
> > rebuilding. If that does not work, try removing the the EXPORTS line
> > and
> > all lines after it.
> >
> > Janet
> >
> >
> >
> > Mark Rivers wrote:
> >
> >
> > ...
> > It works, producing an ezcaIDL.dll file that I can use from
> > IDL, but I don't like those warnings. Do you know how to get rid of
> them?
> >
> > Thanks,
> > Mark
> >
> >
> >
> > ________________________________
> >
> > From: Mark Rivers
> > Sent: Wed 10/19/2011 4:40 PM
> > To: 'Janet Anderson'
> > Subject: windows-x64 problem
> >
> >
> >
> >
- Replies:
- RE: windows-x64 problem Mark Rivers
- References:
- FW: windows-x64 problem Mark Rivers
- RE: windows-x64 problem Jeff Hill
- RE: windows-x64 problem Mark Rivers
- RE: windows-x64 problem Jeff Hill
- Navigate by Date:
- Prev:
RE: windows-x64 problem Mark Rivers
- Next:
RE: Logging change of state for binary input in Message History of CSS Kasemir, Kay
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: windows-x64 problem Jeff Hill
- Next:
RE: windows-x64 problem Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·