13,870
社区成员
发帖
与我相关
我的任务
分享Tc编译模式问题 有经验的请出手!
我在TC3.0,DOS下编程时遇到两个问题:
1.所有书上都说单个的源文件,目标文件都不能超过64K,但我的程序源文件,目标文件和可
执行文件都远远超过了这个限制,不过运行正常为什么?
2.为了符合64K这个限制,我把文件拆成几个模块后,只有在huge模式下编译后才能运行,为
什么?(虽然我用了huge指针,但并没有听说过必须用huge模式编译才行呀).
1.所有书上都说单个的源文件,目标文件都不能超过64K,但我的程序源文件,目标文件和可
执行文件都远远超过了这个限制,不过运行正常为什么?
2.为了符合64K这个限制,我把文件拆成几个模块后,只有在huge模式下编译后才能运行,为
什么?(虽然我用了huge指针,但并没有听说过必须用huge模式编译才行呀).
...全文
请发表友善的回复…
发表回复
skt642 2001-05-31
- 打赏
- 举报
24456关注！
wxz 2000-12-25
- 打赏
- 举报
兄弟，王士元的那个破烂扔垃圾桶算了。
DOS下，C有6种编译模式，第一种Tiny模式用于编译成com文件，第2种small模式用于编译code和data都小于64k即都在单一段的情况，.....
总之，采用compact模式吧。如果老兄确实是做大大项目，那么用huge吧.
DOS下，C有6种编译模式，第一种Tiny模式用于编译成com文件，第2种small模式用于编译code和data都小于64k即都在单一段的情况，.....
总之，采用compact模式吧。如果老兄确实是做大大项目，那么用huge吧.
storyxlx 2000-12-24
- 打赏
- 举报
1。文件不能超过64k，是TC2.0的限制，TC3.0用DPMI，它在保护模式下运行，没有这个限制（win31也用DPMI，参见《windows奥秘》和《windows抛析》）。
2。因为你的程序没有使用DPMI，当然还要受16位的64k壁垒之苦，Borland huge模式使用了宏代换（参见Borland自己的库函数源码），用时间换取空间，所以你的程序运行无误。
2。因为你的程序没有使用DPMI，当然还要受16位的64k壁垒之苦，Borland huge模式使用了宏代换（参见Borland自己的库函数源码），用时间换取空间，所以你的程序运行无误。
BCB 2000-12-04
- 打赏
- 举报
与模式有关系：
dos每一个段只能<64k,程序有三类型的段：数据段，代码段，堆栈段;
你可能是小模式态，代码<64k,数据<64k,两者之和<128k；
若是极小模式，只有一个段，两者之和只能<64k,可转换成.com;
huge模式要分开编译，每一部分是一个代码段64k,多个代码段
合在一起就可大于64k了;
dos每一个段只能<64k,程序有三类型的段：数据段，代码段，堆栈段;
你可能是小模式态，代码<64k,数据<64k,两者之和<128k；
若是极小模式，只有一个段，两者之和只能<64k,可转换成.com;
huge模式要分开编译，每一部分是一个代码段64k,多个代码段
合在一起就可大于64k了;
BCB 2000-12-04
- 打赏
- 举报
TC 好象是远古时代的文物吧,
还有DOS什么的，请考古学家
出山
还有DOS什么的，请考古学家
出山
项目花园范德彪 2000-12-04
- 打赏
- 举报
BC3.1倒是有，那我的一个哥们说， 网上也可以DOWN的，不知在哪，用Small才是你说的
单个的源程序其编译生成的代码和数据量均不能超过64K，但也只是在80286以下的机子上，
现在的地址是怎么 回事，就不得而知了，
另个，com确实比EXE的文件小，还快
单个的源程序其编译生成的代码和数据量均不能超过64K，但也只是在80286以下的机子上，
现在的地址是怎么 回事，就不得而知了，
另个，com确实比EXE的文件小，还快
项目花园范德彪 2000-12-04
- 打赏
- 举报
没有人用，就别回答呀，我怎么越看越不懂了，
问问题的兄弟是不是要做一个 .com的文件，这要用Tiny模式，在64K以内，才能用EXEtoCom转
问问题的兄弟是不是要做一个 .com的文件，这要用Tiny模式，在64K以内，才能用EXEtoCom转
gall 2000-12-02
- 打赏
- 举报
人在项目中，身不由己，1M的内存，8M的DOC（相当于硬盘）386的PC104，硬件平台决定了用DOS，不过BC3.1 倒确实不错，我以前也用过，可是早就没有了，哪位仁兄那有，肯惠赐否？
关于64K的限制我是在王士元编的C高级实用程序设计91页看的，原话是：无论采用那种编译模式，单个的源程序其编译生成的代码和数据量均不能超过64K，对于超过的源程序可以...
拆分...另外一本书上也说:任何一个单个的原语言模块不能超过64K,必须把超过的分成若干模块
再把它们的.OBJ连接起来建立.EXE文件
看来只能认为他们说错了.
关于64K的限制我是在王士元编的C高级实用程序设计91页看的，原话是：无论采用那种编译模式，单个的源程序其编译生成的代码和数据量均不能超过64K，对于超过的源程序可以...
拆分...另外一本书上也说:任何一个单个的原语言模块不能超过64K,必须把超过的分成若干模块
再把它们的.OBJ连接起来建立.EXE文件
看来只能认为他们说错了.
Winsky 2000-12-01
- 打赏
- 举报
另外对于第二个问题我建议你使用Borland C++ 2.0 或者 3.1 编译连接，因为 Turbo C++ 1.0 ～ 3.0 在内存管理方面都存在一些bug。
Winsky 2000-12-01
- 打赏
- 举报
1.所有书上都说单个的源文件,目标文件都不能超过64K,但我的程序源文件,目标文件和可
执行文件都远远超过了这个限制,不过运行正常为什么?
答：源文件和目标文件没有这个限制。如果你生成的exe文件中用的指针和指向的数据凑巧被编译连接到同一个64k段中，运行也会很正常，不过数据太大时就会出问题，你的程序就是这个情况，可能只是因为你的数据较小，没有出问题而已。
2.为了符合64K这个限制,我把文件拆成几个模块后,只有在huge模式下编译后才能运行,为
什么?(虽然我用了huge指针,但并没有听说过必须用huge模式编译才行呀).
答：使用large指针虽然可以访问其它数据段的内容，但访问时指针增量不能超过64k段，使用large模式编译时huge指针的物理地址转换方法和huge方式时的huge指针的物理地址转换方法不同，huge模式下的huge指针才是真正的huge指针。
执行文件都远远超过了这个限制,不过运行正常为什么?
答：源文件和目标文件没有这个限制。如果你生成的exe文件中用的指针和指向的数据凑巧被编译连接到同一个64k段中，运行也会很正常，不过数据太大时就会出问题，你的程序就是这个情况，可能只是因为你的数据较小，没有出问题而已。
2.为了符合64K这个限制,我把文件拆成几个模块后,只有在huge模式下编译后才能运行,为
什么?(虽然我用了huge指针,但并没有听说过必须用huge模式编译才行呀).
答：使用large指针虽然可以访问其它数据段的内容，但访问时指针增量不能超过64k段，使用large模式编译时huge指针的物理地址转换方法和huge方式时的huge指针的物理地址转换方法不同，huge模式下的huge指针才是真正的huge指针。
mywater 2000-12-01
- 打赏
- 举报
你做工控吗？
就是，也不用非得在Dos下面编程,并且使用TC30!
我的建议：
Dos:
WC
BC
Windows:
VC
CB
就是，也不用非得在Dos下面编程,并且使用TC30!
我的建议：
Dos:
WC
BC
Windows:
VC
CB
cwhelucky 2000-12-01
- 打赏
- 举报
对于你的拆分来讲，其编译时将其同样写入一个文件的，等于没有拆分，执行文件没有大小限制，因为其为exe格式，还有单个文件正常，因为你用的编译器，支持huge模式。
Searph 2000-12-01
- 打赏
- 举报
这些东西都快忘光光了，建议你不要再和dos纠缠不清了，呵呵~~
原文件不大于64K没什么道理，这和dos16位指针有什么关系？
目标文件不大于64K好像只有.com文件有这个限制，exe是允许跨段的，无论是code还是data段，只是根据是否跨段使用不同的编译模式，如果code和data都跨段了就使用huge模式。
也不知道记得的这些还对不对，有没有dos老鸟讲一下？
原文件不大于64K没什么道理，这和dos16位指针有什么关系？
目标文件不大于64K好像只有.com文件有这个限制，exe是允许跨段的，无论是code还是data段，只是根据是否跨段使用不同的编译模式，如果code和data都跨段了就使用huge模式。
也不知道记得的这些还对不对，有没有dos老鸟讲一下？
