תוכנית התקנה

[gilad_no]

תוכנית התקנה

כתבתי יישום התקנה לתוכנות. אשמח לשמוע תגובות אם תמצאו בו שימוש. (כמו כן, אם יש הערות לגבי העיצוב - גם כן אשמח לשמוע

)

 

[אינגולמו]

קודם כל אחלה יוזמה...

לא בדקתי את התוכנה לעומק, אבל עושה רושם שיש את המינימום הדרוש. בכל זאת, עליך לקחת כמה דברים בחשבון, שאותם פירטתי מן הקל אל הכבד. חלקם רק בגדר המלצה, אבל שווה לך לקרוא לדעתי... ועדיין קבל ח"ח!

1. בשנים האחרונות, MS הכתיבה סטנדרט מאוד חשוב לגבי התקנות תחת WINDOWS. הוא מתיייחס בראש ובראשונה לניהול נכון של גירסאות ומוצרים לפי מספרי זיהוי ייחודיים הנקראים GUIDS. בגירסאות ישנות של WINDOWS (לפני WIN2000), לא היה צורך בהם, ועד היום יש עדיין תמיכה בשיטת ההתקנה הישנה והטובה. אבל לידע כללי, מנוע התקנה מודרני אמור לתמוך בכל הנחיות MS. 2. עדיין קשור לסעיף 1, MS פיתחה API ששמו MICROSOFT INSTALLER או MSI בקיצור, והוא אמור לדאוג (במידה ומשתמשים בו נכון) לכל ההגדרות במכונה. כל מה שמנוע ההתקנה צריך לעשות זה לספק את האינפורמציה הדרושה ל-API וזהו. כך יובטח לך שהתוכנה שהתקנת תופיע בחלון ה-ADD OR REMOVE PROGRAMS גם במערכות עתידיות, וכן שכל המידע הדרוש *לשינוי* ההתקנה הנוכחית (לא רק להסרה) יהיה קיים. 3. בהקשר לסעיף 2, מומלץ לתמוך בהוספה/הסרה של רכיבים *מתוך* האפליקציה. 4. הרבה מוצרים דורשים התקנה של SERVICES ו/או גישה למסדי נתונים דרך ODBC. מנועי התקנה מודרניים תומכים באופציות האלה. 5. מה קורה אם יש בעיה במהלך ההתקנה, או שהמשתמש לוחץ על CANCEL אחרי זמן מה? האם יש תמיכה במנגון ROLLBACK כלשהו? 6. ישנם מוצרים כיום, אשר משווקים למספר פלטפורמות (UNIX, NT וכו'). מנקודת המבט של הארגון, זה לא כ"כ משנה להם, והם רוצים מנוע התקנה CROSS PLATFORM. גם כזו חיה קיימת היום. 7. מבחינה בירוקרטית, ישנם הרבה אירגונים שלא קונים מוצרים שאינם בעלי תו תקן של MS (חברות ממשלתיות, חברות גדולות וכו'). ישנם מנועי התקנה, אשר מאפשרים לך לוודא האם פרוייקט התקנה מסויים עומד בתקן כזה או אחר. מי שמפתח את ה-SETUP משתמש בהנחיות של מנוע ההתקנה בכדי לשנות את נתוני ההתקנה כדי שיתאימו לדרישות. 8. כאשר תוכנה מותקנת בהרבה מאוד תחנות בבת אחת, רוב הארגונים מעוניינים במנגנון כלשהו של SILENT INSTALLATION. מנגנון זה צריך לעבוד לפי כללים מסויימים, כדי שיוכל להתממשק למערכות להפצת תוכנה כמו SMS של MS או SDO של COMPUTER ASSOCIATES. בד"כ זה אומר שיש איזה קובץ טקסט, המכיל תשובות לכל ה-DIALOGS של תהליך ההתקנה, או משהו דומה. כל מה שצריך לעשות, זה להפעיל פעם אחת את ההתקנה באופן רגיל ולבקש ממנוע ההתקנה "להקליט" את תגובות המשתמש לקובץ. אח"כ, את שאר ההתקנות מבצעים בעזרת הקובץ שנוצר. ולא לשכוח להחזיר שגיאות החוצה לאיזה קובץ נוסף, שיהיה נגיש למערכות להפצת תוכנה או למשתמש. 9. לפעמים, כאשר מפיצים עדכונים, רוצים שהם יהיו קטנים ככל האפשר. מנועי התקנה, או יותר נכון מוצרים-תומכי-מנוע, מחוללים "הפרשים" בין חבילות התקנה, ויודעים ליצור חבילות קטנות ככל האפשר, אפילו ברמת הבלוק (כמה קילו-בתים) ולא רק ברמת הקובץ. היכנס לאתר של INSTALLSHIELD בכדי לקבל רעיונות.... בהצלחה!

 

