jeff@cbnewsh.att.com (Jeff Drew) (12/14/90)
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