🚀 go-pugleaf

I am part of a team writing a windows 3.0 application that utilizes
ETN's PoweLibW 's library routines to do some specialized database
management.  Under normal circumstances, there are no problems.
However, if we first ran a large application specific tsr, we found
that the windows routine no longer worked correctly (created zero
length index files).  Previous to this, we had integrated another
vendors database software into our application with the same exact
results.  This made us first suspect the tsr, however, in running the
one below which does nothing more than take up the number of paragraphs
in memory equal to the passed argument, the same exact symptoms result
once you reach a specific tsr size.  This was all done running windows
in enhanced mode.  When running in real mode by simply disabling
himem.sys, we have no problems in either case (until of course we
run out of memory).  This has now made us suspect that a large tsr
is forcing windows to start using extended memory and something is
going wrong here.  Anyone know of any specific problems in himem.sys
that could shed some light?

Other incidentals, this does not appear to be any conflict between
dos/windows device drivers because the same thing happens even if
himem.sys is the only device loaded.

--test tsr--
main(int argc, char *argv[])
{
	unsigned int wParagraphs = 0;

	if (argc != 2) {
		printf("usage: %s: <number of paragraphs to grab up>\n", argv[0]);
		return -1;
	}

	sscanf(argv[1],"%d",&wParagraphs);

	if (wParagraphs == 0) {
		printf("usage: %s: <number of paragraphs to grab up>\n", argv[0]);
		return -1;
	}

	bdos(0x31,wParagraphs,0);
}


-- 
Jeff Drew
AT&T Bell Laboratories Holmdel/Middletown (and two places ain't fun)
drew@mtunh.ATT.COM       att!mtunh!drew