Jeff and Janet,
I am getting different behavior for win32-x86 and windows-x64 that contradicts the MSDN documentation and Jeff's message
http://msdn.microsoft.com/en-us/library/bb687850.aspx <http://msdn.microsoft.com/en-us/library/bb687850.aspx>
When I build for win32-x86 the exports are decorated, when I build for windows-x64 they are undecorated.
Here is a very simple test file, test.c. It defines 2 functions, test1 and test2. test1 is defined using the EPICS <shareLib.h> mechanism, test2 is defined using the Visual Studio directives.
**********************************
#define epicsExportSharedSymbols
#include <shareLib.h>
epicsShareFunc int epicsShareAPI test1()
{
return 0;
}
__declspec(dllexport) int __stdcall test2()
{
return 0;
}
**********************************
Here is my Makefile:
**********************************
include $(TOP)/configure/CONFIG
SHARED_LIBRARIES=YES
LIBRARY_HOST_DEFAULT += test
test_SRCS += test.c
test_LDFLAGS_WIN32 += /manifest
test_SYS_LIBS_WIN32 = ws2_32 advapi32 user32
include $(TOP)/configure/RULES
**********************************
Here is the output when I build for windows-x64.
H:\epics\extensions_devel\src\ezcaIDL>make install.windows-x64
perl H:/epics/base-3.14.12.1/bin/windows-x64/makeMakefile.pl O.windows-x64 ../../..
make -C O.windows-x64 -f ../Makefile TOP=../../.. T_A=windows-x64 install
make[1]: Entering directory `H:/epics/extensions_devel/src/ezcaIDL/O.windows-x64'
cl -c /favor:blend /nologo /D__STDC__=0 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /Ox /GL /W3 /w44355 /MT -I. -I..\\O.Common -I. -I.. -I..\\..\\..\\include\\os\\WIN32 -I..\\..\\..\\include -IH:\\epics\\base-3.14.12.1\\include\\os\\WIN32 -IH:\\epics\\base-3.14.12.1\\include -I..\\..\\..\\include ..\\test.c
test.c
link /nologo /subsystem:windows /dll /LTCG /incremental:no /opt:ref /release /MACHINE:X64 /manifest /implib:test.lib /out:test.dll test.obj ws2_32.lib advapi32.lib user32.lib
Creating library test.lib and object test.exp
Generating code
Finished generating code
mt.exe /manifest test.dll.manifest "/outputresource:test.dll;#2"
Microsoft (R) Manifest Tool version 5.2.3790.2075
Copyright (c) Microsoft Corporation 2005.
All rights reserved.
"Installing shared library ../../../bin/windows-x64/test.dll"
"Installing library ../../../lib/windows-x64/test.lib"
make[1]: Leaving directory `H:/epics/extensions_devel/src/ezcaIDL/O.windows-x64'
Here is the output of dumpbin/exports on that 64-bit DLL file. Note that it is correct, the names are undecorated.
H:\epics\extensions_devel\src\ezcaIDL>dumpbin /exports ..\..\bin\windows-x64\test.dll
Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file ..\..\bin\windows-x64\test.dll
File Type: DLL
Section contains the following exports for test.dll
00000000 characteristics
4EA18AAF time date stamp Fri Oct 21 10:07:27 2011
0.00 version
1 ordinal base
2 number of functions
2 number of names
ordinal hint RVA name
1 0 000067E0 test1
2 1 000067D0 test2
Summary
3000 .data
1000 .pdata
2000 .rdata
1000 .reloc
1000 .rsrc
6000 .text
Here is the output when I build for win32-x86:
H:\epics\extensions_devel\src\ezcaIDL>make install.win32-x86
perl H:/epics/base-3.14.12.1/bin/win32-x86/makeMakefile.pl O.win32-x86 ../../..
make -C O.win32-x86 -f ../Makefile TOP=../../.. T_A=win32-x86 install
make[1]: Entering directory `H:/epics/extensions_devel/src/ezcaIDL/O.win32-x86'
cl -c /nologo /D__STDC__=0 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /Ox /GL /W3 /w44355 /D_WIN32_WINNT=0x0503 /MT -I. -I..\\O.Common -I. -I.. -I..\\..\\..\\include\\os\\WIN32 -I..\\..\\..\\include - IH:\\epics\\base-3.14.12.1\\include\\os\\WIN32 -IH:\\epics\\base-3.14.12.1\\include -I..\\..\\..\\include ..\\test.c
test.c
link /nologo /subsystem:windows /dll /LTCG /incremental:no /opt:ref /release /manifest /implib:test.lib /out:test.dll test.obj ws2_32.lib advapi32.lib user32.lib
Creating library test.lib and object test.exp
Generating code
Finished generating code
mt.exe /manifest test.dll.manifest "/outputresource:test.dll;#2"
Microsoft (R) Manifest Tool version 5.2.3790.2075
Copyright (c) Microsoft Corporation 2005.
All rights reserved.
"Installing shared library ../../../bin/win32-x86/test.dll"
"Installing library ../../../lib/win32-x86/test.lib"
make[1]: Leaving directory `H:/epics/extensions_devel/src/ezcaIDL/O.win32-x86'
Here is the output of dumpbin/exports on the 32-bit DLL. Note that it is incorrect, the names are decorated. WHY???
H:\epics\extensions_devel\src\ezcaIDL>dumpbin /exports ..\..\bin\win32-x86\test.dll
Microsoft (R) COFF/PE Dumper Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file ..\..\bin\win32-x86\test.dll
File Type: DLL
Section contains the following exports for test.dll
00000000 characteristics
4EA18B95 time date stamp Fri Oct 21 10:11:17 2011
0.00 version
1 ordinal base
2 number of functions
2 number of names
ordinal hint RVA name
1 0 00007360 _test1@0 <mailto:_test1@0>
2 1 00007350 _test2@0 <mailto:_test2@0>
Summary
2000 .data
2000 .rdata
1000 .reloc
1000 .rsrc
7000 .text
So when I build for win32-x86 the names are decorated, and it seems like I have to use a .DEF file to get undecorated names. Am I doing something wrong, perhaps in a CONFIG_SITE file or something?
Thanks,
Mark
________________________________
From: Jeff Hill [mailto:[email protected]]
Sent: Fri 10/21/2011 9:29 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
>
>
>
>
- References:
- FW: windows-x64 problem Mark Rivers
- RE: windows-x64 problem Jeff Hill
- Navigate by Date:
- 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
- Navigate by Thread:
- Prev:
RE: windows-x64 problem Mark Rivers
- Next:
seq lib load error (vxworks) Laznovsky Michael
- 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
·