תוכנית TSR

בסביבת מערכת ההפעלה DOS, תוכנית TSR (ראשי תיבות באנגלית: Terminate and Stay Resident) היא תוכנית שנשארת בזיכרון לאחר סיומה. תוכנית רגילה מסיימת את פעולתה על ידי ביצוע קריאת מערכת שמשחררת את הזיכרון שהוקצה לה ומחזירה את השליטה למערכת ההפעלה. תוכנית TSR, לעומת זאת, משתמשת בקריאת מערכת ייעודית, שמסיימת את פעולת התוכנית אך מותירה חלק מוגדר מהזיכרון מוקצה עבורה. קריאת המערכת המקורית (INT 27h - ‏Terminate but Stay Resident) אפשרה להקצות לתוכנית עד 64K של זיכרון. החל מגרסה 2.0 של MS-DOS, הוצגה קריאת מערכת משופרת (INT 21h Function 31h - Keep Process) שהסירה את המגבלה הזו. מאחר ש-DOS אינה תומכת בריבוי משימות, ברגע שהתוכנית מסתיימת הקוד שלה חדל להיות פעיל. כדי לחזור לפעולה, על התוכנית לממש שגרת טיפול בפסיקה. באופן זה ניתן להעביר אליה את השליטה בהמשך באמצעות פסיקת תוכנה או חומרה. התוכנית יכולה ליירט, למשל, את פסיקת בקר המקלדת (IRQ 1), המשוגרת עם כל לחיצת מקש, כדי לבדוק אם נלחץ צירוף מקשים מסוים ולהגיב בהתאם. תוכנית TSR טיפוסית תחולק לשניים: חלק אתחול וחלק שוכן זיכרון (resident). חלק האתחול יכיל את כל הקוד שאיננו נחוץ לפעילות התוכנית כאשר היא מתפקדת "ברקע", כלומר לאחר החזרת השליטה ל-DOS באמצעות Keep Process. כשחלק זה מסיים את תפקידו הוא משחרר את הזיכרון שהוקצה עבורו, ובכך חוסך מקום בזיכרון.
אחד השימושים הבולטים והמזוהים ביותר עם טכניקת ה-TSR היה יישומי פופ-אפ, שהופעלו לרוב בלחיצת צירוף מקשים מסוים, ובאמצעות מימוש מנגנון של החלפת הקשר הצליחו לתת למשתמש חוויה של מעין ריבוי-משימות בסיסי ביותר. שימושים נוספים היו תוכנות שסיפקו ממשק להתקני חומרה (דומות מאוד למנהלי התקנים מבחינת התפקוד, אך טכנית הן אינן כאלה), או ששיפרו ממשק קיים; וכן תוכניות שביצעו מניפולציה על יישום בזמן הריצה כדי לתקן בו פגמים, או כדי לשנות או להוסיף לו פונקציונליות.
טכניקת ה-TSR זכתה אומנם לפופולריות רבה, אך היו לה כמה חסרונות בולטים. הן המשתמשים והן מפתחי התוכנה נאלצו להתמודד עם אילוצים שונים שנבעו מהאופן שבו DOS מנהלת את זיכרון המחשב, כשהבעיה העיקרית הייתה המקום שתפסו תוכניות ה-TSR בזיכרון הראשי (מתחת למחסום ה-640K) על חשבונם של יישומים אחרים. מאחר שהזיכרון הראשי היה מוגבל מאוד, כל תוכנית TSR שנטענה לזיכרון הפחיתה את יתרת הזיכרון הפנוי והגבילה עוד יותר את האפשרות להשתמש ביישומים הצורכים נפח זיכרון גדול. מנקודת מבטם של המפתחים, ששאפו לחיסכון מרבי בזיכרון, התכנות בטכניקה זו היה מורכב ומגושם וחייב רמה גבוהה של היכרות עם מערכת המחשב ושליטה בשפת סף. מתכנתי TSR השתמשו במגוון טכניקות ואלתורים כדי להתגבר על המגבלה ולצמצם ככל הניתן את צריכת הזיכרון של תוכנית ה-TSR. טכניקת ה-TSR זכתה לתמיכה רשמית בסיסית בלבד מצד מערכת ההפעלה, ויישום יעיל שלה חייב שימוש בקריאות מערכת שלא תועדו (אנ') בגרסאות מוקדמות של מערכת ההפעלה. אחד הקשיים היה הצורך לממש את החלפת ההקשר ברמת היישום, כמעט ללא תמיכה של מערכת ההפעלה. כמו כן היה על המתכנת להתחשב בעובדה ש-DOS ו-BIOS לא תוכננו לריבוי כניסות (reentrancy). לדוגמה, אם התוכנה הפעילה הייתה פונה ל-DOS באמצעות קריאת פסיקה, למשל כדי לקרוא מידע מקובץ, ותוך כדי הטיפול בקריאה זו התקבל קלט מהמקלדת שגרם להפעלת תוכנית ה-TSR וזו מצידה הייתה פונה גם כן ל-DOS, למשל כדי להציג פלט על המסך, אזי שתי הקריאות ל-DOS היו מתנגשות ומחזירות תוצאות שגויות או גורמות למחיקת נתונים וקריסת התוכנה. כדי לפתור את הבעיה נאלצו מפתחי ה-TSR לנטר את כל הקריאות של תוכנות אחרות לפסיקות החשובות להם, ולשמור את הקריאות של עצמן עד לאחר שהפסיקות הקודמות תסתיימנה, דבר שהפך את קוד תוכנת ה-TSR למורכב ומסורבל מאד.
טכניקה קרובה מאוד ל-TSR, שלא עשתה שימוש בקריאת Keep Process, הייתה לממש את שגרות הטיפול בפסקה, כבתוכנית TSR רגילה, ולאחר מכן להריץ יישום משנה (child process). בזמן שיישום המשנה פועל, התוכנית מתפקדת "ברקע" כתוכנית TSR - כלומר, הקוד שלה נשמר בזיכרון ומופעל כשמתבצעת הפסיקה הרלוונטית. שיטה זו התאימה לתוכניות שתוכננו לביצוע מניפולציה על יישום מסוים בזמן הריצה (ללא שינוי בעותק הפיזי שלו השמור בדיסק), כגון טלאי תוכנה, או טריינר שנועד למשחק מסוים. בנוסף, יש תוכניות שהשתמשו בשיטה זו כדי להריץ עותק נוסף של COMMAND.COM. מימוש זה יצר אפקט דומה מאוד לתוכנית TSR אמיתית, וחסך מהמתכנת את הצורך לטפל בשלב הסרת התוכנית מהזיכרון (uninstall): שלב זה בוצע באמצעות הפקודה EXIT של COMMAND.COM, שהחזירה את השליטה ליישום המפעיל (parent), שבתורו סיים את התוכנית בדרך הרגילה. החיסרון העיקרי בדרך זו היה הצורך לטעון לזיכרון שני עותקים של COMMAND.COM דבר שפגע ביכולת לטעון יישומים נוספים.