[gilad_no]

קודם כל, תודה על התגובה

לגבי MSI, בכוונה לא רציתי ללכת לכיוון MSI מכיוון שהוא דורש התקנה מוקדמת של MSI. משתמשים במערכות ישנות (98 וכו') - עדיין לא כולם התקינו את זה ורציתי משהו שיעבוד על כל פלטפורמת חלונות. לגבי תכונות יותר מתקדמות, זה בתכנון. זאת רק הגירסה הראשונה. בקרוב אני מתכוון לפתוח את קוד המקור של היישום כך שמי שרוצה יוכל לעזור ולהרחיב את המוצר. CROSS PLATFORM - לא התיימרתי לכוון לכך. אני מכוון רק לחלונות. ללינוקס יש את הכלים שלהם (RPM בRH וכו'). השלב הבא שאליו אני חותר הוא לבנות מסכים מותאמים אישית. לפעמים יישום רוצה מסכים מיוחדים להתקנה שלו וזה יהיה השלב הבא (כנראה של הפרוייקט). בכל אופן, תודה רבה על הביקורת הבונה.

 

[אינגולמו]

כמה דברים קטנים

זה נכון ש-MSI לא מותקן על הרבה מערכות, אבל גם MS חשבו על הבעיה, ומותר לך להפיץ MSI יחד עם כל התקנה. הוא רץ לפני ההתקנה, מעדכן/מתקין את עצמו ואז ממשיכה ההתקנה כרגיל. זה נוהל סטנדרטי וזה לא עולה לך גרוש. לגבי CROSS PLATFORM - סבבה. רק זכור שבאופן עקרוני, *לא* רוצים להשתמש במנועים שונים, אלא רק באחד, אפילו אם זה על פני כמה פלטפורמות. הרי גם ל-WINDOWS יש סביבות פיתוח סטנרטיות (INSTALLSHIELD, INSTALLWISE הכי נפוצות) ומנועים נפוצים (MSI). זה עדיין לא אומר שלא מחפשים פתרון כולל אחד ויחיד, כדי שאם אני, מנהל הרשת, רוצה להפיץ AGENT של ANTI VIRUS לכל הפלטפורמות, אני אעשה את זה ע"י מנוע אחד ויחיד. לגבי עניין המסכים: מנסיוני המר והארוך עם פיתוח התקנות מהמוזרות ביותר

אני יכול לומר לך שהדבר שהכי עיצבן אותי, *ולא* קיים במנועי התקנה נוכחיים, הוא התממשקות נוחה ל-DIALOGS שנכתבו ב-MFC. הרי MFC כ"כ נוח לכתיבת DIALOGS, אז למה לפתח סביבה אחרת ליצירתם? לדוגמה, כל ה-DIALOGS של ההתקנה צריכים לנהל כפתורי NEXT, BACK וכו'. למה שאיישם אותם כל פעם מחדש בחלונות MFC שלי? למה סביבת הפיתוח של ההתקנה לא יכולה לספק לי את "המסגרת", ולהציב בתוכה חומר שלי (DIALOG בתוך DIALOG), מבלי שאצטרך לנהל את כל הדברים הטריביאלים בכל חלון? אני פתרתי את הבעיה ע"י יצירת מסגרת כזו, שתומכת בכל מיני דברים נחמדים ושימושיים, ואף ע"י בניית DIALOG פנימי "כללי", המאפשר בעזרת כמה מחרוזות פשוטות לקבוע אילו פקדים יהיו בחלון (תמיכה בכל הפקדים הסטנדרטיים). עשה במידע הזה שימוש

 

