|||||| |||||| || || |||||| |||||| || || ||| || || || || ||| |||| |||||| || |||| Your || || || || ||| || || |||||| |||||| || || |||||| |||||| GEnieLamp A2Pro || |||||| || || |||||| RoundTable || || || ||| ||| || || || |||||| |||||||| |||||| RESOURCE! || || || || || || || ||||| || || || || || ~ LATEST NEWS FROM THE A2PRO ONLINE DEVELOPERS ~ ~ RAMBLINGS OF A WANNABE PROGRAMMER ~ ~ A2U SPRING SESSION CONTINUES WITH RESOURCE CLASS ~ ~ HOT NEWS ~ HOT MESSAGES ~ HOT VIEWS ~ ////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ GEnie Lamp A2Pro ~ A T/TalkNET OnLine Publication ~ Vol.1, Issue 03 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" Publisher.........................................T/TalkNET Publishing Editor-In-Chief........................................John Peters Editor.................................................Jim Couch ~ GEnieLamp IBM ~ GEnieLamp [PR]/TX2 ~ GEnieLamp ST ~ GEnieLamp A2 ~ ~ GEnieLamp MacPRO ~ GEnieLamp A2Pro ~ GEnieLamp Macintosh ~ ~ Member Of The Disktop Publishing Association ~ ////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ >>> WHAT'S HAPPENING IN THE APPLE A2Pro ROUNDTABLE? <<< """"""""""""""""""""""""""""""""""""""""""""""""""""""" ~ April 1, 1993 ~ FROM MY DESKTOP ......... [FRM] A2PRO ROUNDTABLE STAFF . [DIR] Notes From The Editor. Directory. HEY MISTER POSTMAN ...... [HEY] DEVELOPER'S CORNER ...... [DEV] Is That A Letter For Me? News from A2Pro Developers. RAMBLINGS................ [RAM] A2U CAMPUS CHAT ......... [A2U] Ramblings of a Wannabe Programmer A2 University:Learning Online. ONLINE LIBRARY .......... [LIB] LOG OFF ................. [LOG] April is Tech Note month! GEnieLamp Information. [IDX]""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" READING GEnieLamp GEnieLamp has incorporated a unique indexing """"""""""""""""" system to help make reading the magazine easier. To utilize this system, load GEnieLamp into any ASCII word processor or text editor. In the index you will find the following example: HUMOR ONLINE ............ [HUM] [*]GEnie Fun & Games. To read this article, set your find or search command to [HUM]. If you want to scan all of the articles, search for [EOA]. [EOF] will take you to the last page, whereas [IDX] will bring you back to the index. MESSAGE INFO To make it easy for you to respond to messages re-printed """""""""""" here in GEnieLamp, you will find all the information you need immediately following the message. For example: (SMITH, CAT6, TOP1, MSG:58/M475) _____________| _____|__ _|___ |____ |_____________ |Name of sender CATegory TOPic Msg.# Page number| In this example, to respond to Smith's message, log on to page 475 enter the bulletin board and set CAT 6. Enter your REPly in TOPic 1. A message number that is surrounded by brackets indicates that this message is a "target" message and is referring to a "chain" of two or more messages that are following the same topic. For example: {58}. ABOUT GEnie GEnie costs only $4.95 a month for unlimited evening and """"""""""" weekend access to more than 100 services including electronic mail, online encyclopedia, shopping, news, entertainment, single-player games, multi-player chess and bulletin boards on leisure and professional subjects. With many other services, including the largest collection of files to download and the best online games, for only $6 per hour (non-prime-time/2400 baud). To sign up for GEnie service, call (with modem) 1-800-638-8369. Upon connection type HHH. Wait for the U#= prompt. Type: XTX99014,DIGIPUB and hit RETURN. The system will then prompt you for your information. Need more information? Call GEnie's customer service line (voice) at 1-800-638-9636. """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" [EOA] [FRM]////////////////////////////// FROM MY DESKTOP / ///////////////////////////////// Notes From The Editor """"""""""""""""""""" By John Peters [GENIELAMP] FROM MY DESKTOP When I typed in the characters ATDT and the the number of """"""""""""""" a local bulletin board for the very first time, I was completely and utterly awed. No longer was I alone in my computing pursuits. At the touch of a key, I could call out to practically any place in the world and make friends with people that I would have never had the chance to do so with otherwise. The modem had broken my computing isolation from the rest of the world. Ten years later, I'm still awed by it all, but now, even more so. I keep in touch with friends via GE Mail, I stay on top of what's happening in the news with Newbytes and I can get answers to just about any question I can think of - many times within hours of posting it. I can share my knowledge with others and more importantly, I can learn from their experiences as well. I can download pictures, sounds and books to read and I can even play a friendly game of backgammon or chess with someone in Boston, or Miami, or Japan. Amazing. But it can be frustrating too... When you think about it, we "onliners" represent a very small segment of the overall population. Surprisingly, there are many people who own computers are unaware of what's available to them online. They use the computer to type in an occasional school report or (more likely) play games on it. That's okay as eventually many of these people will find their way online by way of a friend, an article they read or because they are just plain curious (like I was). The point is, we've only just begun. Think about it...we are in the infancy of telecommunications. In a way, I'm sorry I won't be around a hundred years from now to see where all of this is heading. On the other hand, I am thrilled to be among the online pioneers of this _new_ and exciting technology. Welcome aboard, friend, and I'll see you online! GEnie Elsewhere Did you know that the Public Forum RoundTable (M545) is """"""""""""""" archiving all of the official White House Electronic Press Releases issued by the new White House E-Mail Communications Office? The files are available in the PF Library in the format WHPRxxx.TXT, and there are currently 177 of these files available. The files include press releases, official announcements, transcripts of press conferences & other official White House communiques. Interesting stuff here - well worth checking out! For more info., contact GRAFFITI, the PF SysOp. NEW 800 SERVICE Some GEnie access numbers incur a $2.00 per connect hour """"""""""""""" communications surcharge. This surcharge applies to all GEnie usage, including GEnie*Basic services. Surcharged access numbers are noted with a dollar-sign ($) and the amount of the hourly communications surcharge (i.e., $2.00/hr). To retrieve local access numbers, please type *PHONE or PHONE at any main menu prompt. When accessing GEnie via 800-Service (available only in the US), you will incur a $6.00 per connect hour communications surcharge, for 300, 1200 and 2400 baud access. This surcharge applies to all usage, including GEnie*Basic services. 9600 baud access is also available via 800-Service. When using 9600 baud via the 800-Service, you will be charged $18.00 per connect hour during non-prime time and $24.50 per connect hour during prime time. LOCATION BAUD RATE SURCHARGE NETWORK ACCESS NUMBER --------------- -------------- --------- --------- ------------- United States 300/1200/2400 $6.00/hr GEnie 800-362-1296 United States 9600 $12.00/hr GEnie 800-847-5260 When accessing GEnie via SprintNet, you will incur a $2.00 per connect hour communications surcharge. This surcharge applies to all GEnie usage, including GEnie*Basic services. Surcharged access numbers are noted with a dollar-sign ($) and the amount of the hourly communications surcharge (i.e. $2.00/hr). To retrieve local access numbers, please type *PHONE or PHONE at any main menu prompt. PLEASE NOTE If you are dialing long-distance to access GEnie, we do not """"""""""" recommend dialing a surcharged access number, as you will incur the $2.00 connect hour surcharge in addition to long-distance charges. Also note that interstate long-distance calls are usually less expensive than intrastate long-distance calls. Please be sure to verify the long-distance charges with your local telephone company. [*][*][*] GEnieLamp FUN AND GAMES This is one big issue so I'm going to keep my """"""""""""""""""""""" desktop notes short this time around. One word of caution when reading this month's issue: Don't forget, it's April! Until next month... John Peters [GENIELAMP] [EOA] [DIR]////////////////////////////// A2PRO ROUNDTABLE STAFF / ///////////////////////////////// By Jim B. Couch [J.COUCH2] ____________________________________________ A2 PROGRAMMERS & DEVELOPERS ROUNDTABLE STAFF _____ ______ ____________________________________________ /_____|/______\ /__/|__| ___|__| Head Sysop: Matt Deatherage (M.DEATHERAGE) /__/_|__| /_____/ Assistants: Steve Gunn (A2PRO.STEVE) /________|/__/ __ __ __ Greg Da Costa (A2PRO.GREG) /__/ |__|__/______ /_//_// / Todd P. Whitesel (A2PRO.TODDPW) /__/ |__|________// / \/_/ JIM MURPHY LEAVING A2PRO STAFF POSITION Well, I'm sad to say it, but I'm """"""""""""""""""""""""""""""""""""""" announcing my resignation from the A2Pro staff. I've had a great time helping this place to be as useful and successful as it has become, but I just don't have the time to spend here that being a sysop requires. Since I took a position in the Apple II Continuation Engineering Group in January, about 95% of my waking hours have been spent hacking on the IIgs System Software, and that has left precious little time for GEnie (just ask Matt :-). I will still be here in A2Pro, just not as a staff member (many of you are now asking, "Jim? On the A2Pro staff? Since when?" :-). It's been fun. -Jim Murphy (A2PRO.JIM [Murph'], CAT1, TOP17, MSG:68/M530) A2PRO IS LOOKING FOR A NEW STAFF MEMBER Jim? On the A2Pro staff? """"""""""""""""""""""""""""""""""""""" Since when? He'll still be around, folks, because I live near him and I'll make his life miserable if he's not. :) However, it does leave us with an opening on the A2Pro staff for someone who's familiar with GEnie, Apple II technical issues and third-party developers. We need a staff member who can manage A2Pro's extensive list of third-party companies who support developers right here for Apple II programmers. This person will be responsible for assisting companies in providing support, including answering their GEnie questions and solving GEnie problems for them. The new staff member will also be responsible for managing A2Pro's beta-test service -- one of our best-kept secrets. Right now, several major commercial products are being beta-tested in private, hidden categories right here in our own bulletin board (and libraries), and this person will also be responsible for making sure those companies get what they need. That includes inviting people into private categories and libraries, helping people set up new beta-test services, and actively going out to find great new products that we can help make better. In return, all connect time in A2Pro is waived, plus this person gets invited to all the private beta-testing categories (except where legal non- disclosures are required) and can help shape future Apple II software in a powerful way. You also get a few other benefits from Resource-Central, like a free subscription to A2-Central. Interested? If you have the time and the talent, you can help us make a difference. Send me your qualifications in GE Mail (M.DEATHERAGE) if you've been waiting for this chance. --Matt (I speak for myself, not for Apple) (M.DEATHERAGE, CAT1, TOP17, MSG:70/M530) [EOA] [HEY]////////////////////////////// HEY MISTER POSTMAN / ///////////////////////////////// Is That A Letter For Me? """""""""""""""""""""""" By Jim B Couch [J.COUCH2] o BULLETIN BOARD HOT SPOTS o A2PRO ODDS & ENDS o WHAT'S NEW? o THROUGH THE GRAPEVINE o PROGRAMMER'S CORNER o HOT TOPICS o MESSAGE SPOTLIGHT >>>BULLETIN BOARD HOT SPOTS <<< """"""""""""""""""""""""""""""" [*] CAT15, TOP2, MSG{41}...........................Memory Manager [*] CAT15, TOP34, MSG{56}.......................Text Edit Tool Set [*] CAT34, TOP3, MSG{58}........................Ultra Programming [*] CAT35, TOP1, MSG{8}.............Foundation General Discussion [*] CAT36, TOP11, MSG{83}...................................ORCA/C [*][*][*] >>> A2PRO ODDS & ENDS <<< """"""""""""""""""""""""" WELCOME TO THE APRIL ISSUE OF THE A2PRO GENIELAMP In the spirit of April """"""""""""""""""""""""""""""""""""""""""""""""" Fools Day we have taken our normally solemn Lamp and included just a few brief moments of levity. keep an eye out for them! While we have included all the great programming information and tips we always feature I thought it would be fun to lighten things up just a tad for this month. WELCOME NEW WRITERS I would like to welcome some new writers to the """"""""""""""""""" A2Pro GEnieLamp. Appearing in this issue is an article by Larry Elseman [L.ELSEMAN1] who will be writing feature articles for us on a regular basis. I would also like to welcome Nate Trost [N.TROST] who will be starting next month as a staff writer. Nate will be covering the A2Pro libraries, real time conferences, and A2 University. A short introduction featuring Nate is a part of this month's lamp. I also hope to have some other folks writing articles as well. Welcome aboard Nate and Larry. INTRODUCING NATE TROST! Hello! I'm Nate Trost, newest member of the """"""""""""""""""""""" A2Pro GEnieLamp staff. As my first assignment I get to introduce myself. My experience with computers began back in 1981 when my father bought an Apple ][+. Over the next few years I played games, slaved away at Zork, and started tinkering with BASIC. The ][+ was replaced by a IIe in 1983, and then the IIe was traded in for a Woz IIGS in 1987. About the time we got the GS, I began to move from BASIC into the realm of Pascal. With much encouragement from my father, I worked through the Instant Pascal tutorial. Although archaic by today's standards, most of what I learned about basic programming concepts came from working with Instant Pascal. I began to develop an interest in GS programming and started to fiddle with TML Pascal. Then I discovered assembly, and life became a lot more crash-prone. :-) By the time 1990 rolled around I was slowly becoming familiar with 65816 programming and the use of the IIGS toolbox. It was then that I attended KansasFest for the first time and realized how much there still was to learn! I kept plugging away and started messing around with IIGS animation programming, which would later become my special area of expertise. During 1991 and 1992 I continued to build on my skills, writing articles for 8/16 Central, developing programs for Softdisk G-S, teaching graphics/sound programming at KansasFest, and just messing around with the II. Currently I am busy finishing high school, working part-time at Argonne National Laboratory programming UNIX workstations, developing software for Softdisk Publishing, and writing for GEnieLamp. [*][*][*] WE WANT YOUR FEEDBACK! I would love to hear from you all! I hope that the """""""""""""""""""""" A2Pro edition of GEnieLamp is meeting with your approval. We need your suggestions, comments, ect to make the Lamp even better. Drop me a line and let me know what you think! E-Mail your comments to me at [J.COUCH2]. [*][*][*] WHAT TO DO WITH THOSE PESKY .SYM FILES? Several people have mentioned """"""""""""""""""""""""""""""""""""""" they don't like the .sym file sitting there with their source files, but I don't know where else to put it. The problem is that the .sym file is needed right away, before the first character of the source file is even read, so I can't depend on any option set within the compiler. Here are some of the options I looked at and rejected: 1. Make the .sym files invisible. I thought that would cause more problems than it was worth. 2. Use resources. I was afraid that would mess up too many editors. I was starting to reconsider after some recent editor resource discussions, but there were some pretty negative comments about using the resource fork for the .sym information. 3. Put them in some other directory. But where? This runs into all sorts of problems. I'm open to suggestions. One additional though that I've had, and not yet rejected, is using a shell variable to set the .sym file directory. The default would be 8:, which is effectively what it is now, and you could code any other path name you want. -Mike Westerfield (BYTEWORKS, CAT36, TOP11, MSG:57/M530) HERE IS A .SYMPLE IDEA TO TRY A couple of people have mentioned that they """"""""""""""""""""""""""""" don't like the .sym file cluttering up the directory where their source is located. After playing around with it this weekend, I found a solution that I personally like. Most of us that do multi-file C programming use script files to do the builds. In your script file, right after each compile, insert a line more or less like enable i foo.sym This makes the file invisible, and the CAT command generally won't show the file. There is a CAT command flag that will show invisible files, or you could use disable i =.sym to see them all again. Of course, all of the GS/OS based commands still work; you can copy, delete, or whatever, even when the file is invisible. Give it a try and let me know what you think. -Mike Westerfield (BYTEWORKS, CAT36, TOP11, MSG:78/M530) TELL ME A BIT ABOUT XMODEM The following is a question a friend of mine """""""""""""""""""""""""" asked me to ask here on GEnie (and elsewhere) regarding the Xmodem protocol. Here it is (quoted): >Specifically, I want to know what they mean by "Block number character >in ASCII", and if that block number starts at 0 or 1. Also, I need to >know how it calculates the checksum. Can anyone help him out with this question? - Derek Fong (M.POTTER4 [AppleNET], CAT17, TOP2, MSG:10/M530) XMODEM PACKET FORMAT AND CHECKSUM In ASCII? Hmmm as far as I know it's """"""""""""""""""""""""""""""""" just a byte... Packet format is: "01 xx yy [128 bytes] zz" where xx is the block number (starting at $00) and yy is 256 minus the block number (starting at $FF) and zz is the checksum. The block numbers wrap back to $00 and $FF when you do more than 256 blocks. The checksum is simply the sum of the [128 bytes] with any carry discarded. CRC is a little more complicated, and I don't remember the formula off-hand, but I could look it up if you wanted it. _ |_)avid |\/|iller (D.MILLER132 [GTerm] [Dave], CAT17, TOP2, MSG:11/M530) A SMALL CORRECTION Packet format is: "01 xx yy [128 bytes] zz" where """""""""""""""""" xx is the block number (starting at $00). For XMODEM, the block number starts at $01, goes to $FF, and then wraps around to $00. YMODEM transfers start at $00 (file information is passed in the $00 block :-) (JWANKERL [Joe], CAT17, TOP2, MSG:16/M530) WHERE TO GO FOR MORE SPECIFICS You can find source code to an Example """""""""""""""""""""""""""""" CRC-16 algorithm (The same one that XModem uses) in the NuFX File Type Note. That's $E0/$8002. The new technical notes aren't up in separate files, but I think that there may be a copy of that File Type Note in the library separately. Plus if I remember correctly, there is a lot of source in the library that has CRC checking in it.. do a search in the lib on CRC. Let me know if you can't find this stuff.. -Steve (A2PRO.STEVE, CAT17, TOP2, MSG:13/M530) AND A CRC CODE EXAMPLE IN C The source code I've got is in C... if you """"""""""""""""""""""""""" don't understand C, I can see if I can find something else... /* * This function calculates the CRC used by the XMODEM/CRC Protocol * The first argument is a pointer to the message block. * The second argument is the number of bytes in the message block. * The function returns an integer which contains the CRC. * The low order 16 bits are the coefficients of the CRC. */ int calcrc(ptr, count) char *ptr; int count; { int crc, i; crc = 0; while(--count >= 0) { crc = crc ^ (int)*ptr++ << 8; for(i = 0; i < 8; ++i) if(crc & 0x8000) crc = crc << 1 ^ 0x1021; else crc = crc << 1; } return (crc & 0xFFFF); } This was excerpted from a file called YMODEM.DOC, can't remember where I got it from. _ |_)avid |\/|iller (D.MILLER132 [GTerm] [Dave], CAT17, TOP2, MSG:15/M530) GS/OS OPEN FILE LIMITS >>> J.KRELL1 [Jay """""""""""""""""""""" > The ORCA/C docs say GS/OS is "limited" to 32767 > open files. Where is this documented? I never saw such a limitation documented; I think someone made it up and Mike remembered it. There are limits in reality, of course -- right now, each open files takes about 1K of memory, so on an 8 MB system there's a practical limit of about 8000 open files. To date, this hasn't inconvenienced anyone. :) -Matt (I speak for myself, not for Apple) (M.DEATHERAGE, CAT36, TOP11, MSG:82/M530) >>> WHAT'S NEW? <<< """"""""""""""""""" EDIT 16 V2.0 DELAYED Edit-16 v2.0 is delayed a bit. My fault (although """""""""""""""""""" this gives Bill some breathing space in the beta testing)... The Manual isn't done! We are now projecting a release toward the end of this month. Marc "feeling harried" Wolfgram Lunar Productions (M.WOLFGRAM2 [Lunar Host], CAT35, TOP5, MSG:74/M530) AS IS NAMOBJ NameOBJ will be shipping soon.. """""""""""" There have been a few things that are holding up NameOBJ's release. We expect it to start shipping later this month. -Marc Wolfgram Lunar Productions (M.WOLFGRAM2 [Lunar Host], CAT35, TOP6, MSG:18/M530) >>> THROUGH THE GRAPEVINE <<< """"""""""""""""""""""""""""" NEW ULTRA 4 INITS ON THE WAY? Is there any truth to the rumor I hereby """"""""""""""""""""""""""""" start, that there is soon to be an I.Claudius init? (:-) -Roger (R.MALTZ, CAT34, TOP3, MSG:50/M530) >>>>> Roger, I.DoubtIt *^P """"" -Lorne (L.WALTON [Canucklehead], CAT34, TOP3, MSG:51/M530) >>>>> Lorne, """"" I.EmAshamed -Roger (R.MALTZ, CAT34, TOP3, MSG:52/M530) >>>>> Lorne and Roger, """"" I.Dunno -Randy (BRANDT [Randy], CAT34, TOP3, MSG:53/M530) >>> BRANDT [Randy] > I.Dunno I.GetIt -- we need a new topic for Init Humor. I.Laugh when U4 get to talking like this. -Will (W.NELKEN1, CAT34, TOP3, MSG:54/M530) >>> PROGRAMMER'S CORNER <<< """"""""""""""""""""""""""" This month we have a couple more opportunities for those who wish to make some money programming. We also continue to present programming tips. This time we present tips on Pascal, Ultra 4, using MaxBlock, and using colors with text controls! 65816 ASSEMBLY PROGRAMMER WANTED There's a small company in the Bay Area """""""""""""""""""""""""""""""" looking for a SNES programmer. They're willing to take a good IIgs programmer and train them. The game you'd be working on is _VERY_ cool and the starting salary is somewhere around $35-40K. They need someone NOW. If you're interested in this please send me e-mail or call me at home (evenings/weekends) at 318-424-0263. -Jay (PUNKWARE, CAT13, TOP8, MSG:33/M530) PHANTASM (AND TWILIGHT II) BLANKER MODULES WANTED If you know IIGS """"""""""""""""""""""""""""""""""""""""""""""""" graphics programming, why not contribute a blanker module for the new Phantasm blanker module disk? Check the library for details on writing Phantasm modules (which will also work with Twilight II) -- if they're not there already, they will be shortly. We are interested in buying these modules outright. They should not be too difficult to write -- you ought to be able to turn out two or three in a weekend. B) (QC [Jerry], CAT13, TOP8, MSG:34/M530) PASCAL AND THE STACK Range checking will make sure Pascal doesn't """""""""""""""""""" overflow the stack, but it can't check to see what the tools are doing. Unfortunately, there is no foolproof way to do so. Nesting procedures is fine, although it doesn't effect the stack space one way or the other. Using variables from one or two levels up may save you a word or two of stack space, but it increases your code size by a lot more than a word, and in some tight loops, it may noticeably effect execution speed. For small stacks, these are the general rules: 1. Keep the number of local variables and parameters down, especially arrays. 2. Pass arrays as var parameters whenever you can, since the impact on the stack for a var array is 4 bytes, while the impact on the stack for a value array is 4+sizeof(array). 3. Avoid recursion or deeply nested procedure/function calls. You should leave about 1K more on the stack than you need. The tools can generally live with this amount. ORCA/Pascal 2.0 also handles the stack a lot better. It uses less stack space to start with (Pascal 1.4.1 wastes about 4K), and procedure and function calls have less impact on the stack. Stay tuned... As for checking for eof being icky, it's a lot better, more portable, and generally has less impact on speed and code size than handling through SystemError. As for the repeated calls to SystemError, that may just be the file I/O system trying to read a line at a time or something. I can look into that further if you like, but I'll need a complete program to look at. E-mail would be the best way to get it to me. -Mike Westerfield (BYTEWORKS, CAT36, TOP10, MSG:39/M530) HOW TO HAVE ALL 16 COLORS AVAILABLE IN TEXT CONTROLS Recently I was """""""""""""""""""""""""""""""""""""""""""""""""""" talking to someone about something (how's that for vague?) and we got on the subject of stat text controls. He was mad at Apple for only allowing us to use purple and green colors in stat text controls in 640 mode. I said, "What?!? Don't you know about the font flags?" He said, "Huh?!?" To have all 16 colors available to your stat text controls, do this after you create the window: myWindow = NewWindow2(....); if (NoErrors) { SetPort(myWindow); SetFontFlags(GetFontFlags() || 0x04); etc.... } That'll allow you to use all 16 colors as expected... He was happy. -Bryan (SOFTDISK.INC [Zak], CAT15, TOP16, MSG:57/M530) MAXBLOCK DOES NOT LIE, BUT... Someone recently noted in private that """"""""""""""""""""""""""""" MaxBlock was always returning about 20K even though RealFreeMem returned about 120K and memory allocations were always working, and wondered: > Does MaxBlock() really report the largest free block in memory, or does > the memory manager try to conserve memory by reporting large, but not > the largest chunk? MaxBlock does not lie, but it's not as useful as lot of people seem to think. You can have lots of little free spaces scattered throughout memory and only one 20K block, and MaxBlock will return 20K even though the Memory Manager may be able to satisfy a 30K request. That's why Apple has always told people to just allocate the block you want and not to preflight by using MaxBlock or RealFreeMem. It will work really hard to get you what you want. OOM queue routines firing: they'll always fire both times before any $0201 error is returned, even for something that you logically know can't work. Try allocating a one-byte absolute address handle in the middle of your program code -- the Memory Manager will purge everything and call every OOM queue routine in an attempt to get that one-byte handle, and will finally give up when your fixed program code block doesn't go away. See Apple IIgs TN #78 for some more explanation in one specific case. --Matt (I speak for myself, not for Apple) (M.DEATHERAGE, CAT15, TOP2, MSG:50/M530) HOW TO UNCACHE ULTRA 4 TASK FILES >>>B.WEITHOFE """"""""""""""""""""""""""""""""" > Is there a way to unload or replace > an existing task file in memory so that the corrected file would be > executed? Bob, I wrote the following macro that displays a list of Taskfiles in memory, and allows you to pick ones that you want to "uncache". -- David -- start :! (D.THOMAS29, CAT34, TOP3, MSG:58/M530) HOW DO I DETERMINE THE CAUSE OF CRASHES? I have installed GSbug and the """""""""""""""""""""""""""""""""""""""" accompanying Loader Dumper on my GS. These tools came from the ORCA/M 2.0 disks. Occasionally, my system crashes into GSbug. I would like to determine what is causing these crashes. What kind of information should I record so you can help me determine what is going on? Thanks. -Glenn (G.W.HOFFMAN [Glenn], CAT5, TOP3, MSG:31/M530) YOU CAN USE NIFTY LIST Glenn, What a question! :) """""""""""""""""""""" I do this a lot: note the stack location (address under the S thing) and the current PC. Then I pop into Nifty List and do a "w" on the PC, that'll tell me where I'm crashed. then doing a ";s" on the stack will do a stack crawl and sometimes you can get an idea of what was going on before you crashed. -Bryan (SOFTDISK.INC [Zak], CAT5, TOP3, MSG:32/M530) SOME MORE IDEAS One of the things to look at is the value of the """"""""""""""" Accumulator. If there was a toolbox error, then the accumulator should hold the error code. You can also look at the values of K/PC and use that information with Nifty List to find out who owns the memory. There is a GSBug tutorial around in the library somewhere, which Tim Swihart wrote and has quite a bit of useful information. I'm not sure which file it is, but I'm pretty sure it's in with one of the GSBug or Nifty List archives. _ _ / _ | \ Greg Da Costa \_| |_/ A2Pro Archivist (A2PRO.GREG, CAT5, TOP3, MSG:33/M530) >>> HOT TOPICS <<< """""""""""""""""" A (NOT SO) QUICK LESSON ON THE IIGS MEMORY MANAGER There has been some """""""""""""""""""""""""""""""""""""""""""""""""" discussion in the ORCA/C topic about how the Memory Manager should work, or how it should have been designed. Such discussion more correctly belongs here, and here is where I'll respond. >>> A2PRO.TODDPW [!@tybalt] > I would have preferred that the memory manager require you to > dereference and lock all handles in one operation, and enforce the rule > that unlocked handles may move at ANY time. If the system doesn't do it > from an interrupt, the compiler optimization might. If I'd grown up with this kind of memory model, it might not bother me. But I didn't, and in retrospect, to think of everyone having to lock any memory block just to reference it seems silly to me. As Mike pointed out in the ORCA/C topic, a compiler optimization that changes the order of evaluation is a bug -- and there is a well-defined and well-constructed set of rules about when memory can move and when it can't. It's not a problem, except for: >>> PROCYON.INC > GNO can context switch out of a process when it believes that its > handles are safe; the process being switched to can allocate memory and > cause the 1st process' handles to move or get purged. This is a design flaw in GNO. Plain, simple, incontrovertible. If it makes programs crash by changing the Memory Manager's rules, then it is at fault. Jawaid may rightfully say "But there's no way to avoid it!" -- and he's right. That's why all the _other_ companies that investigated projects like GNO did not bring them to market -- because they are inherently unreliable. If people find GNO useful even with these severe restrictions, more power to them. Claiming it's the system software's "fault" that GNO breaks the software architecture is like producing a hardware card that doesn't work and saying "It's Apple's fault; it would work fine if the IIgs ran at 5.3 MHz." You should have figured that out before you started. > DTS gave me a (not-great- but-it'll-have-to-do) way to tell the memory > manager not to ever move blocks. This technique, for those interested, is the "We're in an interrupt" flag documented in Apple IIgs Technical Note #57. As long as the flag is set, no memory will _ever_ move. In effect, the entire point of the handle-based Memory Manager will be destroyed if this flag is set all the time, which is what I think GNO is going to do in the future. The Technical Note calls setting this flag to avoid memory moving "mind- numbingly stupid," an assessment with which I heartily agree. --Matt (I speak for myself, not for Apple) (M.DEATHERAGE, CAT15, TOP2, MSG:41/M530) MULTITASKING AND MEMORY PROBLEMS? >>> D.MILLER132 [GTerm] [Dave] """"""""""""""""""""""""""""""""" > Specifically with the onset of > multitasking (GNO etc.), what if another process does something that > moves memory while your process is in between reading part of your block? Jawaid would probably say "Yes, you need to worry about this." In fact, he already has. Apple, however, has said since 1986 that you do not -- memory should not move behind your back. If you dereference a handle, the resulting pointer should stay valid until -you- do something that moves memory. The system maintains an interrupt flag to insure that memory allocated at interrupt time does not cause memory to move. Right now, GNO _can_ cause memory to move behind your back, which I'm fairly sure is at least part of the reason some applications aren't compatible with it (though Jawaid has not verified any crashes due to this). You can either lock everything all the time you reference it or you can wait for GNO to find a solution. Personally, I opt for leaving things unlocked until _I_ move them; I think it's wasteful to have to lock things all the time when the system clearly says it's not necessary. The System Software's paradigm, for better or worse, is "unlocked handles are safe unless you do something that moves them." Programs like GNO aren't allowed to change rules like that towards being >less< compatible, but that's what's happened. Apple certainly isn't going to any effort to change the places in system software where unlocked handles stay dereferenced where they should be safe. --Matt (I speak for myself, not for Apple) (M.DEATHERAGE, CAT15, TOP2, MSG:52/M530) GNO AUTHOR SAYS TO LOCK YOUR HANDLES FOR NOW David, You're right on the """""""""""""""""""""""""""""""""""""""""""" mark. I haven't come up with a solution to the "other process moves a handle" problem yet that won't eventually cause the machine to run out of memory. The best thing is for programmers to lock their handles while they're accessing any information in them. Especially since locking a handle can be accomplished in about 20 cycles of machine code (5 lines). The problem hasn't caused a verified crash in GNO, but you never know. -Jawaid (Message, CAT15, TOP2, MSG:/M530) HANDLES ALA MACINTOSH > I haven't come up with a solution to the "other """"""""""""""""""""" > process moves a handle problem yet that won't > eventually cause the machine to run out of memory. I wonder if it might be possible to patch into the memory manager to allocate separate "heaps" for applications, such that each program has its own heap space, can allocate handles within it, and that's it. That way, handles that were moved by one application would not affect the handles in a heap owned by another application. This is basically how the Mac works under System 7/MultiFinder. Each time an application calls NewHandle (directly or indirectly), you'd have to fake the memory manager into thinking that all memory outside the application's heap is locked and not usable. I'm sure there are a number of unrealized complexities in doing this, and is probably something you guys have already mulled over. (MORGAN-DAVIS, CAT15, TOP2, MSG:53/M530) LOCKING ALL HANDLES IS NOT A SOLUTION Asking those developers who write """"""""""""""""""""""""""""""""""""" code specifically for GNO to lock handles all of the time is, unfortunately, a non-solution. You must realize that portions of the System Software itself rely on memory not moving when it's in control. As I've said before many, many (uncountable) times, the toolbox was never designed for pre-emptive multitasking, and asking permanently-rooted guidelines to bend is an impossible proposition. > The problem hasn't caused a verified crash in GNO, but you never know. In all honesty, I could probably create a reproducible sequence that demonstrates this problem in a matter of minutes. All you need to do is to allocate memory such that compaction occurs when someone is accessing an unlocked block. Since pre-emptive context switching can theoretically occur before any instruction is executed, the best way to show that this is happening would be through a logic analyzer trace. With intrusive tools such as GSBug, you just wouldn't be able to show this happening. -Jim (A2PRO.JIM [Murph'], CAT15, TOP2, MSG:54/M530) GNO AUTHOR REPLIES Morgan, actually, I hadn't thought of that. Hum. That """""""""""""""""" would be a lot of work, but it's closer to my ideal solution of virtual memory than anything that had crossed my mind. Thanks. Matt & Jim, GNO doesn't context switch while a process is inside the System Software. So, it's just applications; and you both misread me, or I didn't make myself clear. I suggested to lock handles only while accessing them. GNO's Kernel does this quite a bit; it locks, dereferences, fiddles with memory, then unlocks. It does not ever assume a handle is in a particular spot unless it's also known to be locked. Jim, Even Matt gave up the "The System wasn't designed for XXX" argument some time ago. Progress, and all that. -Jawaid (PROCYON.INC, CAT15, TOP2, MSG:55/M530) YOU DON'T GIVE UP ON THE TRUTH >>> PROCYON.IN """""""""""""""""""""""""""""" > GNO doesn't context switch while a > process is inside the System Software. How do you keep GNO from switching inside signal handlers? That'd be a trick. > Even Matt gave up the "The System wasn't designed for XXX" argument some > time ago. Progress, and all that. You don't "give up" on the truth. The truth is that it's _not_ designed for that, and changing it to be that way is in no way, shape or form a priority. It's just not going to happen, leaving the problem to be addressed in the software that _makes_ it a problem: GNO. --Matt (I speak for myself, not for Apple) (M.DEATHERAGE, CAT15, TOP2, MSG:56/M530) LOCKING, DEREFING, PIDDLING, AND UNLOCKING NOT NECESSARY >>> Jawaid """""""""""""""""""""""""""""""""""""""""""""""""""""""" > So, it's just > applications; and you both misread me, or I didn't make myself clear. > I suggested to lock handles only while accessing them. > GNO's Kernel does this quite a bit; it locks, dereferences, fiddles > with memory, then unlocks. It does not ever assume a handle is in a > particular spot unless it's also known to be locked. Nope, I read you correctly the first time, it's you who didn't understand me. Locking, derefing, piddling, and then unlocking is exactly what I said you don't need to do, as long as you don't make a toolbox call. I do this, the System Software does this, things that I've added to the System Software do this, programs written since 1986 do this, etc. By mentioning that even the System Software does this, I was making the point that Apple has said this technique is valid and will continue to remain valid for the existence of the IIgs, or the end of the planet, whichever comes first. If you're not going to cause memory to be compacted, either directly or indirectly (by making a toolbox call that allocates memory), there is no need, under the IIgs memory architecture to always lock memory when you access it, plain and simple. -Jim Murphy (A2PRO.JIM [Murph'], CAT15, TOP2, MSG:57/M530) A SOLUTION WOULD BE NICE REGARDLESS OF WHOSE PROBLEM IT IS I agree with """""""""""""""""""""""""""""""""""""""""""""""""""""""""" Matt that this is GNO's problem, not the system software's, yet it would still be way cool to have a solution that would work reliably without a great deal of overhead. The fact that the Memory Manager has at least one problem (not a bug, really, just a feature that might be done better) suggests another alternative: Jawaid, the Memory Manager is small, rewrite it. Yours could take over after the fact as long as it used the same data structures as Apple's, and as long as it kept those same data structures, you could even embed it in GNO and return control to the standard Memory Manager when GNO exits. In your own Memory Manager, you could impose one additional restriction: when a program that can be switched asks for memory, don't purge or move memory unless it belongs to some program you know about. You could make up for a lot of the losses this would cause by allowing your Memory Manager to move blocks around other, fixed blocks, which Apple's doesn't do. (Or at least, didn't do the last time I checked. This is the problem I alluded to earlier.) For the record, all of the ORCA products are designed to lock handles before they are used. If any of them are causing you problems, it's a bug. Let me know and I'll fix it. Mike Westerfield (BYTEWORKS, CAT15, TOP2, MSG:58/M530) GEE, LOOKS LIKE I DUG UP A CAN OF WORMS! >>> M.DEATHERAGE """""""""""""""""""""""""""""""""""""""" >>> MORGAN-DAVIS >>> PROCYON.INC >>> A2PRO.JIM [Murph'] > The System Software's paradigm, for better or worse, is "unlocked > handles are safe unless you do something that moves them." Gee, looks like I dug up a can of worms! :-) Obviously, locking a handle any time you access it makes the most sense, but as it's already been stated, the rules already say it isn't necessary, and it's very hard to change the rules. Mostly because of everything that's already been written following the rules. Two other solutions I can think of are the one Morgan mentioned, and the other would be any time GNO pre-empts a process, lock all of its handles. This would probably be easier to implement than the separate heap idea, but it would probably be dangerous on programs that use a lot of memory, especially if memory is becoming scarce. There may be plenty of free space, but compacting won't get you anything because all the memory belongs to one application that happens to be switched out at the moment... _ |_)avid |\/|iller (D.MILLER132 [GTerm] [Dave], CAT15, TOP2, MSG:59/M530) >>> MESSAGE SPOTLIGHT <<< """"""""""""""""""""""""" Category 36, Topic 11 Message 83 Wed Mar 03, 1993 BYTEWORKS at 14:56 EST The problem with sizeof and many of the libraries, especially the string handling libraries that return lengths, is that the size actually varies in the various dialects of C, and sometimes even in the same C compiler. In K&R C, sizeof and strlen return int. In ANSI C, they return something of type size_t, which is defined as an integer big enough to hold the largest pointer, with the implication that for efficiencies sake, it should be the smallest integer that fits the requirement. In at least one implementation of Turbo C, size_t was a 16 bit value for one memory model and 32 bits for another, and that's with the same compiler! You have to couple that with the fact that it is _your_ responsibility, not the compiler's, to make sure that all of the parameters you pass are used. Many compilers do some stack clean up more or less by accident, because it's the most efficient way to use the machine, and a lot of C programmer's have erroneously assumed that this is a requirement of C. It isn't. Any C compiler is perfectly within it's rights to crash when it hits a statement like printf("%ld\n", 4); and with optimizations on, ORCA/C just might do that. (With optimizations off, ORCA/C inserts some very time consuming code to "fix" the stack. It works most of the time, but not all of the time. Of course, the stack repair on other compilers doesn't work all of the time, either. ORCA/C also has a debug option to help track down these bugs.) This leaves you with a problem: you don't know how big the value returned by sizeof actually is, unless you nail your question down to a particular memory model of a particular version of a particular compiler, and then you've defeated the supposed "portability" of C. The only safe, portable way to code these statements is with an explicit type cast, like this: printf("%lu\n", (unsigned long) sizeof(int)); printf("%lu\n", (unsigned long) strlen("Hi")); You could, of course, get by with casting the result to int or unsigned, but on most modern computers, using the largest memory model available, it's possible for either of these functions to return a value greater than the maximum allowed integer. I showed the most general case, and one that will work on every C compiler that I'm aware of. Mike Westerfield [*][*][*] While on GEnie, do you spend most of your time downloading files? If so, you may be missing out some excellent information in the Bulletin Board area. The messages listed above only scratch the surface of what's available and waiting for you in the bulletin board area. If you are serious about your AII, the GEnieLamp staff strongly urge you to give the bulletin board area a try. There are literally thousands of messages posted from people like you from all over the world. [EOA] [RAM]/////////////////////////////// RAMBLINGS / ////////////////////////////////// Ramblings from a 'Wannabe' Programmer """"""""""""""""""""""""""""""""""""" By Larry E. Elseman [L.ELSEMAN1] >>> WHY PROGRAM? <<< """""""""""""""""""" procedure WhyProgram; begin writleln 'Why do you program?'; readln (i); case i of 1: ForFame; 2: ForMoney; 3: ForSatisfaction; 4: ForCareer; 5: ForFun; 6: ForBabes; 7: ForHunks; otherwise: ForGetIt; end; procedure ForFame; begin writeln 'I want to be famous!'; end; procedure ForMoney; begin writeln 'I want to be rich!'; end; procedure ForSatisfaction; begin writeln 'I want to be happy!'; end; procedure ForCareer; begin writeln 'I want a good job!'; end; procedure ForFun; begin writeln 'I enjoy it!'; end; procedure ForBabes; begin writeln 'I want to meet women!'; end; procedure ForHunks; begin writeln 'I want to meet men!'; end; procedure ForGetIt; begin writeln 'EXCUSES not to program!'; EXCUSES := true; end; procedure WhyNot; begin If not EXCUSES then begin WhyProgram; end Else begin StartArticle; end end; BEGIN {Main} WhyProgram; WhyNot; END. procedure StartArticle; begin [*][*][*] What the heck am I trying to say here? Well in my warped twisted way, what I'm saying is that everyone has their reasons for programming, just as everyone who doesn't program has a reason or an EXCUSE. If I eliminate people who don't use computers, then that leaves us with people who do use computers... duh. Okay, so if you use computers and don't program, I'm asking 'Why don't you program?' And if you do program, what keeps you from programming more? Here are some of my own personal reasons (EXCUSES) for not programming more: I. I am not a professional programmer. II. I have a full time job, which doesn't involve programming. III. I have a family. IV. I don't have time. A. I have other activities outside of work. 1. Share taxi duties with wife, shuttling kids around town. 2. Little League administrator. 3. Chores around the house (Honey-do's). 4. Attending night school. B. I need time for other things. 1. Spend time with my wife (alone, if possible :)) 2. Love to golf. 3. Enjoy playing on computer/Sega. V. I don't know how to write the applications I would like to program. A. Need to learn powerful languages to program the GS. 1. Orca Pascal. 2. Orca M. 3. Micol Advanced Basic. B. Need more time to learn those languages (see IV). As you can see, time is my biggest stumbling block (EXCUSE) to becoming a 'real' programmer. How about you? For some people they have the time, but programming logic is their stumbling block. Try this: Remove lines from this equation until both sides are equal. But do it by removing as few lines as possible: XI + I = X Come on, that's easy... you can do it in just one move; place the second 'I' after the right 'X' to give you: XI + = XI Right?.... WRONG! Just look at the equation upside down! Zero lines moved. Logic; sometimes the obvious is too hard. But that's also what makes programming so doggone much fun. There are many ways to solve a problem, and probably just as many ways to code a solution to the problem. For me programming is a release from the pressure and stress of day to day living (Of course programming itself can be pressure packed and stressful too, but that's another topic). And programming is fun. I find it very exhilarating to get a program up and running, just exactly like I had planned it. Making that pile of silicon and plastic respond according to my wishes is a terrific high. On GEnie I have found knowledgeable people who are very talented at programming and offer their expertise to your programming questions. Use them to your advantage. Learn from their mistakes and achievements. You'll be on the road to programming success. Don't use the EXCUSE; 'Well, no one is available to help me', because the folks at A2 Pro, and everyone who accesses it are here to help! [EOA] [DEV]////////////////////////////// DEVELOPER'S CORNER / ///////////////////////////////// News from the A2Pro Online Developers """"""""""""""""""""""""""""""""""""" By Jim B.Couch [J.COUCH2] >>> ONLINE SUPPORT IN A2PRO <<< """"""""""""""""""""""""""""""" CAT COMPANY --- ------------------------ 30 Procyon, Inc. 31 Softdisk Publishing 32 Morgan Davis Group (MDG) 33 GS+ Magazine 34 JEM Software 35 Lunar Productions 36 The Byte Works Each month this column feature highlights and news from various developers who provide support via A2Pro: >>> NEWS FROM SOFTDISK PUBLISHING <<< """"""""""""""""""""""""""""""""""""" SOFTDISK REORGANIZATION BRINGS CHANGES Recently we had a big re-org here """""""""""""""""""""""""""""""""""""" at Softdisk, and one of the results is that we (Softdisk and Softdisk G-S) are now part of the "Apple Development Group", or ADG as we like to call it. ADG is Softdisk, Softdisk G-S and Diskworld (our Macintosh product). So, something we are looking for are articles that can apply to all platforms. For example, recently Joe Kohn wrote an article about HP printer solutions for Softdisk G-S. In about an hour one of our Mac people "ported" it to Diskworld. As another example, Tim Tobin is writing us an article on removable mass storage options (SyQuest, Floptical, Magneto-Optical, etc) and he's writing for the GS but keeping in mind the Macintosh. So, where does this leave us? Well, we'd like to see some of the following articles: - controlling home electrical stuff with your GS/Mac (X-10??) - solutions for the handicapped - CD-ROM, the ins and outs - ??? If you're interested in writing an article on any of the above, or have ideas of your own, please, contact us...we pay anywhere from $75 to $250 for articles. You can reach us at this address (SOFTDISK.INC) or you can call Lee Golden at 1-318-221-2173. -Bryan (SOFTDISK.INC [Zak], CAT31, TOP3, MSG:25/M530) >>> NEWS FROM GS+ MAGAZINE <<< """""""""""""""""""""""""""""" GS+ PHONES DOWN DURING STORM For the past week, the phones here at GS+ """""""""""""""""""""""""""" Magazine have gone unanswered. The reason for this is that due to the "Storm of the Century" we have been without power all week. No power means, among other things, no answering machine and no fax machine. We apologize for any concern this may have caused, but be assured that we are NOT out of business. At approximately 4:30 p.m. Eastern Time on Thursday, March 18th, the power came back on. We have resumed our normal operations as of 9 a.m., Friday, March 19th. Now of course, we have to make up four lost days and try to get things back on schedule. Please spread the word that while we will be working as hard as we can, the next issue of GS+ Magazine may arrive a little later than expected. Thanks for your patience. -Everyone at GS+ Magazine (JWANKERL [Joe], CAT33, TOP4,, MSG:18/M530) >>> NEWS FROM JEM SOFTWARE <<< """"""""""""""""""""""""""""""" HOW MUCH ARE JEM PRODUCT UPGRADES? I read in the last AWKS Forum that """""""""""""""""""""""""""""""""" updates for JEM products were $5.00. I sent for and update to TotalControl, but you stated in a recent post in the A2 area that they are $13.00. Did I misunderstand the NAUG notice? I sent for the update last week. I need it pretty bad. Thanks. -John King (J.KING26 [JohnK], CAT34, TOP2, MSG:62/M530) IT DEPENDS Bug fix disks are always $5 to just cover the cost of the disk """""""""" and shipping and handling. A feature upgrade is usually $10 plus $3 s/h. (BRANDT [Randy], CAT34, TOP2, MSG:64/M530) >>> NEWS FROM LUNAR PRODUCTIONS <<< """"""""""""""""""""""""""""""""""" TELL ME ABOUT FOUNDATION VS GENESYS Hi, I'm taking the Introduction to """"""""""""""""""""""""""""""""""" Resources course and have a question about Foundation. (Forwarded here as suggested by Matt D.) I know that Mr. Wolfgram worked on Genesys and now Foundation, and that they're separate products. I've also heard that Genesys does some things that Foundation (as yet) cannot. What and why not? Thanks and, editors haven't been discussed in the course yet, so you're dealin' with a layman here. :) (P.CREAGER [Wily], CAT35, TOP1, MSG:8/M530) MY CHOICE IS FOUNDATION Well, I'm not Marc, but I can answer your """"""""""""""""""""""" question.. First, why Foundation can't do what Genesys can. Because Foundation has a radically different, uh, foundation! # Genesys right now supports "graphical" editing of a lot of different resource types. (although beware, the editing is System 5.0 based and you may "damage" some resource types in some cases, for example Lists that have the scroll bars drawn inside the bounds rect). Foundation doesn't yet have graphical editors for the major resource types-- why? because they were only three people and there were only 24 hours in a day. :) I'm sure Marc will be along to let you know the time frame, but my understanding is that full graphical editors are forthcoming. In any case, while using Genesys is a Bad Idea, Foundation CAN be used to edit any resource type. Either ScriptEdit or HexEdit can be used. It's better than nothing, but not as good as a graphical editor. My choice? Foundation, easily. -Bryan (SOFTDISK.INC [Zak], CAT35, TOP1, MSG:9/M530) FOUNDATION AUTHOR COMPARES BOTH PROGRAMS Thanks Bryan! That was well """""""""""""""""""""""""""""""""""""""" stated! Willy, both Genesys and Foundation have individual strengths that make both of them useful in different ways. As Bryan pointed out, Genesys has a somewhat complete set of "Graphic" resource editors. It also can generate source for a number of languages. It's drawbacks are its total lack of support for System 6 resource structures, and non-existant company support -- there won't be an update to Genesys as far as I can tell. Foundation's strengths are numerous, but as of today, the only "Graphic" editor available for it is SoundREM from Mike Nuzzi at Triad Ventures. As Bryan mentioned, additional editors will be forthcoming! We are almost done with a combination rIcon/rBundle editor that will be packaged with the Foundation 1.0.3 update in mid April. What Foundation does have right now, is a full HexASCII generic editor that allows you to edit ANY resource, be it a standard from System 5 or System 6, or a custom resource that you or someone else created. Foundation also comes with a ScriptEditor, which is a template driven universal editor. Right now there are some limitations in what it can edit, but this too will pass (hopefully by mid April as well). We concentrated on building a lot of useful features into the Foundation application, including full recognition of System 6 resource structures and dependencies, and multiple file support. This means that you can select a MenuBar in on file, and copy/paste it into another file AND all the associated Menus, MenuItems, Pascal Strings and whatever are copied as well. It also lets you delete resources safely, telling you if the resource is used by something else, and also allowing a whole resource dependency tree to be deleted at once. We have dynamic resource naming, fork optimization, dependency walking and a bunch of other really nice features built right into the program. Foundation includes a developers kit with sample source code and the full documentation of the editor interface and 40 odd shell support functions. Yes, I was party to SSSi's Genesys...In fact I use Genesys a lot to prototype windows and alerts. However, Foundation lets me manage these a lot nicer, and it isn't bound by the "System 5 Only" resource limitations in Genesys. We're working hard to bring the "Graphic" advantage to our product, but wanted a solid, er, foundation in place on which to build :) -Marc Wolfgram Lunar Productions (M.WOLFGRAM2 [Lunar Host], CAT35, TOP1, MSG:10/M530) >>> NEWS FROM THE BYTE WORKS <<< """"""""""""""""""""""""""""""""" TELL ME ABOUT PROGRAMMING THE TOOLBOX I would like to know more about the """"""""""""""""""""""""""""""""""""" programming of the toolbox and what need to do in order to use it, also some more detail on ORCA/Pascal itself. -Dave (D.GANEZER [DAVE], CAT36, TOP22, MSG:1/M530) CHECK OUT BYTEWORKS TOOLBOX PROGRAMMING COURSE Toolbox Programming in """""""""""""""""""""""""""""""""""""""""""""" Pascal is a self-contained course. You need ORCA/Pascal and a computer, but no other books or reference material. The basic requirements for your computer are: 1. 1.75M of memory, 2M or more recommended. 2. A hard drive. You can get by with 2 or 3 3.5" floppy drives, but I'll have to give you some tips if you want to try it. 3. A color screen is nice, especially for the graphics chapters, but it isn't actually required. 4. A printer that works with Apple's Print Manager is needed for the sections that deal with printing, although you can skip those sections if you like. The course comes with an abridged toolbox reference manual that will get you through the course and all of the problems. If you already have the Toolbox Reference manuals, great -- the course will teach you how to use them. If you do not have the Toolbox Reference manuals, yet, I'd suggest starting without them. You need to have the Toolbox Reference manuals before you start writing your own programs, but you don't need them right away. About half way through the course, if you like what you are doing and intend to go on, you'll want to start buying the reference books. The course itself has a brief description of the various reference books; that will help you decide which ones to buy, and in what order. ORCA/Pascal itself is a complete development system for writing Pascal programs. You'll find a short description of it in our online catalog (topic 1 in this category). If you'd like more detailed information, you can ask questions, or send me your mailing address and I'll get some printed material off to you. -Mike Westerfield (BYTEWORKS, CAT36, TOP22, MSG:3/M530) [EOA] [A2U]////////////////////////////// A2U CAMPUS CHAT / ///////////////////////////////// A2 University; Learning Online """""""""""""""""""""""""""""" By Jim B. Couch [J.COUCH2] >>> A2U COURSES CONTINUE <<< """""""""""""""""""""""""""" ---+----+--------------------\ @ |Fila| Redactar Ventanas < A2 University is in Session! ---+----+---------------+----/ | Sobre Finder... | Introduction to Resources | Ayuda... @? | with Marc Wolfgram of Lunar Productions |--------------------| | Panel de Controles | No, we won't teach you Spanish, but... +--------------------+ ...we _will_ show you how to customize many System 5 and System 6 applications that use resources to fit your needs -- changing the language is just an example. To learn what resources are and how they can help you customize your applications, be sure to visit the A2Pro Real Time Conference on Wednesdays at 9:30pm EST, or visit A2U (Category 22) in the A2Pro bulletin board. You don't have to be an official participant in the course to attend, and the first three lessons are now available! This course will be followed by a more technical course aimed at participants in the first course, and programmers interested in furthering their skills with resources Both are taught by Marc Wolfgram, who helped develop both Genesys and Foundation, two popular resource editors. >>> A2U DATA COMPRESSION CONFERENCES CANCELED <<< """"""""""""""""""""""""""""""""""""""""""""""""" Current A2U RTC Schedule ------------------------ Wednesdays @ 9:30 EST - Intro to Resources with Marc Wolfgram. NOTE: The Data compression conferences, due to lack of attendance, have been cancelled until the final lesson is released. If you want to see the conferences, post that why in the discussion topic for Andy's course. (A2PRO.STEVE, CAT22, TOP5, MSG:2/M530) [EOA] [LIB]////////////////////////////// ONLINE LIBRARY / ///////////////////////////////// April is Tech Notes month! """""""""""""""""""""""""" By Jim B. Couch [J.COUCH2] >>> GET THE LATEST TECH NOTES NOW! <<< """""""""""""""""""""""""""""""""""""" Matt Deatherage has been very busy this past month uploading ALL of the Apple II Tech Notes! There is one mega file that contains ALL of the Tech Notes AND all of the File Type Notes. For those who do not need the File Type Notes there is also a mega file that contains ALL the Tech Notes, but no file Type Notes. There are also numerous files with separate File Type Notes if you don't need the whole wad! ------------ Number: 3139 Name: ALL.TNS.BXY Address: M.DEATHERAGE Date: 930214 Approximate # of bytes: 828160 Number of Accesses: 2 Library: 2 This archive contains all the Technical Notes (but not File Type notes) released by Apple Computer as of 6/92, which was the last released batch. Downloading this archive gives you _all_ the current Technical Notes. Keywords: Apple,TN,Technical,Technote,Notes,DTS ------------ Number: 3140 Name: ALL.NOTES.BXY Address: M.DEATHERAGE Date: 930214 Approximate # of bytes: 1078912 Number of Accesses: 23 Library: 2 This archive contains all the Technical Notes and File Type Notes released by Apple Computer as of 6/92, which was the last released batch. Downloading this archive gives you _all_ the current Technical Notes and File Type Notes; you'll have every one of them and can throw all your older ones away. Keywords: Apple,TN,FTN,Technical,Technote,Filetype,File Type,DTS ------------ Number: 3125 Name: ATALK.TNS.BXY Address: M.DEATHERAGE Date: 930213 Approximate # of bytes: 49536 Number of Accesses: 2 Library: 2 This archive contains all the AppleTalk Technical Notes released by Apple Computer as of 6/92, which was when the last release happened. This archive contains the AppleTalk Technical Notes, the Technical Note Index and 'About Technical Notes' so you can find other Notes more easily. The contents of this archive completely replace any older versions of AppleTalk Technical Notes you may have. Keywords: Apple,TN,Technical,Technote,DTS,AppleTalk,ATLK ------------ Number: 3126 Name: IIE.TNS.BXY Address: M.DEATHERAGE Date: 930213 Approximate # of bytes: 103808 Number of Accesses: 3 Library: 2 This archive contains all the Apple IIe Technical Notes released by Apple Computer as of 6/92, which was when the last release happened. This archive contains the Apple IIe Technical Notes, the Technical Note Index and 'About Technical Notes' so you can find other Notes more easily. The contents of this archive completely replace any older versions of Apple IIe Technical Notes you may have. Keywords: Apple,TN,Technical,Technote,DTS,Apple IIe,IIe,AIIe ------------ Number: 3128 Name: IIC.TNS.BXY Address: M.DEATHERAGE Date: 930213 Approximate # of bytes: 44672 Number of Accesses: 1 Library: 2 This archive contains all the Apple IIc Technical Notes released by Apple Computer as of 6/92, which was when the last release happened. This archive contains the Apple IIc Technical Notes, the Technical Note Index and 'About Technical Notes' so you can find other Notes more easily. The contents of this archive completely replace any older versions of Apple IIc Technical Notes you may have. Keywords: Apple,TN,Technical,Technote,DTS,Apple IIc,IIc,AIIc ------------ Number: 3129 Name: GSOS.TNS.BXY Address: M.DEATHERAGE Date: 930213 Approximate # of bytes: 75776 Number of Accesses: 4 Library: 2 This archive contains all the GS/OS Technical Notes released by Apple Computer as of 6/92, which was when the last release happened. This archive contains the GS/OS Technical Notes, the Technical Note Index and 'About Technical Notes' so you can find other Notes more easily. The contents of this archive completely replace any older versions of GS/OS Technical Notes you may have. Keywords: Apple,TN,Technical,Technote,DTS,GS/OS,GSOS ------------ Number: 3130 Name: HCGS.TNS.BXY Address: M.DEATHERAGE Date: 930213 Approximate # of bytes: 37120 Number of Accesses: 4 Library: 2 This archive contains all the HyperCard IIgs Technical Notes released by Apple Computer as of 6/92, which was when the last release happened. This archive contains the HyperCard IIgs Technical Notes, the Technical Note Index and 'About Technical Notes' so you can find other Notes more easily. The contents of this archive completely replace any older versions of HyperCard IIgs Technical Notes you may have. Keywords: Apple,TN,Technical,Technote,DTS,HyperCard IIgs,HyperCard,HCGS ------------ Number: 3131 Name: IIGS.TNS.BXY Address: M.DEATHERAGE Date: 930213 Approximate # of bytes: 458368 Number of Accesses: 6 Library: 2 This archive contains all the Apple IIgs Technical Notes released by Apple Computer as of 6/92, which was when the last release happened. This archive contains the Apple IIgs Technical Notes, the Technical Note Index and 'About Technical Notes' so you can find other Notes more easily. The contents of this archive completely replace any older versions of Apple IIgs Technical Notes you may have. Keywords: Apple,TN,Technical,Technote,DTS,Apple IIgs,IIgs,GS ------------ Number: 3132 Name: MISC.TNS.BXY Address: M.DEATHERAGE Date: 930213 Approximate # of bytes: 76544 Number of Accesses: 1 Library: 2 This archive contains all the Apple II Miscellaneous Technical Notes released by Apple Computer as of 6/92, which was when the last release happened. This archive contains the Apple II Miscellaneous Technical Notes, the Technical Note Index and 'About Technical Notes' so you can find other Notes more easily. The contents of this archive completely replace any older versions of Apple II Miscellaneous Technical Notes you may have. Keywords: Apple,TN,Technical,Technote,DTS,Miscellaneous,Misc ------------ Number: 3133 Name: MOUSE.TNS.BXY Address: M.DEATHERAGE Date: 930214 Approximate # of bytes: 41728 Number of Accesses: 2 Library: 2 This archive contains all the Apple II Mouse Technical Notes released by Apple Computer as of 6/92, which was when the last release happened. This archive contains the Apple II Mouse Technical Notes, the Technical Note Index and 'About Technical Notes' so you can find other Notes more easily. The contents of this archive completely replace any older versions of Apple II Mouse Technical Notes you may have. Keywords: Apple,TN,Technical,Technote,DTS,Mouse ------------ Number: 3134 Name: PASCAL.TNS.BXY Address: M.DEATHERAGE Date: 930214 Approximate # of bytes: 73600 Number of Accesses: 3 Library: 2 This archive contains all the Apple II Pascal Technical Notes released by Apple Computer as of 6/92, which was when the last release happened. This archive contains the Apple II Pascal Technical Notes, the Technical Note Index and 'About Technical Notes' so you can find other Notes more easily. The contents of this archive completely replace any older versions of Apple II Pascal Technical Notes you may have. Keywords: Apple,TN,Technical,Technote,DTS,Pascal,Pasc ------------ Number: 3135 Name: PRODOS8.TNS.BXY Address: M.DEATHERAGE Date: 930214 Approximate # of bytes: 110976 Number of Accesses: 4 Library: 2 This archive contains all the ProDOS 8 Technical Notes released by Apple Computer as of 6/92, which was when the last release happened. This archive contains the ProDOS 8 Technical Notes, the Technical Note Index and 'About Technical Notes' so you can find other Notes more easily. The contents of this archive completely replace any older versions of ProDOS 8 Technical Notes you may have. Keywords: Apple,TN,Technical,Technote,DTS,ProDOS 8,P8,PDOS ------------ Number: 3136 Name: SMTPORT.TNS.BXY Address: M.DEATHERAGE Date: 930214 Approximate # of bytes: 43520 Number of Accesses: 5 Library: 2 This archive contains all the SmartPort Technical Notes released by Apple Computer as of 6/92, which was when the last release happened. This archive contains the SmartPort Technical Notes, the Technical Note Index and 'About Technical Notes' so you can find other Notes more easily. The contents of this archive completely replace any older versions of SmartPort Technical Notes you may have. Keywords: Apple,TN,Technical,Technote,DTS,SmartPort,SmtPort,SmPt ------------ Number: 3137 Name: UNIDISK.TNS.BXY Address: M.DEATHERAGE Date: 930214 Approximate # of bytes: 39424 Number of Accesses: 3 Library: 2 This archive contains all the UniDisk 3.5 Technical Notes released by Apple Computer as of 6/92, which was when the last release happened. This archive contains the UniDisk 3.5 Technical Notes, the Technical Note Index and 'About Technical Notes' so you can find other Notes more easily. The contents of this archive completely replace any older versions of UniDisk 3.5 Technical Notes you may have. Keywords: Apple,TN,Technical,Technote,DTS,UniDisk 3.5,UniDisk ------------ Number: 3138 Name: IW.MEMX.TNS.BXY Address: M.DEATHERAGE Date: 930214 Approximate # of bytes: 3456 Number of Accesses: 2 Library: 2 This archive contains all the ImageWriter and Memory Expansion Technical Notes released by Apple Computer as of 6/92, which was when the last release happened. This archive contains the Technical Notes (both of them). It does _NOT_ contain 'About Technical Notes' or the Technical Note Index to keep the archive size down -- those Notes are in all the other Note archives here in A2Pro. The contents of this archive completely replace any older versions of ImageWriter or Memory Expansion Technical Notes you may have. Keywords: Apple,TN,Technical,Technote,DTS,ImWr,ImageWriter,MemX,Memory, Slinky [*][*][*] >>> A2PRO LIBRARY REORGANIZATION COMPLETED! <<< """""""""""""""""""""""""""""""""""""""""""""" Matt Deatherage is not the only person who has been busy this month. Todd Whitesel has been engaged with the A2Pro library reorganization. Todd has arranged the library so that files will be much easier to find. These alterations reflect the changing nature of programming on the Apple II and I think you will agree that Todd has done a wonderful job! YOWZA! YOWZA! A2PRO REORGANIZATION NOW COMPLETE! Historically, the """""""""""""""""""""""""""""""""""""""""""""""" general areas of the A2PRO library have been divided along the boundaries of programming languages. This made sense a long time ago, because the Apple programming world was much smaller and more isolated than it is now. These days, the environment you're writing your program for is usually more important than the language (or languaGES) your program will be written in. To reflect this, the entire library has been in a state of flux for nearly four weeks (yeah, I know, sorry bout how long it took) and is now fully reorganized around a new set of criteria that, while it isn't perfect yet, should at least make it a lot easier to find things by library number. A couple of the categories turned out to get rather large, though, so I'll probably split them up in a little while when I can think of a good, clear criteria for dividing them. When this happens, it will be far less traumatic because there is reserved space for them to expand into, and no other libraries will need to move to accommodate them. All the changes were to the general area (libraries 1 through 29). Here is a listing of the 'final' categories: 1. A2Pro Archives and Transcripts 2. Apple II Tech Notes 3. Apple II File Type Notes 4. Apple II Sample Code 5. System Software 6. Help me! ... Problem source uploads 7. Categorize me! & General Uploads. 8. 8-bit development, AppleSoft, HyperC 9. Archive Tools (Shrinkit/Stuffit/BNY) 10. A2 University (A2U) 11. Theory and General Techniques 12. The Reference Shelf: Specs and Info 13. HyperCard IIgs and HyperStudio 14. Resources: REZ, Tools, and Utilities 15. Miscellaneous Programming Utilities 16. Interface Files, Macros, & Libraries 17. Debugging Tools (GSBUG, Nifty List) 18. Other IIgs Languages (BASIC, FORTH) 19. Shells and Shell Utilities (EXE's) 20. Classic Desk Accessories and Inits 21. Desktop Programs and GUI code 22. Reserved 23. Practice: Putting it all Together 24. Reserved 25-29.Reserved In most cases the titles should be self-explanatory. There are now descriptions available (yeah, that option #1 that never printed anything before, now it actually says something for most of them). Don't worry about getting confused by the new structure. I thought of the whole flaming thing and even _I_ can't make up my mind about where some of those files ought to go! That's why there is library #7. If no other category seems to fit, or you just can't decide between two or three libraries that look like good places to put the file, just upload it to #7 and let _me_ lose sleep trying to figure out where to put it. (Of course, I reserve the option to punt and let it stay in library #7, which is what I did with a few files from the old organization that don't seem to fit _anywhere_ in the new scheme -- some of them probably belong in A2 but I don't have the heart to evict them yet.) Any comments or helpful suggestions you can think of are appreciated -- post them in cat 1 topic 3 or (if you don't want them read in public) mail them to A2PRO$ so that all the sysops (not just me) will see them. That way if I don't see the value of your idea but somebody else does, they can beat me over the head with a cat-o-nine-ball-less-mice until I repent. Enjoy! -Todd Whitesel (A2PRO.TODDPW [growf?], CAT1, TOP17, MSG:66/M530) >>> HOT FILES YOU CAN DOWNLOAD <<< """""""""""""""""""""""""""""""""" File # Filename Description """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" 3207 A2U.ULTRA4.BXY [8bit] All msgs from the A2U Ultra 4 course 3206 TMPROGINFO.BXY [IIgs] Programmer Info for The Manager 3205 INDEX.ADB.BXY March Index of Topics (ADB Re-Up) 3203 A2U.RES.3.BXY [IIgs] Lesson 3 in the A2U Resource Intro 3202 ADVSRC.BXY [IIgs] APW C source to orig. Adventure 3201 ADPCM1.1.BXY [IIgs] Newer version of 16-bit ADPCM source 3198 A2NDX0393DB.BXY A2 Cat/Top Index - Mar '93 (ADB) 3197 A2NDX0393TX.BXY A2 Cat/Top Index - Mar '93 (TXT) 3196 ULT.PROG.01.BXY Old msgs -- Ultra Programming 3195 U.QUIRKS.02.BXY Old msgs -- Ultra Quirks 3192 INDEX.TXT.BXY March 93 A2PRO Topic Index (TXT) 3186 A2U.RES.2.BXY [IIgs] Resource Introduction Lesson 2 3178 SYS.DISK.P8.BXY [8bit] Prodos 8 System Disk 4.0.1 3173 A2U.RES.1.BXY [IIgs] A2U Resource Introduction, lesson 1 3142 ORCAQUIKREF.BXY [IIgs] Orca Editor 2.0 Quick Reference 3141 ROBCMDS.BXY [8bit] external commands for Davex 3140 ALL.NOTES.BXY All TNs and FTNs as of 6/92 """""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" [EOA] [EOA] [LOG]////////////////////////////// LOG OFF / ///////////////////////////////// GEnieLamp Information """"""""""""""""""""" o COMMENTS: Contacting GEnieLamp o GEnieLamp STAFF: Who Are We? o GET_THE_LAMP Scripts & Macros o SEARCH-ME! Answers GEnieLamp GEnieLamp is monthly online magazine published in the """"""""" GEnieLamp RoundTable on page 515. You can also find GEnieLamp in the ST (475), the Macintosh (605), the IBM (615) Apple II (645), A2Pro (530), Unix (160), Mac Pro (480), Geoworks (1050), BBS (610), CE Software (1005) and the Mini/Mainframe (1145) RoundTables. GEnieLamp can also be found on CrossNet, Internet, America Online and many public and commercial BBS systems worldwide. We welcome and respond to all GEmail.To leave messages, suggestions or just to say hi, you can contact us in the GEnieLamp RoundTable (515) or send GE Mail to John Peters at [GENIELAMP] on page 200. U.S. MAIL """"""""" GEnieLamp Online Magazine Atten: John Peters 5102 Galley Rd. Suite 115/B Colorado Springs, CO 80915 >>> GEnieLamp STAFF <<< """"""""""""""""""""""" GEnieLamp o John Peters [GENIELAMP] Editor-In-Chief """"""""" ATARI ST o John Gniewkowski [J.GNIEWKOWSK] Editor """""""" o Mel Motogawa [M.MOTOGAWA] ST Staff Writer o Terry Quinn [TQUINN] ST Staff Writer o Sheldon Winick [S.WINICK] ST Staff Writer o Richard Brown [R.BROWN30] ST Staff Writer o John Hoffman [JLHOFFMAN] ST Staff Writer o Al Fasoldt [A.FASOLDT] ST Staff Writer ATARI ST/TX2 o Cliff Allen [C.ALLEN17] Editor/TX2 """""""""""" ATARI [PR] o Fred Koch [F.KOCH] Editor/PD_Q """""""""" IBM o Robert M. Connors [R.CONNORS2] Editor """ o Peter Bogert [P.BOGERT1] IBM Staff Writer o Brad Biondo [B.BIONDO] IBM Staff Writer o Tippy Martinez [TIPPY.ONE] IBM Staff Writer o David Holmes [D.HOLMES14] IBM Staff Writer MACINTOSH o James Flanagan [JFLANAGAN] Editor """"""""" o Richard Vega [R.VEGA] Mac Co-Editor o Dan "Remo" Barter [D.BARTER] Mac Staff Writer o Tom Trinko [T.TRINKO] Mac Staff Writer o Bret Fledderjohn [FLEDDERJOHN] Mac Staff Writer o Bill Garrett [BILL.GARRETT] Mac Staff Writer MacPRO o James Flanagan [JFLANAGAN] Editor """""" o Erik C. Thauvin [MACSPECT] Supervising Editor o Chris Innanen [C.INNANEN] MacPRO Staff Writer o Paul Collins [P.COLLINS] MacPRO Staff Writer APPLE II o Darrel Raines [D.RAINES] Editor """""""" o Phil Shapiro [P.SHAPIRO1] A2 Co-Editor o Mel Fowler [MELSOFT] A2 Staff Writer A2Pro o Jim B. Couch [J.COUCH2] Editor """"" o Nate C. Trost [N.TROST] A2Pro Staff Writer INTERNET o Jim Lubin [JIM.LUBIN] GEnieLamp IBM """""""" ETC. o Jim Lubin [JIM.LUBIN] Add Aladdin """" o Scott Garrigus [S.GARRIGUS] Search-ME! o Bruce Faulkner [R.FAULKNER4] CrossNET Support o Mike White [M.WHITE25] Cowlumnist/Asst. SysOp GEnieLamp CONTRIBUTORS """""""""""""""""""""" o Steven Weyhrich [S.WEYHRICH] o Gina Saikin [G.SAIKIN] o Paul Varn [P.VARN] o Larry E. Elseman [L.ELSEMAN1] o Les Blatt [L.BLATT] \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\//////////////////////////////////// Material published in this edition may be reprinted under the following terms only. All articles must remain unedited and include the issue number and author at the top of each article reprinted. Reprint permission granted, unless otherwise noted, to registered computer user groups and not for profit publications. Opinions present herein are those of the individual authors and does not necessarily reflect those of the publisher or staff of GEnieLamp. We reserve the right to edit all letters and copy. Include the following at the end or the beginning of every reprint: \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\//////////////////////////////////// (c) Copyright 1993 T/TalkNET Online Publishing and GEnie. To join GEnie, set your modem to 2400 baud (or less) and half duplex (local echo). Have the modem dial 1-800-638-8369. When you get a CONNECT message, type HHH. At the U#= prompt, type: XTX99014,DIGIPUB and hit the [return] key. The system will then ask you for your information. Call (voice) 1-800-638-9636 for more information. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\//////////////////////////////////// [EOF]