Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Problem "Out of Memory" while writing BBS door in
#31
Well, once again: gimme a list of used functions. If you do, I'll help you solve the problem, as I said.
SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Reply
#32
First of all, I forgot these two files in the ZIP file I put online:

http://www.wam.umd.edu/~ccb/itm.txt
http://www.wam.umd.edu/~ccb/mon.txt

they are the files that contain the item and monster names for the program, and need to be in the same directory as the EXE (if it ever gets made!)

Now, here you go Na_th_an. I used LIB.EXE to make a LST file out of qb_edr.lib, and went through the lists of routines and picked out the ones I use as well as the ones that I believe are used internally by the library.

http://www.wam.umd.edu/~ccb/edr_inc.txt

I hope the file makes sense. Let me know if you have any questions.

Unfortunately, I'm going away for a few days. I should be back again on Wednesday for a brief spell, and then again the following Monday.

*peace*

Meg.
Reply
#33
you don't necessarily have to worry about whether or not you need all the routines in it. A library is just a set of object modules. Any one module will contain at least one subroutine or function, but it may contain more. If your code references even one routine in that module, the code from the entire module gets linked into your program. However, if no routine in a particular module is referenced, that entire module is ignored by LINK.EXE; none of it gets added to your code. (That's not true of quick libraries, by the way. All code in a .QLB file gets loaded into memory when QB.EXE runs, regardless of whether or not it actually gets used.)

So, you can take unneeded modules out of your .LIB file, but that won't likely help you. It's taking individual unneeded routines out of a single module that might help you. Unfortunately, that's not doable without remaking the .LIB file from scratch.
ravelling Curmudgeon
(geocities sites require copying and pasting URLs.)
I liked spam better when it was something that came in a can.
Windows should be defenestrated.
Reply
#34
Hrm, yeah I included the lib...here's what QBMCX sends to link:

Microsoft ® Overlay Linker Version 3.69
Copyright © Microsoft Corp 1983-1988. All rights reserved.

Object Modules [.OBJ]: /EX /NOE /NODBig Grin:\MED\QBMCX\BRUN45.LIB D:\QB\BBS\DUNGEON.O
BJ+
Object Modules [.OBJ]: BATTLE.OBJ+
Object Modules [.OBJ]: CHARACTR.OBJ+
Object Modules [.OBJ]: EVENT0.OBJ+
Object Modules [.OBJ]: EVENT1.OBJ+
Object Modules [.OBJ]: FUNCTS.OBJ+
Object Modules [.OBJ]: ITEMS.OBJ+
Object Modules [.OBJ]: LISTS.OBJ+
Object Modules [.OBJ]: SPELLS.OBJ+
Object Modules [.OBJ]: USEITEM.OBJ+
Object Modules [.OBJ]: USEITEM2.OBJ
Run File [DBig GrinUNGEON.EXE]: D:\QB\BBS\DUNGEON.EXE
List File [NUL.MAP]: NUL
Libraries [.LIB]: D:\MED\QBMCX\BCOM45.LIB+
Libraries [.LIB]: QB_EDR.LIB

Which looks pretty much identical to what you have. I don't think there's really that many errors, it's probably the case of one error causing an "avalanche"...
Reply
#35
in his command-line but then you link with BCOM45.LIB. Are you mixing runtime libraries with standalone ones? I'm wondering if that's what meg is doing or if he used /O at all on BC.EXE's command-line. I'd suggest always using /O with BC.EXE. That way, BRUN45.LIB won't be needed. (When BRUN45.LIB is used to make the .EXE, BRUN45.EXE gets loaded at runtime, and all of *it* loads into memory, regardless of whether all routines in it are needed or not.)
ravelling Curmudgeon
(geocities sites require copying and pasting URLs.)
I liked spam better when it was something that came in a can.
Windows should be defenestrated.
Reply
#36
Because that's what QB does...?

For stand-alone EXEs QB uses:
/NOD:BRUN45.LIB
and links with BCOM45.LIB

For EXEs requiring BRUN45 QB uses:
/NOD:BCOM45.LIB
and links with BRUN45.LIB

or maybe I'm not understanding the question...
Reply
#37
There's certainly no need to do it, and I can't imagine anything but bad things that could happen by doing it. (Now I'm off to try something.)

Well, I got reminded of why I wouldn't have ever seen QB doing that if it was doing that. All I see on LINK's command-line is reference to a response file, which gets deleted when LINK is done. However, upon undeleting one such file (after telling QB to make a stand-alone executable) and looking in it, I saw no reference to BRUN45.LIB.
ravelling Curmudgeon
(geocities sites require copying and pasting URLs.)
I liked spam better when it was something that came in a can.
Windows should be defenestrated.
Reply
#38
Load QB with QB.QLB (/L), and then make an EXE Smile
Reply
#39
It does do it then. And now that I've figured out that I (for some weird reason) misinterpreted the output from LINK.EXE that you posted, I think I know what it's doing. (Although, I don't know why that line changes, depending on whether or not a quick library is loaded. The quick library seems irrelevant.) The /NOD option tells LINK.EXE to not use any defaut libraries and only use the ones specified on LINK's command-line or in response to its prompt for what libraries to use. That line of input to LINK appears to be just a redundancy to make sure that BRUN45.LIB doesn't get used. (It's redundant because when QB.EXE puts the /O on BC.EXE's command-line, *that* keeps BRUN45.LIB from being used.) However, putting a ":" after the "NOD" with a library name after that appears to be an undocumented feature. My manual doesn't indicate that anything ever goes after the /NOD.

Well, thanks for the opportunity to figure something out.
ravelling Curmudgeon
(geocities sites require copying and pasting URLs.)
I liked spam better when it was something that came in a can.
Windows should be defenestrated.
Reply
#40
Alright, I'm back for a day, but leaving again really soon for a few.

I still haven't managed to get this thing to become an EXE file. I've got it modularized to the point where I can make all the object files, but it looks like the linker (LINK.EXE) is not able to handle the library (QB_EDR.LIB). I get a message that says:

Object Modules [.OBJ]: BATTLE+
Object Modules [.OBJ]: CHARACTR+
Object Modules [.OBJ]: FUNCTS+
Object Modules [.OBJ]: SPELLS+
Object Modules [.OBJ]: ITEMS+
Object Modules [.OBJ]: LISTS+
Object Modules [.OBJ]: USEITEM+
Object Modules [.OBJ]: USEITEM2+
Object Modules [.OBJ]: EVENT0+
Object Modules [.OBJ]: EVENT1
Run File [DUNGEON.EXE]: DUNGEON.EXE
List File [NUL.MAP]:
Libraries [.LIB]: BCOM45.LIB+
Libraries [.LIB]: QB_EDR.LIB
QB_EDR.LIB(TEMPEDR2.BAS) : fatal error L1070: BC_CN : segment size exceeds 64K
pos: 2DCC Record type: 98

Anyone have suggestions? Only things I can think of are:

1. finding a linker that's better able to handle large files (anybody know any good ones?)

2. make a lib file that only contains the routines in qb_edr.lib that i call in my program (or are used internally by the lib). Unfortunately, i have no idea how to do this. I think I could manage building libs out of the existing modules in the lib, but i don't know how to break it down to the level of individual routines...

as always, any feedback is greatly appreciated. you guys have been great so far!

*peace*

Meg.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)