[gilad_no]

אני רוצה ללכת על רעיון של SHEETS

הרי כל ההתקנה בנויה סביב PROPERTYSHEETS, כך שחלון המסגרת מנהל הכל (NEXT,BACK וכו') ואתה רק כותב את החלון הייעודי שיוכל בפנים. כנראה שהשלב הראשון יהיה אפשרות לPLUGIN שתוכל לכתוב ויישום ההתקנה יידע לייצא ממנו את הSHEET שלך ולהטמיע אותו בהתקנה. בשלבים הבאים, אני רוצה כלי פשוט לDIALOG EDITOR שיוכל לשמש גם אנשים שלאו דווקא מתכנתים בC++.

 

[אינגולמו]

סבבה

נזכרתי בעוד משהו מעניין כרגע... בעיה נפוצה בתעשיית ההיי-טק: משום מה (ולא ברור לי למה), אנשים אוהבים להפוך את תוכנת ההתקנה לתוכנת CONFIGURATION. אני רואה התקנות עם 20 חלונות, לקנפג 100 דברים, חלקם תלויים אחד בשני וכו'. אח"כ ההתקנה רצה, נכשלת מאיזושהי סיבה, והמשתמש חושב פעמיים לפני שהוא מריץ שוב את ה-SETUP, כדי לא להגדיר הכל מחדש. במילים אחרות, אל תצא מנקודת הנחה שהולכים להיות המון PROPERTY PAGES או CONFIGURATION TREE וכו'.... אם תעשה זאת, תיתן יד לציר הרשע, המסבך ומייגע את תהליכי ההתקנה

אבל ברצינות, שווה לך להשקיע את רוב הזמן בדברים שאמורים לקרות בזמן ההתקנה *עצמה*, כמו תמיכה ב-SERVICES ו-ODBC, וכו', ופחות ב-GUI. וזאת כי GUI הוא הרבה עבודה שחורה, וכמו שאמרתי, לא עוזר לאף אחד כשהוא לא מינימליסטי. ההתקנה האידאלית בעייני, היא אחת שיודעת רק: 1. האם רוצים לעשות התקנה STANDARD או CUSTOM 2. אילו רכיבים רוצים להתקין/להסיר מהמחשב/מהתקנה קיימת 3. לאיזו ספריה להתקין (סעיפים 2,3 - רק ב-CUSTOM SETUP) זהו. אחרי שההתקנה הסתיימה, ו-SETUP עשה מה שהוא יודע הכי טוב לעשות - להתקין, אז אפשר לשאול את המשתמש אם הוא רוצה להריץ תוכנת קונפיגורציה (באחריות מפתח האפליקציה כמובן), שתומכת/לא תומכת ב-SILENT CONFIG או ב-COMMAND LINE, וכו'. מבחינת המשתמש, זה הרבה יותר עדיף לדעתי, כי הגדרות זה משהו שעלול לגרום לתוכנה לא לעבוד טוב, אבל ההרגשה הכללית ש"התוכנה כבר פה וכל מה שאני צריך לעשות זה לקנפג אותה", היא הרבה יותר טובה מאשר "הגדרתי מלא הגדרות וההתקנה נכשלה, עכשיו אני לא יודע איזו הגדרה דפקה לי את ההתקנה, וממש לא בראש שלי עכשיו להתקין את התוכנה 20 פעם עד שזה יצליח". אני מדבר על סמך נסיון עבודה עם לקוחות שהתקינו את המוצר שלנו על מעל 1/2 מליון תחנות ברחבי העולם.

 

[אלדד28]

לדעתי תוכנת התקנה טובה

תיתן לך DEFAULT CONFIGURATION ואפשרות לעשות הגדרות כרצונך. אני חושב ש-GETRIGHT עושה את זה - שואלת אותך אם אתה רוצה להגדיר עכשיו או אח"כ. כשאתה משתמש "בודד" זה נוח לעשות את זה ככה.

 

[אינגולמו]

יש הבדל בין

תוכנת התקנה טובה לבין מנוע התקנה טוב. מה שאני מתכוון, זה שאחריות הקונפיגורציה תהיה מחוץ למנוע ההתקנה. ברור שכדאי שתהיה לך גישה להגדרות בזמן ההתקנה אבל זה לאו דווקא חייב להיתמך מאחורה ע"י המנוע. אני מקווה שעכשיו קצת יותר ברור למה התכוונתי... כיום, זה לא כ"כ המצב, שכן כל הגדרות ה-REGISTRY לדוגמה, הן באחריות מנוע ההתקנה. זה טוב ויפה למוצרים קטנטנים, שאין להם הרבה הגדרות, אבל האמינו לי מנסיון שזה נעשה מאוד מכוער כאשר המוצר מסתבך

ב-MSI יש 80(!) טבלאות שצריך למלא (חלקם הגדול ידנית) רק כדי לתמוך במנגנון ההתקנה, גם בלי לטפל בהגדרות ספציפיות של המוצר. מי שעבד עם MSI יודע איזה כאב ראש זה - אפילו עם סביבת הפיתוח המהוללת של INSTALLSHIELD. וזה נכון גם בזמן פיתוח של מוצרים עם התקנה פשוטה. זה, לדעתי, אחד החסרונות הגדולים של סביבת הפיתוח שלהם (ושל INSTALLWISE באותה המידה). הגעתי למצב שאני כ"כ שונא לפתוח את ה-IDE שלהם, שכבר כתבתי SCRIPTS כדי לבנות 90% מהפרוייקט דרך AUTOMATION INTERFACES, ורק ה-GUI עוד דורש ממני התעסקות עם ה-IDE. ולמה???? YOU GUESSED IT! כי אנחנו יוצרים חלונות *להגדרות* בזמן ההתקנה. כמו שאומרת לובה, קשה קשה

לסיכום, *אחריות* הקונפיגורציה אמורה להיות בידי CONFIG UTILITY, שאפשר לגשת אליו אחרי/בזמן ההתקנה ע"י המנוע, כמו שעושה GETRIGHT (ד"א גם אני תומך במודל של *תוכנת* ההתקנה של GETRIGHT ובמקרה גם במנוע ההתקנה שלה, ומשם למעשה שאבתי הרבה INSIGHT בזמנו).

 

