--------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F1K00011 Date: 01/14/98 From: FRANK ADAM Time: 04:37am \/To: PAUL LENTZ (Read 0 times) Subj: Need help please On Jan 10 09:34, 1998, Paul Lentz of 1:124/5025 wrote: G'day Paul, PL> I'd like to write a small TSR util to boot a machine if a trigger file PL> is found. I'll admit I never have written a TSR, I can handle that. I PL> need help with coldbooting a PC in DOS. My idea is to use int86, but I PL> Anybody every written such a monster? Wanna share the code? :-) Well there is this little known archive called Snippets. :-) It has a file called rebooot.asm. Just plug it in your code, you'll need tasm or masm. Regards, Frank. Email: fadam@sensation.net.au. --- Msged 4.20 beta 4 * Origin: The ticking point, Melbourne, Australia. (3:635/728.21@fidonet) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F1K00012 Date: 01/15/98 From: JOHN GARDENIERS Time: 01:11pm \/To: ALL (Read 0 times) Subj: Free(question) Hi All, Up till now, whenever I've needed memory for working with a large number of strings I malloc()ed the whole lot in one go. I've seen a number of examples posted here which malloc() just enough memory for one string at a time. This obviously has both advantages and disadvantages. The one thing I haven't seen is an example of how such a dynamically allocated array is free()ed. Must I have a matching free() for each malloc() or can it all be free()ed at once? ttyl, >>> Fuse >>> ... OK, I'm weird! But I'm saving up to be eccentric. --- GoldED/386 3.00.Alpha4+ * Origin: The Cubby House, I C it but I don't believe it (3:634/391) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F1K00013 Date: 01/15/98 From: JOHN GARDENIERS Time: 04:33pm \/To: PAUL LENTZ (Read 0 times) Subj: Need help please Hi Paul, -=> 11 Jan 98 03:09, Paul Lentz wrote to All <=- PL> Now the TSR stuff turns out harder than I thought! :-( That's generally the way with TSRs. :-) To write a *good* (reliable and predictable) one is a bit more involved than one would first expect. For a whole multitude of reasons I strongly suggest you don't try to write it in C. It'll not only end up absolutely massive for a tiny function but I would place no great expectations on it's ability to perform transparently to the rest of your system. ttyl, >>> Fuse >>> ... A redhead a day will wear you out! --- GoldED/386 3.00.Alpha4+ * Origin: The Cubby House, I C it but I don't believe it (3:634/391) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F1K00014 Date: 01/15/98 From: JOHN GARDENIERS Time: 04:42pm \/To: BOB STOUT (Read 0 times) Subj: moderation and the echos Hi Bob, -=> 11 Jan 98 12:40, Bob Stout wrote to All C_Echo & C_PLUSPLUS <=- BS> b) The nominating period will run through 18-Jan-98. Nominations I don't even read the C++ echo, much less post in it, but thought it might be worth pointing out that I received your message on Jan 15, a mere three days before the end of the nomination period. I wonder if any potential candidates outside zone 1 may be deprived of the opportunity because they couldn't respond in time. I might add that the same thing happened with the previous C_ECHO election. In order to give a better chance to those who must (at least sometimes) suffer significant echo delays I suggest that future nomination and election periods are made a little longer. I can of course see that these same delays could well be a strong reason for someone not serving but still feel that they should get a chance. ttyl, >>> Fuse >>> ... The young know the rules, the old know the exceptions! --- GoldED/386 3.00.Alpha4+ * Origin: The Cubby House, I C it but I don't believe it (3:634/391) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F1K00015 Date: 01/15/98 From: JOHN GARDENIERS Time: 04:51pm \/To: AUKE REITSMA (Read 0 times) Subj: Moderator nominations Hi Auke, -=> 10 Jan 98 20:29, Auke Reitsma wrote to ALL <=- AR> Nominated: AR> - John Gardeniers, 3:631/391, no email (yet!) For the noted reason (if nothing else) I'm unable to accept. Not everyone on the planet has this Internet fever. :-) AR> - Frank Adam, 3:635/728.31, fadam@sensation.net.au Oops. Frank's point is 21, not 31. ;-) AR> Frank told me however that he'll continue to co-moderate for zone 3 AR> as needed. I'm pleased, as I don't expect a great flood of other candidates. :-) ttyl, >>> Fuse >>> ... If I abbreviate 'abbreviation' who will know what I mean? --- GoldED/386 3.00.Alpha4+ * Origin: The Cubby House, I C it but I don't believe it (3:634/391) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F1K00016 Date: 01/15/98 From: JOHN GARDENIERS Time: 04:58pm \/To: AUKE REITSMA (Read 0 times) Subj: Very large executables with BC45? Hi Auke, -=> 10 Jan 98 21:03, Auke Reitsma wrote to Roger Scudder <=- AR>>> _Which_ Micro C ;-) I know of at least two products ... RS>> Really... which one is there besides the one by Dave Dunfield? AR> I do not have a good identification of it. Some of the guys at the AR> office had a "Micro C" for embedded work some time ago. Neither the The term "micro C" covers a large number of compilers which handle a subset of the C language. As I recall, the doc file with Dunfield's Micro-C even states that he doesn't consider that product to be in the same catagory as the other micro C's. A couple of decades ago these small compilers were fairly common on many 8 bit machines and it was normal to have one included with CP/M installations. ttyl, >>> Fuse >>> ... C program, C program run, C program crash, C programmer cry. --- GoldED/386 3.00.Alpha4+ * Origin: The Cubby House, I C it but I don't believe it (3:634/391) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F1K00017 Date: 01/15/98 From: JOHN GARDENIERS Time: 08:41pm \/To: LYNN NASH (Read 0 times) Subj: Pointer to a string Hi Lynn, -=> 11 Jan 98 16:18, Lynn Nash wrote to Gaines Wright <=- LN> Personally I think that we are into dogma here. :-) I never let LN> myself fall pray to the meta concept of strings since they appear to LN> have been an afterthought. As far as I am concerned there is only LN> array of char. Strings themselves are just short circuit kludges as LN> indicated Amazingly well documented and supported "kludges", aren't they? LN> by reliance of a single terminator. Comparing strings in C to arrays LN> of characters is like comparing ASYNC communications to SYNC LN> communications. Exactly. They *are* different and must be treated accordingly. If you insist on treating a string as nothing more than a simple char array you deprive yourself of a great deal of power and flexibility built into the C language. You will also no doubt fall prey to numerous bugs, as you go on to describe. LN> Relying on being able to keep track of string length under _ALL_ LN> conditions assumes perfect input or a known range of possible errors. But that's such an easy thing to do that there's no excuse for not doing so. Surely you don't have trouble restricting your strings within the limits set for them? Perhaps if you treated them as strings instead of char arrays you would find it easier. LN> I submit corrupted data files as a prime example of an unknown range LN> of possible errors. Using memset on array of char is a common LN> defense and normal programming. In the context of the example which started this thread memset is merely hiding bugs which *do* exist in the code. It doesn't *correct* the bugs at all. Imagine what will happen later on when someone, quite reasonably, decides to remove the "redundant" memset. All of a sudden the whole lot caves in because of bugs which have been there all the time. LN> Seeing the silly errors that occur in lots of commercial software, LN> either your point about many bad programmers is true, Of course it is. Why should programmers be expected to be of a higher standard than people working in any other occupation? LN> I choose to believe that there are lots of programmers that have been LN> bitten enough times to build in defense mechanisms and keep happy LN> customers. I choose to believe that those programmers are making better profits by hiding the problems instead of fixing them. The quick fix rarely endures. It's a lot like some of the methods used to "repair" a car prior to selling it. It might be legal, it might be effective, but it's still a lousy thing to do. Don't confuse a "defense mechanism" with poor workmanship. ttyl, >>> Fuse >>> ... TV Truth: The "Good Guys" are the only ones with a sense of humor. --- GoldED/386 3.00.Alpha4+ * Origin: The Cubby House, I C it but I don't believe it (3:634/391) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F1K00018 Date: 01/15/98 From: JOHN GARDENIERS Time: 08:48pm \/To: DANIEL E. CHAPMAN II (Read 0 times) Subj: Network file creation. Hi Daniel, -=> 11 Jan 98 12:16, Daniel E. Chapman II wrote to ALL <=- Seeing as I recently asked the question (again) I suppose this is directed at me. :-) DI> To create files on a network drive, you can usually either just use DI> the plain drive mapping (like N:\ or whatever) but you can also DI> usually use UNC type mappings. Which are double backslash, computer DI> name, and then the share name. I understand that but wish to access the remote drive in the same manner as a local drive. As an example, drive E: on my computer is really \\ROB\\ROB-C. Although I *may* be able to access the drive in this way it would only be a workaround, not a solution. Anyway, it turns out that the problems I have/had opening files on network drives have been traced to my use of the wrong function number in assembler and a quirk in the run-time library of Turbo C 3.0 (and possibly other versions as well). Thanks for the input though. ttyl, >>> Fuse >>> ... SUPERCOMPUTER => What it sounded like before you bought it. --- GoldED/386 3.00.Alpha4+ * Origin: The Cubby House, I C it but I don't believe it (3:634/391) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F1K00019 Date: 01/13/98 From: FRANK ADAM Time: 08:44am \/To: MICHAEL STAPLETON (Read 0 times) Subj: Re: Pritty Lites... On Jan 07 20:03, 1998, Michael Stapleton of 3:713/615 wrote: G'day Michael, SA>> If it really bothers you I can knock you up a wee converter... MS> An interesting concept, although I'm sure a comment converter would MS> be more on-topic. :) ROFL! :-) MS> I should've guessed - you've been assimilated! What is it with you MS> guys? My theory is that Borland compilers produce subliminal MS> messages which make you write unportable code. :) Rubbish, BC has always been extremely compliant. As for ISO programmers..now there is a noble reason for cloning humans. ;-) Regards, Frank. Email: fadam@sensation.net.au. --- Msged 4.20 beta 4 * Origin: The ticking point, Melbourne, Australia. (3:635/728.21@fidonet) --------------- FIDO MESSAGE AREA==> TOPIC: 239 C LANGUAGE Ref: F1K00020 Date: 01/14/98 From: SIMON AVERY Time: 01:14pm \/To: NIGEL TRAVES (Read 0 times) Subj: Moderator election Bonjour, Nigel AR>> After a year of moderatorship it is time for someone else to do AR>> the job. In other words: it is election time. NT> Well I have a couple of suggestions for people to do the job. These NT> are only suggestions and not actual nominations for a couple of NT> Simon Avery That was unexpected! Thanks for the nomination, and after thinking about it for a while, I've decided to accept and run for mod. Background info: I currently moderate: PGMRS - Miscellaneous programming. PGMRS_UK - As above, but limited to UK distribution ONLY. WIN95_UK - Windows 95 LOST_MAIL_UK - Info Echo INTERNET_UK - Internet related chat. I do fulfill Auke's requirements (full node, email address etc) and another echo wouldn't take up that much time as I tend to favour an open-style of moderation. The rules as-is have worked quite well and I don't intend changing them much. Auke - can you add me to the list please? NB. My once-a-decade holiday falls right in the middle of voting, ie, Most of February, so I won't be contactable during that period. I will, barring plane-crashes, be back in March. Don't think that should matter though. Simon ... Why, Nigel, have you checked out Tag-O-Matic yet? --- FMail 1.22 * Origin: Tag-O-Matic - Freq T-MATIC from Origin (2:255/90)