Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!saxony!dgil From: dgil@pa.reuter.COM (Dave Gillett) Newsgroups: comp.os.msdos.programmer Subject: Re: Int 10H Function 13H - How Do I access BP from C ? Message-ID: <592@saxony.pa.reuter.COM> Date: 29 Nov 90 20:34:18 GMT References: <1990Oct19.202013.28397@nada.kth.se> <1990Oct21.204236.22011@nada.kth.se> Distribution: na Organization: Reuter:file Inc (A Reuter Company) Palo Alto, CA Lines: 37 In hughes@locusts.Berkeley.EDU (Eric Hughes) writes: >In article <1990Oct21.204236.22011@nada.kth.se> >d87-vik@dront.nada.kth.se (Ville K{rkk{inen) writes: >>My problem is that Int10h - Func13h requires the offset of my data to >>be stored in BP,that is, the BasePointer. Note this,BP is a pointer, >>not a register defined in the REGS union. >BP is the base pointer from which all auto variables are referenced >and which saves the value of SP. Function 13H actually has three problems: (a) It expects a pointer in ES:BP. BP is normally an offset into the Stack segment (SS:BP). So I expect that the function has internal overhead associated with making a usable address out of the supplied paramenters. (b) BP is unusable from high-level languages. As Eric has explained, BP is used to implement stack frames as part of the calling sequence generated by almost all MS-DOS compilers. So you effectively have to resort to assembly language (Turbo C's inline 'asm' keyword can help, but what if you're using some other compiler?) to use this function. (c) Many machine BIOSes don't have it. Maybe you don't consider this a problem, but *I* generally write stuff that should work on any PC. Now, since it is possible to write a routine which has all of the visible effects of function 13H, with none of these drawbacks and negligible performance difference, with only a trivial amount of effort, I would say that the correct answer to Ville is "Don't even try to use that function!" Dave Note: We don't get comp.os.msdos.* here, for some mysterious reason.