[אלדד28]

מסכים לגמרי עם הפסקה הראשונה

אבל לגבי registry - אצלי בפרויקט למשל יש הרבה יותר מקונפיגורציה ב-registry. למשל, יש את כל עניין ה-license שמפוזר all over the place, ויש כל מיני דברים אחרים שהם לא הקונפיגורציה גרידא. לגבי הקונפיגורציה, אין ספק - אתה צודק. זה לא צריך להיות חלק ממנוע ההתקנה. מצד שני, בשביל זה על מנוע ההתקנה להכיר בעובדת היותו מסגרת ותו לא, כלומר - משהו שמאפשר למודולים אחרים לרוץ (למשל כדי לעשות קונפיגורציה למערכת)

 

[אינגולמו]

???

לא הבנתי למה אתה מתכוון.... מה שונה עניין ה-LICENSE מהשאר? תוכנת קונפיגורציה לא יכולה להציג לך מסך ניהול ל-LICENSE? חוצמזה, לא חייבת להיות רק תוכנת קונפיגורציה אחת.... יכול להיות שיהיה לך כלי סטנדרטי שינהל LICENSING כמו FLEXLM וכו', ואפשר לבדוק (תלוי במבנה הקוד - אני לא יודע איך זה אצלכם), איך עושים אינטגרציה בין ה-API של פלטפורמת ה-LICENSING לבין תוכנת ה-CONFIG. כנ"ל לגבי תשתיות CERTIFICATION כמו PKI וכו'. THEN AGAIN, יכול להיות שלא הבנתי למה התכוונת

 

