------------------------------ % .model memmodel ifdef I8086S P equ 4[bp] else P equ 6[bp] endif .code public _peekb ifdef I8086s _peekb proc near else _peekb proc far endif push bp mov bp,sp mov ax,P push ds mov ds,ax mov si,P+2 lodsb xor ah,ah pop ds pop bp ret _peekb endp public _pokeb ifdef I8086S _pokeb proc near else _pokeb proc far endif push bp mov bp,sp push es mov ax,P mov es,ax mov di,P+2 mov ax,P+4 stosb pop es pop bp ret _pokeb endp end ------------------------------------------------ The makefile ------------------------------------------------ MODEL=S MASM=MASM.EXE peek$(SIZE).obj : peekb.asm $(MASM) /mx /Dmemmodel=$(MODEL) /DI8086$(SIZE) peekb,peek$(SIZE); -------------------------------- The batch file -------------------------------- make MODEL=SMALL SIZE=S mkpeek.mak make MODEL=MEDIUM SIZE=M mkpeek.mak make MODEL=COMPACT SIZE=C mkpeek.mak make MODEL=LARGE SIZE=L mkpeek.mak -------------------------------- highly embarrassed, Bill. --- * Origin: bill@escan.demon.co.uk (2:2504/200) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F1100028 Date: 12/28/97 From: MICHAEL STAPLETON Time: 2:52 am \/To: JOHN GARDENIERS (Read 2 times) Subj: Re: Freq.c [1 of 5] -=> Quoting John Gardeniers to All <=- Hi John, JG> File request generator for Binkley This is a PC terminal program, isn't it? Oh well, just because I can't run it, that doesn't mean I can't analyze it. :) JG> Uses Fidouser.lst for sysop name loopups ^ Was that a Freudian slik? :) JG> I ran out of enthusiasm for the comments part way through :-( Still, your code looks fairly readable to me. I just have a few minor quibbles... JG> /* Error exit. Show error message and syntax */ JG> void abandon(char *text) JG> { JG> if(*text) JG> puts(text); JG> puts("\nUsage: F-FREQ address file [flavour]"); JG> puts(" or: F-FREQ f_name l_name file [flavour]"); JG> puts(" (default flavour is direct)"); JG> puts(" or: F-FREQ /R[eport]"); JG> puts(" (to display waiting FREQs.)\n"); JG> puts("F-FREQ will use the Binkley configuration file to"); JG> puts("locate both the nodelist and outbound directories."); JG> puts("It expects to find FIDOUSER.LST in the nodelist"); JG> puts("directory.\n"); JG> exit(1); JG> } I occasionally do this sort of thing myself, OTOH I think that it's neater (& smaller) to loop through a string table, instead of using 9 separate calls to puts(). JG> /* Strip leading white space from the string */ JG> char *kill_white(char *string) JG> { JG> char *ptr; JG> ptr=string; JG> while(*ptr==' ' || *ptr=='\t') JG> ptr++; JG> return ptr; JG> } Why use the extra local pointer? What's wrong with: char *kill_white(char *ptr) { while(*ptr==' ' || *ptr=='\t') ptr++; return ptr; } You also do exactly the same thing with the next function, nextword(). Does this have something to do with your position in the old thread about pointers and references in C? :) Keep up the good work! Michael Stapleton of Graphic Bits. * AmyBW v2.10 * ... This tagline is encrypted --- AdeptXBBS v1.11y (FREEWare/2) * Origin: Mach One BBS (3:713/615) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F1100029 Date: 12/28/97 From: MICHAEL STAPLETON Time: 3:10 am \/To: ROGER SCUDDER (Read 2 times) Subj: Re: Help ;) -=> On 23 Dec 97 17:24:24 you wrote to me <=- Hi Roger, MS> Are you trying to scare off the newbies, Roger? :) RS> No.. but if they scare that easy, they will never make it RS> with this language. ;-) Good point. :) OTOH, you were laying it on rather thick, IIRC... :) MS> FWIW, here's an improved version (IMHO) of your macro: RS> Thanks. No worries. :) MS> Your use of the ternary operator ?: is superfluous, since all MS> of these are logical expressions & are thus guaranteed to MS> evaluate to 0 RS> I wrote in haste. Thanks for pointing this out to me as did RS> some other people. I didn't see that - but I've seen less than 300 mesages in here in the last month. :( MS> PS. Please don't treat this message as some kind of attack! RS> I don't. If I can't look at criticism, I'm in trouble. I thought you'd understand, but I put the disclaimer in, just in case. :) You can never really know how people will interpret a message like that. Also, I didn't want any casual readers to think I was picking on you. :) MS> You're generally doing very well, both in your coding and your tutoring. RS> I'm well out of the newbie stage, but still have a long road RS> ahead on the way to the master stage. To quote Bilbo Baggins, "The road goes ever on". FWIW, I've been programming since 1971, and started with C in 1980. RS> I need to not only keep studying more advanced aspects of the RS> language, I'm not quite sure exactly what more advanced aspects of the language you're talking about here, Roger. Once you're comfortable working with pointers, everything else is pretty straight-forward. Remember, K&R2 is not a very big book. :) I suppose you're referring to the more subtle aspects of the core language itself, like the rules for type conversions, as well as the obscure corners of the standard libraries. Then there are the arcane preprocessor rules regarding # and ## in macros. You could also be referring to the more advanced data structures & algorithms which are possible to implement directly in C, which have no simple equivalents in BASIC. And the then there is the bottomless pit of dealing with the OS and hardware... especially your OS & hardware. :) RS> but also to keep sharpening my understanding and usage of the RS> basics. The main reason I get the C_ECHO is to keep myself sharp with the basics, both for my own sake & to improve my ability to communicate these basics to new programmers. I don't learn too much here about standard C that I didn't know before, although what C facts I have learned here I'm of course extremely grateful for. Thanks guys! However, by "working out" in this "programmer's gym" the quality of my code has certainly improved over the years, especially stylistically. Some of the source code I wrote 6 or 7 years ago can make me wince just to look at it. :) One graphics program that in other respects I'm quite proud of (a perfectly smooth scrolling text-viewer using any font, word-wrapping, etc,etc) has functions that are huge and uses tons of globals - over a dozen of these global variables have names beginning with a single letter, followed by "width", eg lwidth, nwidth, ewidth! These days, I'm still tempted to use globals for QAD development, and once the program is working then I can decide where these variables should really live. RS> I appreciate it when anyone makes thoughtful criticism of my RS> posts. Good! So do I. :) PS. Did you see my Moon Phase program I posted about a week ago? PPS. Have you been playing Precede? :) Michael Stapleton of Graphic Bits. * AmyBW v2.10 * ... This tagline is encrypted --- AdeptXBBS v1.11y (FREEWare/2) * Origin: Mach One BBS (3:713/615) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F1100030 Date: 12/28/97 From: MICHAEL STAPLETON Time: 3:12 am \/To: AUKE REITSMA (Read 2 times) Subj: Re: Moon Phase -=> On 22 Dec 97 19:46:00 you wrote to me <=- Hi Auke, MS>> PS. Did you see my updated version of your CFG.C that I MS>> posted as part of BWPack? AR>> I don't think so ... I'm not sure ... When did you post it? MS> I posted it around May or June. I didn't see any feedback about MS> BWPack, but the BBS I use has been rather unreliable the last six MS> months. AR> Yes, now that you've given a 'reasonable' reference I see that I AR> have it. You posted it on July 13. I guess I didn't even give you an unreasonable reference the first time. :) OTOH, I thought you might have noticed it because you basically suggested that I write it when I tried to convince you to do a Blue Wave version of CS2QWK. :) FWIW, apart from the CFG stuff, BWPack was not developed from CS2QWK, rather it grew out of a REXX program I wrote which packs reply packets together. MS> Basically, I fixed the memory leak when duplicate entries are MS> encountered. Using a #define, you can select either to ignore a MS> duplicate entry, or to override the old entry after properly MS> de-allocating it. AR> Useful fix! Glad you like it! I was also thinking of adding a compile-time option for case sensitive key names. Another nice possibility is to allow for a different separator char between the name and data fields, (even a blank, like in MsgEd) : int CfgRead( char * Filename, struct CfgStrings * CfgInfo, char sepchr ); MS> I think I've sent you three Netmails this year. Oh well, at MS> least Netmail appears to get through sometimes... AR> Well, I have received only one. Netmail stinks :-( I'll bear that in mind... did Moon Phase make it into the echo? Michael Stapleton of Graphic Bits. * AmyBW v2.10 * ... This tagline is encrypted --- AdeptXBBS v1.11y (FREEWare/2) * Origin: Mach One BBS (3:713/615) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F1100031 Date: 12/23/97 From: BOB STOUT Time: 02:05pm \/To: BILL BIRRELL (Read 2 times) Subj: Help On , Bill Birrell (2:2504/200@fidonet) wrote: >>> The only C reserved word I can find beginning with 'str' is struct. >> Aside from keywords like "struct", all identifiers in the standard library >> are reserved... > We are playing with words, Bob. What I said is strictly true. C has a otal > of 28 keywords. These are reserved absolutely at all times. An identifier > is reserved only while it is in scope.. Bill... Not so much "playing with words" as cutting hairs rather thinly. The standard actually disagrees with you. A careful reading of section 7.1.3 (reserved identifiers) details classes of reserved identifiers, including some which are reserved "for any use". True, they're not keywords, but you still can't use them, regardless of scope, in a strictly conforming program. You're quite correct in that you can legally use an identifier beginning with "str", provided you follow the scoping restrictions. But why do it? The whole purpose of the C_Echo is to develop good coding practices, and I don't know of anyone who seriously would advocate getting into the habit of bending the rules for reserved identifiers just because it's strictly legal. --- QM v1.00 * Origin: MicroFirm : Down to the C in chips (1:106/2000.6)