Which LINKER works best for WINxx platform?? 2

[wildcard]

I currently use RTLINK on CLIPPER 5.2b source code.

This results in a 1.6MB .EXE which tells me at link time
that the result uses 399K.

When I run the program (with 580k conventional memory available under WIN98) I have only 95k of FREE memory.

ENVIRONMENT FACTORS ARE:-
DBASE3 FILE STRUCTURE:-
Databases are *.DBF (some with *.DBT memo files)
Index files are *.NDX

In AUTOEXEC.BAT I have
SET CLIPPER=F111 /E:000 /SWAPPATH:C:
In CONFIG.SYS I have
DEVICE=C:\WINDOWS\HIMEM.SYS
DEVICE=C:\WINDOWS\EMM386.EXE NOEMS
DOS=HIGH,UMB
DEVICEHIGH=C:\WINDOWS\IFSHLP

MY PROBLEMS ARE:-
a) Insufficient memory to RUN some DOS tasks
(eg TYPE, PKZIP, PKUNZIP, EDIT)
b) Slow to display alternate sub-menus
(I presume this is internal overlays related)
c) Slow to complete INDEX routines
(I presume because of the small amount of memory)

I searched the prior questions and I see sufficient
dialogue that suggests there may be a better way than
what I am currently using... So...

MY QUESTION IS:-
Is there a more efficient LINKER (or suggested
alternate way of configuring for WINxx) to improve
CA-CLIPPER performance?

Cheers,
Jim Wild

 

[GAstrada]

Use BLINKER 6.0 instead of RTLINK. Check it's manuals and on-line information, and NG for it, to fine-tune your link-edition time, and the behavoir of dynamic overlay managment.
Also check the configuration of the dos shell you open: althoug is suggested "automatic", is a better idea to make 4096 bytes as an initial environment memory.
Also try changing the "noems" word (no expanded memory size) in your emm386 invocation , to "ram", or not word at all. Try the 3 options.
You should use native NTX index, not NDX. This will slow the process of indexing.
By the way, I advise you that Blinker 6.0 seems to be the only linker to make Clipper apps work without major problems under Win 2000.
Good luck ! (and go ahead with your poetry, friend =) )

 

[wildcard]

So please, where do I score a copy of BLINKER?

Thanx,
Jim

 

[GAstrada]

go

http://www.blinkinc.com

good luck, friend !

 

[circes9]

what is the version of RTLINK that you are using?
Your problem may be not in which linker you are using, but in how you have linked your OBJ files.

My experience with NDX vs NTX is that the NTX are much faster in searching and more stable.

 

[wildcard]

Oops. I fibbed. My RTLINK version is 5.2a dated 1993.

Source code comprises 15 modules. I compile each of the
15 *.OBJs then run RTLINK on the following *.LNK file.

UPPERCASE
FI hokes, wildutil 42K + 84K
LIB DBFNDX, GRUMP52, CT
OUTPUT hokes
OVERLAY CODE
BEGINAREA
SECTION FILE debtors 165K
SECTION FILE creditor 171K
SECTION FILE sellmenu 134K
SECTION FILE editmenu, reportmu 88K
SECTION FILE tranmenu, invmenu 58K + 105K
SECTION FILE ordmenu 130K
SECTION FILE costmenu 91K
SECTION FILE housmenu 82K
SECTION FILE genlmenu, jobmenu 58K + 35K
SECTION FILE wildcard 15K
ENDAREA

Before the program got so large I also included my own
WIZARD Report/Label system with relational databases
and executable script files... This I have had to make
into a standalone application (I called it WIZARDRL).

How can I improve on what I am doing?
Thanx team
Jim
<jwild@xtra.co.nz>

 

[circes9]

1. possibly some or all of the 3 Library files you have can be overlayed, that will reduce the size of the footprint.
2. make reportmu, invmenu, and jobmenu their own overlay entry
3. if you want to try the .NTX index scheme, unless you have some literal index file names hard codes in the code (which would require you to remove the '.NDX' part of the file name) should be able to simply remove the DBFNDX file from the linker. Delete all OBJ's then recompile.

All of the above may require some expermentation, but any/all would help in performance of application.

Good luck

 

[wildcard]

Circes9,

Had already experimented with NTX index regime and
am thrilled with the results:-
a) 38% faster to build NTX indexes
b) 32% reduction in diskspace for NTX indexes
c) FILTER/SEEK routines up to 25% faster.

That is impressive.

Have now at your suggestion made all the smaller
modules a separate OVERLAY but could not detect
any improvement thereafter.

The remaining matter is how to OVERLAY Library files.
Any advice would be appreciated.

Thanx team.
Jim

 

[circes9]

Jim,
Glad to hear the NTX helped.
Your origional issues were...

a) Insufficient memory to RUN some DOS tasks
(eg TYPE, PKZIP, PKUNZIP, EDIT)
These will always be problematic. Blinker offers a different function to Clipper &quot;SWPRUN&quot; that may make the difference, however, maybe reconsider why you feel ZIPping and UNZIPping is required while running app. Could some of these requirements best be served by a nice batch program?
If you are trying to print a file via the TYPE commany, maybe &quot;copy to&quot; would be an alternative. TBrowse may be an alternate to your need for calling EDIT.

b) Slow to display alternate sub-menus
(I presume this is internal overlays related)
If believed to be overlay related, prove by placing the PRG with sub-menuing functions in root, not as overlay and recompile, other functions may now suffer, but if your sub-menuing improves, problem is likely overlay related. Possibly experiment with order of overlays. Blinker or EXOSpace may be alternative.

c) Slow to complete INDEX routines
(I presume because of the small amount of memory)

Better with NTX's?

Regarding overlaying LIB...
should be something like this...

BeginArea
File abc
File def
File ghi
Lib 123
Lib 456
EndArea
Some LIB's do like to be overlayed. Unless you have a DOC telling you specifics, expermentation is in order.


Circes9