[אלדד28]

ברור שזה תלוי באפליקציה.

השאלה היא איפה אתה עוצר - תוכנת ההתקנה צריכה לעשות משהו

בוא נדייק. תוכנת ההתקנה צריכה להתקין את המוצר. יש הגדרה מדויקת (צריכה להיות הגדרה מדויקת) של "מה כולל מוצר". זה יכול להיות, למשל, בניית ספריות ייעודיות, העתקת קבצים מסוימים, רישום כל מיני דברים במערכת ההפעלה (שזה בעצם פניה ל-REGISTRY, אם מדובר ב-WINDOWS), וכן הלאה. עכשיו, את ההגדרה הזו אפשר לצמצם יותר, או להרחיב יותר, איש איש וטעמו. למשל, יכול להיות שכתבתי אפליקציה שחלק אינטגרלי בהתקנתה יהיה העתקת קבצים על בסיס קונפיגורציה. זה נכון במיוחד בהתקנות דרך הרשת - למשל, אם אתה מוריד את QUICKTIME אתה מתבקש לומר מה אתה רוצה (איזה FEATURE-ים), ובהתאם תוכנת ההתקנה מורידה את הקבצים המתאימים מהרשת, ומתקינה לך אותם. במצב כזה אפשר לעשות משהו מאוד בסיסי, ולומר למשתמש "טוב, עכשיו אתה יכול להוסיף עוד FEATURE-ים דרך מסך כך וכך, אם יש לך קשר לאינטרנט". אפשר מצד שני (וזה צד שני טוב, לדעתי) לשאול את המשתמש, עוד לפני שההתקנה וההורדה התחילו בכלל, מה הוא רוצה - ושיסמן. אני חושב שיש שתי קיצונויות פה - האחת היא לא לעשות כמעט כלום חוץ מלהעתיק קבצים (וזה בערך מה ש-WINZIP עושה), והשניה היא להכניס הכל הכל הכל לתוך מנוע ההתקנה (כמו ש-MSI מנסה). האידיאלי היה, לדעתי, האופציה השניה, אם היא הייתה באמת מושלמת, ידידותית, וגמישה ברמה כזו שנותנת לך לוותר על קומפוננטות שלמות בלי להינזק, ומצד שני להוסיף את הקומפוננטות שלך בצורה חלקה וקלה. זה מנוע ההתקנה האולטימטיבי. אגב, רטנת למה אי אפשר להוסיף DIALOG-ים של MFC, או לפחות לייצר אותם בתוך IS כמו שאתה עושה אותם בקלות ב-MFC. יהיו הרבה אנשים שיקחו את השאלה שלך קדימה וישאלו למה אי אפשר לעשות אותם בקלות הרבה יותר גדולה כמו בדלפי או ב-VB (ובצדק!). גם כאן אני חושב שיש הרבה מקום לשיפור ב-IS, מבחינת הידידותיות ומבחינת הגמישות, ששתיהן לא מדהימות ב-IS.

 

[אינגולמו]

ואללהההה

לא הבנתי איך *כל* מה שכתבת קשור איכשהו למה שאני כתבתי...

