[em2]

[quote]这个问题我也没有解决方法.
我试过.
在VB中读数据的时候定义成 LONG 型的数据.
在32位机上是32位的.在64位机上是64的.
不是固定的.
后来我改用.NET了.
使用 INT16-INT32-INT64严格区分就没问题了.

VB6里我也没办法.实在不行就读2次数据最后自己拼接.
不过好像要是在32位机上可能不能保存64位数据吧.[/quote]
[em14][em14]
VB6是32位编译器,怎么会支持把LONG编译为64位呢?
如果你说的是VB.NET,LONG无论在32位还是64位系统上都是64位整数.

LS照你这么说VB.NET是64位编译器了?

[em2]

[quote]LS照你这么说VB.NET是64位编译器了?[/quote]

应该是吧.
我现在用VS 2008了.里面有64位的组件.并且使用的是.NET框架.

在32位系统中也能做可以运行在64位兼容的程序.
现在已经知道XP-X64 EDITION
VISTA-X64
WIN 7-X64
的64位系统中.如果运行一个纯32位程序,在进程中会显示出来这个进程是32位的.
使用VB.NET2008写的程序默认是兼容二个平台的.也就是说.
做出来的程序,可以在32位平台上运行.也可以在64位平台上运行.
并且在64位平台运行时.进程中没有32位标识.也就是说程序运行在64位状态.是一个64位的程序..

这里的32-64位宽,可能和我原来想的不一样.这里的运行位宽不受程序完全决定.可能(具体我也不知道啦,所以说是可能)是由.NET框架( .net framework)决定的.一个.NET程序不是最终的执行代码.在执行前还要使用IL中间语言.最后由.NET托管运行.

在VS 2008中.可以选择目标程序的运行平台.可以只选32位.或是只选64位.默认是2个都选中.

[em2]

尝试一下:

1. LONG
2. INT64
3. 先定义成string再转化成 cint
4. 先定义成string再转化成 cdbl

一般用1.2就可以解决问题了.

另外,注意考虑楼上的建议:

在VS 2008中.可以选择目标程序的运行平台.可以只选32位.或是只选64位.默认是2个都选中.

[quote][quote][quote]这个问题我也没有解决方法.
我试过.
在VB中读数据的时候定义成 LONG 型的数据.
在32位机上是32位的.在64位机上是64的.
不是固定的.
后来我改用.NET了.
使用 INT16-INT32-INT64严格区分就没问题了.

VB6里我也没办法.实在不行就读2次数据最后自己拼接.
不过好像要是在32位机上可能不能保存64位数据吧.[/quote]
[em14][em14]
VB6是32位编译器,怎么会支持把LONG编译为64位呢?
如果你说的是VB.NET,LONG无论在32位还是64位系统上都是64位整数.
[/quote]
不是编译成64位的.
而是运行时数据读取是64位的.
我使用VB中的GET直接从二进制文件中读一个LONG 型出来.
在32位系统中运行正常.
在64位系统中读取数据后数据是不对的.
这个我已经试过了.
我把要读的数据在VS2008中写成是INT32就正常了.在32-64位系统中都能正确读取数据.[/quote]
VB6编译后已经是机器指令了,它的代码已经固化了,怎么会在64位系统就把LONG变成64位呢?
mov eax, dword ptr [0x4xxxxxxx]
这里是把内存0x4xxxxxxx指向的32位整数移到eax寄存器(也是32位),你到64位系统运行,它也还是32位,怎么会莫名其妙变成64位呢?
当然如果你说的是VB.NET就另当别论,但我前面已经说明是"VB6"了.

.net 中Long 是64位的整形数，VB6中是32位，与操作系统无关，在。net中读64位整形数很简单，在VB6中只能用数组读，然后拼接成64位

或者自己定义一个结构
Type Int64
   low as long
   high As Long
 End Type
用这个结构读出数据