אני טענתי שמנוע אמור לעשות כל מה שצריך כדי שיהיה אפשר אח"כ: להסיר את האפליקציה או חלקים ממנה להוסיף חלקים לאפליקציה לקנפג את האפליקציה בעזרת UTILITY להשתמש באפליקציה (אחרי הקינפוג) בצורה קוהרנטית (כלומר לא להגיע למצב שמותקן חצי FEATURE או משהו כזה) לקבל מידע כללי על האפליקציה ממערכת ההפעלה (תלוי במערכת ההפעלה כמובן) לבצע UPGRADES תוכנת ה-CONFIG עלולה להיות חלק חשוב *בתהליך* ההתקנה, אך לא חלק *ממנוע* ההתקנה. מומלץ שהיא תהיה נגישה לשינויים עוד בשלב פיתוח ההתקנה. מצטער, אבל לא הבנתי את הקשר של דוגמת ה-QUICKTIME. למה פירטת את מה שפירטת? להוסיף ולהוריד קומפוננטות בצורה קוהרנטית היא אכן אחת מהתכונות החשובות שבאחריות מנוע ההתקנה. ו... ? לגבי ה-DIALOGS: באופן כללי, IS לא נותן תמיכה טובה ל-DIALOGS שנכתבו מבחוץ. זו היתה כוונתי - לאו דווקא ל-DIALOGS של MFC. אם אפשר לארגן DIALOG של VB בתוך DLL או משהו כזה, אז הגענו לאותה בעיה פחות או יותר. ושאלה: באיזו סביבה של IS עבדת, ואיזה סוג של התקנה יצא לך לפתח?

 

[אלדד28]

עניין ה-QUICKTIME קשור,

כי זו הייתה דוגמה ל"למה הקונפיגורציה חשובה בהתקנה" - או אפילו לפניה. אני עובד עם IS6, ולגבי סוג (מתחזק, לא פיתחתי אותה תודה לאל, רק עושה תיקונים קלים) - אפליקציה רגילה, אנא עארף, איזה סוגים יש? איפה התשובות האפשריות פה?

 

[אינגולמו]

ציינתי

בפירוט של המנוע/תוכנת ה-CONFIG את עניין הגישה ל-CONFIG במהלך ההתקנה. זה אפשרי, זה סבבה, אבל עדיין באחריות תוכנת ה-CONFIG לספק את המידע הדרוש. כאמור כל מה שצריך מהמנוע היא יכולת קריאה ל-API. זו, לדעתי הגישה הנכונה ביותר, מכיוון שהבדיקה אילו רכיבים כבר מותקנים היא FEATURE שדרוש גם אחרי ההתקנה, ולכן לא הייתי רוצה ליישם אותו כחלק מהמנוע. ד"א, סביבת הפיתוח עבור MSI היא עדיין של INSTALLSHIELD (לפחות זו שאני עובד איתה. יש עוד 2 פופולריות של INSTALLWISE ושל MS). כשכתבתי על עניין ה-DIALOGS, התכוונתי ל-DIALOGS במודל של MSI ולא במודל המוצע תחת IS6 Professional, שזוהי הגירסה שאיתה אתה עובד מן הסתם. ב-MSI הבעיה יותר גרועה (וגם רלוונטית יותר, כי MSI הוא סטנדרט DE FACTO). התממשקות ל-MFC DIALOGS תחת IS6 היא עוד סבירה וקלילה לעומת MSI

 

[אלדד28]

אז עכשיו אני עוד פחות מקנא בך ../images/Emo5.gif

 

[stac]

תומך בהצעה.

 

[stac]

למה שמישהו ירצה לעשות תוכנית התקנה.

אם הוא לא מתכנת?

 

[gilad_no]

לא תמיד זה למוצר שלו

לפעמים יש לחברה מוצר ולא המתכנת בונה לו את ההתקנה. או מתכנת VB שרוצה התקנה לתוכנה שלו ולא יודע C++.

 

[אינגולמו]

תרשה לי להפנות אותך לתשובה

לינק

 

[אלדד28]

חחחחחחחחחח ../images/Emo6.gif