.NET Framework גם לסקריפטינג

מאמר מצויין שפורסם ב TechNet Magazine בנושא שילוב .NET Framework בקוד Scripting. מומלץ לכולם:

http://www.microsoft.com/technet/technetmag/issues/2007/01/HeyScriptingGuy/default.aspx

הסברים על תוכנית ההתקנה של ויסטה

ההתקנה של Vista שונה מהתקנות של גרסאות קודמות של Windows, בגלל שבעוד ההתקנות של גרסאות קודמות היו file-based installation, ההתקנה של ויסטה היא image-based installation מה שאומר, בשפה פשוטה, שלא כמו  בגרסאות קודמות, תוכנית ההתקנה לא מעתיקה קובץ קובץ להארד-דיסק, ואז מריצה פקודות ש"יתקינו" אותו, אלא, דיסק ההתקנה מכיל קובץ Image גדול שמכיל למעשה הדמייה של מבנה התיקיות והקבצים של מערכת Windows Vista מותקנת לחלוטין, שהוכנסה לקובץ wim, בדומה לקבצי iso.

חוץ מהקובץ wim הזה מכיל דיסק ההתקנה מספר מאד קטן של קבצים אחרים שמיועדים לסייע לפריסה התחלתית של קובץ ה wim שמשמש גם את ההתקנה. בתהליך ההתקנה, מה שמתבצע בפועל זה פריסה של קובץ ה wim לכונן הקשיח לאיזשהו Partition זמני שנוצר במערכת ההפעלה (ומסומן בדרך כלל באות X). לשם, נפרס הקובץ wim, מבנה התיקיות והקבצים עד שהכל נמצא שם. ההליך הזה לוקח בד"כ 50% מתוכנית ההתקנה. ה50% הנוספים מיועדים להכנת המערכת - כלומר, לקחת את הנתונים מה Partition הזמני, ולהעביר לכונן שבו באמת אמורה להיות מערכת ההפעלה. אם מדובר בהתקנה נקייה, תתבצע רק העברת הקבצים (במידה ויש מערכת הפעלה קודמת, שמירת תיקיית ה windows הקודמת בשם windows.old) ובסוף, החלת הגדרות ראשוניות על המערכת (האם יופעל ממשק Aero? מה רמת הביצועים והפעלת תכונות בסיסיות).

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

למעשה, תוכנית ההתקנה של Vista בתצורת image-based installation לוקחת בין 35-50 דקות (תלוי בחוזק המחשב). תוכנית התקנה של Vista שרצה בתצורת file-based installation הישנה, שבה הותקנה XP תעבוד במשך 2-3.5 שעות עד להשלמת ההתקנה. זה בגלל שבהליך התקנת תמונה, רק בתחילת ההתקנה צריך להשתמש בDVD לשם פריסת קובץ ה image. לאחר מכן, התהליך מתבצע על ה Hard-Disk עצמו. ויותר מכך, היות שכל המבנה של המערכת מגיע בקובץ התמונה, לאחר הפריסה מתבצע רק הליך התאמה קצר של המערכת למחשב ואז המערכת מוכנה לעבודה. מדובר במהירות שיא של התקנה, שזהה כמעט לחלוטין למהירות של פריסת קובץ תמונה מכל סוג אחר (כמו Ghost) רק שפה, חוץ מהפריסה עצמה מתבצע הליך התאמה כלשהו למערכת שמכשיר אותה לעבודה.

לאור הדברים הללו, יש כמה טיפים שכדאי לכל מי שמתקין לשים לב אליהם:

1. במידה ואתם צורבים בעצמכם את קובץ ההתקנה (כמובן קובץ שהורדתם מMSDN או Technet או שיצרתם בעצמם עם רישיון ולא, רחמנא ליצלן, קובץ שהורדתם מתוכנות ששמם דומה לחיות עבודה) שימו לב לעשות צריבה איטית. כשמדובר על תוכנית התקנה פר-קובץ, במידה וקובץ אחד קצת נפגם, ויש סקטור פגום, הרבה פעמים ההתקנה תימשך בלי ששמתם לב לזה, או שפשוט תוכלו להכניס דיסקט עם הקובץ הנכון. כשמדובר בתקנה עם Image, אי אפשר להכניס אח"כ קובץ תקין, ואם יש בעייה בסקטור, למשל זה שמגדיר את מבנה התיקיות, תוכנית ההתקנה כולה תיכשל. אז אל תצרבו במבירות הצריבה המאקסימלית של הצורב. לכו לאט יותר.
   
2. במידה ואתם עומדים להתקין את Vista הרבה פעמים, שקלו להכין התקנה מותאמת אישית. זה קל וזה פשוט. צרו פרוייקט Deployment משלכם לויסטה, שיאפשר לכם להתקין את ויסטה ישר עם הגדרות מותאמות אישית, להתקין בלי צורך לעשות כלום במהלך ההתקנה (פעם אחת להכניס מראש את כל ההגדרות שיש לקובץ שנצרב לתוכנית ההתקנה), תוכנית התקנה שתפיץ אוטומטית את התמונות המשפחתיות לכולם.
   נכון, זה מיועד במקור לאנשי הIT. אבל, אם אתם עומדים להתקין הרבה פעמים ויסטה לצרכים אישיים, אתם יכולים לנצל את זה ולחסוך לכם זמן קינפוג בהמשך. אתם אפילו יכולים לשלב תוכנות שלמות, שבעת התקנת ויסטה יותקנו גם הן מיד (למשל, אופיס או סתם אנטי וירוס ופירוול).
   
3. התקנת מערכת הפעלה היא הזדמנות מצויינת להתחיל מחדש עבודה נכונה. סדרו לכם את ה Hard Disk בצורה כזאת שיהיה Partition אחד למערכת ההפעלה ותוכנות ו Partition אחד או יותר ל Data. מה שמבטיח שפעם הבאה שתצטרכו להתקין הכל מחדש, לא יהיו בלבכם דאגות לגבות ולהעביר מידע.

בהצלחה.

שדרגו לויסטה, המחשב שלכם יעמוד בזה

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

גם אם יש לכם מחשב חלש יותר, ויש לכם רק ג'יגה זיכרון (אפילו 512 מגה עובר) וכרטיס מסך תומךDirectX 8 בלבד - גם אז תעברו. אמנם לא יהיו לכם האפקטים הגרפיים, אבל יהיו לכם כל השיפורים האחרים. החל מגאדג'טים, שיפורי אבטחה וכלה בהוספת תכונות ויכולות למערכת (וגם אז, המערכת תהיה יותר יפה). מי שפחות חשובות לו היכולות, ורוצה להנות רק מהשיפורים בגרעין, מתוספת תכונות ויכולות האבטחה והיציבות החדשות, יכול לחסוך כסף ולהסתפק ב Home Basic שדורשת הרבה פחות, וגם מגיעה מרש בלי Aero Glass. מה שאומר, שהוא לא "שילם עבור משהו שהוא לא יכול להשתמש בו", אלא הוא שילם עבור כל החידושים בחבילה שבה ה Aero Glass כלל לא כלול.

ההמלצה שלי, לכולם, זה לשדרג לויסטה. אפילו אם אין לכם מאיץ גרפי משוכלל ויש לכם 512 מגה זיכרון בלבד. השדרוג הזה רק יתרום ויעזור לכם.

יום טוב.

עדכונים מהבלוג ישירות ל Visual Studio שלכם

אני מניח שכולנו מכירים את מסך הפתיחה של Visual Studio:

במרכז המסך, יש עדכונים, שמגיעים בRSS כברירת מחדל מMSDN. אבל ברור שMSDN זה כלום ביחס לבלוג שלי (ציניות...), ושאתם תרצו לקבל עדכונים מעניינים מהבלג שלי ולא את המאמרים הללו מהMSDN שמדווחים לכם בעיקר על אירועים ומוצרים חדשים ודברים חדשים להורדה (מדי פעם גם משהו מעניין).

הפעולה פשוטה מאד, לכו לתפריט Tools->Options:

ברירת המחדל נראית כך (לכו ל Stratup):

כל מה שצריכים לעשות, זה למחוק את הכתובת המסומנת (כתובת פיד RSS) ולהחליף בRSS המבוקש שאתם רוצים. זה של הבלוג שלי, הוא http://blogs.microsoft.co.il/blogs/shahar/rss.aspx. אתם יכולים להשתמש גם בRSS של איזשהו אגרטור, או של דף הבלוגים הראשי. תזכרו, שאתם מנווטים במאמרים דרך חלונית בVS, מה שהופך את זה להרבה יותר נוח תוך כדי כתיבת קוד.

תהנו.

נ.ב. גם אם לא בא לכם לקבל עדכונים מבלוגים, או מ Code Project, אתם יכולים לשנות לפיד אחר של עדכונים מMSDN.

עבודה עם הרשאות בויסטה (גם דרך קוד)

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

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

נעים להכיר - System.Security.Principal
ה Namespace הזה (שבדוגמאות שאני מראה, כבר עשיתי לו using), לא זכה להרבה פרסום בתקופת הXP כי XP "בלע" הכל ולא הקפיד על הרשאות. ה Namespace הזה מיועד לעבודה ספיציפית עם רמת ההרשאות הנוכחית שיש למשתמש.

אחת המחלקות איתה נתעסק, היא WindowsPrincipal שמכילה מידע ספיציפי עבור המשתמש שבמסגרת בקשתו בוצעה פעולת new ל Class הזה.
ה Constructor (היחיד) של המחלקה הזאת דורש לקבל WindowsIdentity. כלומר, איזושהי זהות הרשאות של המשתמש. כדי לקבל את זהות ההרשאות הנוכחי של המשתמש, נשתמש בפונקציה הסטאטית GetCurrent במחלקה WindowsIdentity שתחזיר לנו בעצמה אובייקט WindowsIdentity שמכיל את הזהות המלאה של המשתמש. אנחנו יכולים להעביר גם WindowsIdentity.GetAnonymous שמייצג משתמש אנונימי.

אחרי שיצרנו אובייקט של WindowsIdentify אנחנו יכולים להשתמש במתודה IsInRole שמקבלת את ה Role מתוך enum בשם WindowsVuiltInRole שמכיל את רשימת כל רמות ההרשאה שמגיעות By Default עם Windows, או לחלופין עם שם ההרשאה כ string ומחזיר true במידה והמשתמש אכן שייך לרמת ההרשאות הזאת. הנה קוד שמציג לנו האם המשתמש Administrator.

עכשיו נקבל את המידע האם המשתמש הוא Administrator או לא. מה שנקבל, במידה והUAC פעיל זה False. מכיוון, שאפילו אם המשתמש הוא באמת יכול להגיע לרמת Administrator, בפועל, בינתיים הוא ברמת משתמש רגיל עד שהוא יעשה פעולה שתדרוש באמת הרשאות Administrator ואז הוא יופיע ככזה, או לחלופין עד שיעשה לאפליקציה Run As Administrator. כלומר, ל Administrator בויסטה יש רק פוטנציאל לקבל את ההרשאות הללו. עד שהוא לא יעשה פעולה שמחייבת את ההרשאות, או יכפה על תוכנה לרוץ עם רמת Administrator, הרי הוא כמשתמש רגיל. המיוצג, דרך אגב, בתור WindowsBuiltInRole.User.

עכשיו, אנחנו יכולים לתחום פעולות מסויימות למשתמש שהוא מ Role מסויים, בין אם מובנה ובין אם Role שנמצא רק לוקאלית על המחשב הזה, ואז נעביר ב string את שם ה Role.

אנחנו יכולים להציג את הקוד הזה גם בצורה שונה, ומקוצרת, אבל זה רק עניין של סמנטיקה:

בין השאר, יכול להיות שנרצה לקבל את הפרטים הרגילים - שם המשתמש (במחשב שבו אני מריץ, Abby. עדיף שלא תשאלו למה), האם הוא מזוהה וכיצד הוא זוהה. הנה קוד קצר שימחיש את זה:

רוצה להיות מנהל
נניח שיש לכם אפליקציה שמאיזושהי סיבה דורשת הרשאות Administrator בשביל שהיא תוכל לרוץ (ומעטים המקרים הללו. אם זה המצב אצלכם, בדקו האם זה באמת צורך - או רק תוצאה של תכנון גרוע). והיא צריכה אותם כאן ועכשיו, כלומר לא משתמש Administrator שיש לו את הפוטנציאל בלבד, אלא שברגע שהאפליקציה תרוץ, היא תרוץ כאילו המשתמש בחר Run As Administrator. במקרה הזה, תיצרו manifest הרצה.
ה manifest הוא קובץ XML שקובע את רמת הדרישות ההתחלתית להרצת אפליקציה. במקרה שלנו, Administrator. במקרה הזה, נוסיף קובץ xml שקובע שרמת ההרשאות המינימלית להרצת האפליקציה זה מנהל מערכת, ולכן למשתמש תקפוץ הודעת UAC שתבקש ממנו לתת את ההרשאות שלו. במידה וזה לא משתמש עם פוטנציאל למנהל מערכת, האפליקציה לא תפעל. קחו זאת בחשבון. לאפליקציה שעשיתי קוראים uac . התוצר, יהיה uac.exe ולכן בחרתי ששם המניפסט יהיה uac.exe.manifest. בקובץ הזה אני אשים את הקוד הנ"ל שאומר בפשטות - "כניסה ל Administrators בלבד, רק לאחר הפעלת מלוא ההרשאות":

מה שאנחנו קובעים פה זה את שם התוכנית, אומרים שאין לה תלויות שנות ודורשים הרשאות administrator. בשלב הזה, נוסיף למאפייני הפרוייקט את הטקסט שקושר את ה manifest הזה לאפליקציה. שימו לב, השתמשתי במשתנה בשם TargetName שמייצג את שם האפליקציה. ניתן, אם רוצים, להשתמש בשם מפורש. זאת המחרוזת:

"$(DevEnvDir)..\..\SDK\v2.0\bin\mt.exe" -manifest "$(ProjectDir)$(TargetName).exe.manifest"  –outputresource:"$(TargetDir)$(TargetFileName)";#1

ופירושה: "הגדר manifest לאפליקציה, ששוכן בתיקייה של האפליקציה, ויש לו את אותו שם כמו האפליקציה, רק שלאחריו יש .exe.manifest .

נדביק את המחרוזת ב Post Build Event Command:

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

ובעת הריצה נקבל את ההודעה של הUAC על תוכנית שרצה כאדמיניסטרטור, והפעם, נראה שהזהות שיש ב WindowsPrincipal היא לא של משתמש רגיל, אלא של Administrator:

לנוחותכם, ניתן להוריד את הפרוייקט מכאן.

בהצלחה.

זכרו: מקרה שבו חייבים להתנות את ריצת התוכנית בנתינת הרשאות מנהל נדיר. ממילא, במידה והאפליקציה הייתה מנסה לבצע פעולה הדורשת הרשאות ניהול, המשתמש היה מקבל הודעה ששואלת אותו מה לעשות. פה, אנחנו נותנים הרשאות ניהול לכל זמן ריצת האפליקציה עם הרצתה.

ויסטה לא שורפת את המועדון

אחת השאלות הבוערות בהתאמת אפליקציה לויסטה, נוגעת דווקא לאפליקציות שנכתבו בצורה בעייתית, אפליקציות שעוברות על מדיניות האבטחה הנהוגה בויסטה, כשהפעולה הכי נפוצה - כותבות לתיקיות שאין להן הרשאות עבורים, בייחוד לתיקיית ה Program Files, כשמדובר פה על אפליקציה שהותקנה ונרשמה במחשב.

מי שכתב אפליקציות כאלה מודאג שמה האפליקציה לא תעבוד בויסטה בכלל. ויסטה לא תבצע ת הפעולה, תגרום לרצף שגיאות runtime ותחסל את האפליקציה. הבשורות הטובות, זה שגם עם האפליקציה שלכם עוברת על חוקי האבטחה, ויסטה לא שורפת את המועדון. תכירו - Virtualized Program Files.

כשתוכנה מנסה לכתוב ל Program Files, מערכת ההפעלה מזהה את זה. כדי לא לגרום נזק, היא פשוט כותבת את הקובץ הזה לתיקייה בשם Virtualized Program Files, וגורמת לאפליקציה להאמין שהקובץ באמת נכתב ל Program Files. כשיתבצע ניסיון לקרוא את הקובץ הזה, הקובץ ייקרא מ"תיקיית האשליות" הזאת.

לצורך העניין, אני אדגים עם תוכנת ההדגמות של ויסטה, Contoso Order. התוכנה הזאת רושמת הזמנה לתוך תיקיית ה Program Files:

כשאני שומר את הנתונים, מתבצעת כתיבה ל Program Files, או לפחות, ככה התוכנה חושבת:

בפועל, מערכת ההפעלה איתרה שמתבצעת פה כתיבה ל Program Files, והפעילה את מנגנון האשליות כדי לגרום לתוכנה להאמין שהקובץ נכתב ל Program Files, כשבמקור הוא נכתב לתיקייה אחרת, שבמידה והיה מדובר בתוכנה זדונית לא היה נגרם נזק. התיקייה הזאת נמצאת בנתיב:
%userprofile%\AppData\Local\VirtualStore\Program Files
וקיימת לכל משתמש בנפרד. הנתונים נשמרו לתיקייה הזאת:

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

עדכון: בעקבות שאלה של אורי בתגובות, חשוב לציין שרק אפליקציות שהותקנו במחשב לאחר שעברו אישור של המשתמש, משמע, הותקנו, ורשמו את עצמן כאפליקציות (תהליך שדורש את אישור המשתמש) רק להן, במידה והן ינסו לכתוב לתיקית ה Program Files בעת ריצת האפליקציה, הקובץ ייכתב לתיקייה המיוחדת הזאת.
זה מיועד לקבצי נתונים ולאלקבצי ריצה שייכתבו. כלומר, אפליקציה שרשמה קובץ טקסט ל PRogram Files, הוא ייכתב לשם.

אפליקציה שכתובה נכון, היא אפליקציה שלא כותבת ל Program Files אלא שומרת את קבצי הנתונים שלה ב Isolated Storage. עבור מתכנתים שלא מכירים, מדובר באפשרות לכתוב Streams בצורה מיוחדת, שייכתבו לתיקייה שקיימת בכל מחשב ושמה App Data שהמטרה שלה זה להכיל קבצים שהאפליקציות רוצות לשמור.  ה Classes המדוברים הם:

• IsolatedStorageFile
• IsolatedStorageFileStream
• IsolatedStorageFilePremission

שבוע טוב.

טיפ: לכו בגדול

אני מניח שכולם מכירים את ההדגמה הנדושה ב Windows Vista שנכנסים לתיקייה, לוחצים על קונטרול ומסובבים את הגלגלת והאייקונים גדלים וקטנים. לידיעתכם, זה אפשרי גם בדסקטופ, ולדעתי, אייקונים גדולים הופך את זה להרבה יותר יפה. שימו לב לאיך נראה הדסקטופ שלי עכשיו:

(תסתכלו על הגודל המלא של התמונה והאייקונים)

פיצ'ר חדש ונחמד בויסטה

בעודי יושב אתמול אצל יוסי תאגורי ומשתמש במחשב שלו, השתמשתי שם בעכבר ש"לגלגל" לא היה הצד החזק של הגלגלת שלו.

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

חג שמח.

Language Fallback

ב Windows Vista, שמו הרבה דגש על ענייני ריבוי השפות. כלומר, סוף סוף תמיכה מוחלטת בשפות. אין כבר את ערכות הMUI בתשלום, אלא הכל באותה מערכת. ובהחלט אם נכנסים לכל מיני תיקיות מערכת ב Program Files, נוכל תמיד לראות את הדבר הזה:

זאת התיקייה של Windows Mail, תוכל האימייל של Windows Vista. יש לנו תיקייה בשם en-US, שמכילה קבצי MUI:

הקבצים הללו, הם קבצי ריבוי השפות. כלומר, אם נפתח תיקייה בשם he-IL ונשנה את קבצי השפה האלה, למעשה ניצור culture חדש וניצור עבורו תיקיית ממשק משתמש.
גם בגאדג'טים בויסטה, יש תמיכה בריבוי שפות. אם בגאדג'ט אני אשים תיקייה ואתן לה שם של איזושהי culture, במידה והמשתמש עובד עם הגדרות התרבות הללו, קבצי הGUI יישלפו מהתיקייה הזאת:

אם המשתמש בתרבות קל en-US, ישמשו אותו הקבצים שבתיקייה en-US, ואם הוא he-IL קבצים משם תואם של תיקייה ישמשו אותו.

ממשק המשתמש יכול להיות בקלות רבה מאד מרובה שפות.

השאלה שנשאלת, היא מה קורה אם המשתמש הוא מהתרבות en-UK. במקרה הזה, אין לו תיקייה חופפת במערך התיקיות של הגאדג'ט. איזה GUI הוא יראה במקרה הזה?
התשובה, נעוצה ביכולת ששולבה בויסטה בשם Lnaguage Fallback, שאומרת דבר כזה- "תרבות מסויימת רצוייה לנו, אבל קבצי לוקאליזציה עבורה. בואו נמצא את הדבר שהכי קרוב". אם התרבות היא en-UK, נועבר אוטומטית לתיקייה en-US, כי זה הכי קרוב. אם היינו עושים תיקייה בשם en, כלומר, שם כללי לכל אלה ששפתם אנגלית, המעבר היה לשם.

מה שאומר, שהזרימה היא מהממוקד לכללי. אם התרבות קיימת, היא זאת שתשמש אותנו. אולם, אם אין ממשק מותאם ל culture אליו מוגדר המחשב, נועבר ליותר ויותר כללי, עד, שבמידה ואין התאמות בכלל, בתחום הגאדג'טים, נעבור לממשק שנמצא ב root של הגאדג'ט. זאת המהות של Language Fallback - לנסות למצוא התאמה כמה שיותר ממוקדת, ובמידה ואין, ללכת לכיוון הכללי יותר שלב אחר שלב.

ההתאמות הקטנות שבויסטה לOS X

סרטון נחמד של ה New York Times. נכון, שהם התייחסו לעניין בצורה די לא מעמיקה (או: רדודה), אבל עדיין, סרטון משעשע ביותר. תשקיעו 3 דקות ועשרים שניות מזמנכם.

ההרצאה שלי בכנס המפתחים השנתי

בכנס המפתחים השנתי הקרוב של מיקרוסופט ישראל שיתקיים ב31 בינואר 2007, ארצה על Windows Gadgets עליהם כבר כתבתי (ורצוי לקרוא) מספר פעמים.

ההרצאה בכנס הקרב תתמקד בפיתוח Windows Gadgets (אחת האפשרויות החדשות והחשובות ב Windows Vista) בצורה מעשית. כלומר, תהיה התמקדות רבה על הצד המעשי, ולא על הצד השיווקי ("למה זה טוב"). זה יתבטא בכך שבמהלך ההרצאה, נבנה גאדג'ט שידגים את כל הנושאים העיקריים בפיתוח גאדג'ט, ידגים לכם בעיות וסוגיות נפוצות ויאפשר לכם להכיר בצורה יותר טובה את הפלטפורמה, כיצד היא עובדת ולהבין גם את היתרונות והחסרונות. הגאדג'ט ידגים את כל השלבים מהבסיס (יצירת גאדג'ט, שמירת הגדרות, תכונות ודרך הפעילות של הגאדג'טים וה Sidebar) ועד נושאים מתקדמים כמו שילוב עם אפליקציות קיימות עם רכיבי COM ו WebServices, שילוב עם WPF , הכרת Windows Gadgets Object Model, סוגיות, בעיות ופתרונות בפיתוח גאדג'טים. בנוסף, תראו קוד ותראו את דרך כתיבת הקוד. בין השאר אני אסביר איך לגשת לכתיבת גאדג'טים וגם אתן כמה טיפים מועילים. וזה, כמובן, רק ההתחלה...

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

אתם מוזמנים לשריין את התאריך 31 בינואר 2007 ביומנים.

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

שחר.

לינקים בגאדג'טים

גאדג'טים כפי שכבר הסברתי בעבר, הם קבצי HTML וJS שמהווים מיני-אפליקציות. הדגשתי, שהסיידבאר לא מנווט לגאדג'טים, אלא מתקין אותם. אחת ההשלכות, זה שכל פעם שמשנים צריך להסיר ולהוסיף את הגאדג'ט (את המופעים שלו) כדי שהדבר יופיע. אחת השאלות המתבקשות - מה יעלה בגורלן של תגיות a href המוכרות, המשמשות לקישורים.

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

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

זה עובד גם מתוך הגאדג'ט, גם מתוך ה Flyout (חלון נפתח של הגאדג'ט המיועד לפרטים נוספים) ואפילו מתוך מסך ההגדרות. הבעייה היא שבמסך ההגדרות צריך לשים לב שכשאתה עובר לדף אחר, הנתונים מהדף הקודם יישמרו (עניין של scope, תחום הגדרה. אני ממליץ שכדי להימנע מבעיות רצוי למעט בשימוש באפשרות הזאת). בקיצור, קישורים רלוונטיים גם בגאדג'טים והם דרך מצויינת למנוע עומס ויזואלי על הגאדג'ט ולהפריד לכמה חלקים. רק הקפידו לשים לב לכך שעומס קישורים עלול לפגוע בשימושיות של הגאדג'טים, ולכן, רצוי למעט בקישורים, ולהפריד למסך נפרד רק נתונים לא מאד חשובים שאתה רוצה לשמור למשתמש את האפשרות לגשת אליהם מתוך הגאדג'ט.

בהצלחה.

רגע לפני השחרור הסופי...

רגע לפני השחרור הסופי של RTM לחנויות, החלטתי לחזור אחורה. לימים שבהם לא דיברנו עוד בבטות, ובטח שלא בRC. לימים שבהם Vista עוד לא היה Vista - אלא Longhorn. לימים שבהם WinFS עוד היה רלוונטי, AERO עוד לא היה קיים ותוכנית ההתקנה שקלה רק 700 מגה ויציבות לא היה הצד החזק שלה. אז התקנתי את Longhorn,  build 4051 על Virtual Machine. חזרתי כדי לספר.

רציתי, באמת רציתי לכתוב את הפוסט הזה ולהעלות אותו. הסתבר רק דבר אחד שבמרוצת הזמן שכחתי. ההתקנות הללו נוטות להיכשל. החומרה לא מזוהה. זה מה שגורם לרוזולוציה של 600*480, וצבעים של 4 ביט בלבד. מה שכן שמתי אליו לב, זה שאז Sidebar לא היה מקום לגאדג'טים, אלא למעשה אמור היה להחליף את ה System  Tray שליד השעון. כיום, כבר אפשר לבנות ולהריץ מזה גאדג'טים, ויש גם את זה וגם את Sys Tray. במקור, זה רק היה אמור להחליף אותו. מסוג פרטי הטריוויה הלאמעניינים בכלל שמגלים כשמתקינים דברים חדשים. אז הנה בכל זאת מספר תמונות שלקחתי מאתרים אחרים, רק כדי שהרעיון יועבר:

עוד לא היה IE7

בלי קשר, אני חייב להגיד - רק מחווית ההתקנה וההפעלה הראשונה, יש שיפור רציני מאד לעומת הRTM (לא חוכמה, אבל בכל זאת) ;-)

התקדמו מיקרוסופט מאז. מאד התקדמו.

מה ההגבלות (אבטחה) של הגאדג'טים בויסטה?

כחלק ממדיניות הUAC שהונהגה ב Windows Vista ובסיסה בכך ש Administrator הוא לא באמת Administrator וכשהוא רוצה לבצע פעולות אדמיניסטרטיביות קריטיות הוא נדרש לאשר שזה מה שהוא רוצה לעשות. לדבר יש שני היבטים:

1. להתמודד בבורות של משתמשים מתחילים שעובדים כ Administrators ועלולים לעשות שטויות.
2. להתמודד עם וירוסים ושאר איומי אבטחה שמנצלים את סמכויות המנהל של המשתמש לביצוע פעולות על המכונה, ללא ידיעתו. במקרה הזה, ההודעות שיקפצו יידעו את המשתמש, ובמידה ולא הוא זה שביצע את הפעולה והוא לא יודע על מה מדובר, הוא יכול פשוט לבטל את הפעולה הבעייתית ולפגוע ביכולת התפקוד של איום האבטחה.

כל חידושי האבטחה הללו (ונוספים) לא פסחו גם על הגאדג'טים בויסטה. אני אביא פה בנקודות קצרות את עניין האבטחה בגאדג'טים.

שימוש בHTML
שימוש בHTML מונע למעשה מהמפתחים אפשרות להשתמש בקוד זדוני, היות וזאת שפה שלא יכולה ליצור איומי אבטחה. גם הJS, מוגבל בריצתו כך שהוא לא יכול להשפיע. כדי להרחיב את פעילות הגאדג'טים, ניתן להשתמש ברכיבי COM (ActiveX) אולם הדבר מותנה בכך שהרכיבים הללו כבר מותקנים במחשב - הגאדג'ט לא יכול להתקין אותם. בכל מקרה, הקוד מתרנדר במנוע MSHTML.

הורדת הגאדג'ט
ניתן לארוז גאדג'ט כקבצי ZIP וCAB עם סיומת gadget, מה שיאפשר להם להיות מופעלים במחשב של המשתמש בקלות. במידה והמשתמש יוריד גאדג'ט, הוא יישאל האם הוא מעוניין בהתקנתו, ואם הגאדג'ט נארז בצורת cab תופיע גם חתימה דיגיטלית, במידה וקיימת. רק לאחד אישור המשתמש יורץ הגאדג'ט.

זמן ריצה - HTML
הקוד שמיוצר הוא אמנם HTML, אבל הוא מיועד בכל זאת לריצה בצורה "מותקנת" מה Sidebar. לפיכך, ניתנות לו הרשאות כאילו הוא שייך לקבוצת Local Machine Zone (ניתן לקנפג את רמת האבטחה). בין האפשרויות שניתנות זה לגשת למידע בדומיינים שונים ברחבי האינטרנט (יכול להיות הכרחי לגאדג'ט) ושימוש ב ActiveX קיימים.
גישה לקבצים על המחשב אפשרית עם הגבלות (רק לקבצי המשתמש, לא לקבצי מערכת).

הגבלת הורים
אחת מהיכולות המשולבות בויסטה זה הגבלת הורים (שליטת הורים). הורים יכולים להחליט ש user מסויים במחשב לא יוכל לגשת לאתרים שמדורגים מדירוג מסויים. במידה והגאדג'ט ינסה לגשת לאתר שהוגבל באמצעות אפשרות זו - הפעולה תיכשל.

UAC
משפט מפתח חשוב בטירוף - כל הגאדג'טים מורצים כאילו הם מורצים מרמת ההרשאות של משתמש רגיל בצורה מבודדת. מה שאומר, שהגאדג'טים רצים עם רמת הרשאות פחותה ולא ניתן לשנות את זה. הם לא יכולים לגשת לכל התיקיות מערכת שנמצאות לוקאלית על המחשב (רק לתיקייה של הגאדג'טים ולעוד מספר מצומצם של מקומות שיש למשתמש שמריץ הרשאות כתיבה), או לתיקיות של משתמשים אחרים. הם לא יוכלו לקרוא cookies שנמצאים על המחשב, או לשנות את קבצי הקונפיגורציה. כל אלה - מחוץ לגבול. מה שנחמד, זה כדי לא להטריד את המשתמש אם גאדג'ט מנסה לבצע פעולות אסורות - לא תופיע הודעה קופצת כמו במידה ותוכנה רגילה תנסה לעשות את זה, אלא הפעולה פשוט לא תתבצע.
במידה והגאדג'ט מפעיל תוכנה שמבצעת את הפעולות הללו, אז כן עלולה להופיע הודעת בקשה בעניין. מפתחי גאדג'טים שמעוניינים להתמודד עם המגבלות הללו, יכולים לעשות תוכנת עזר שהבגאדג'ט יפעיל אותה במידת הצורך, וליצור Installer שיתקין בעצמו את הגאדג'ט ותוכנות העזר וגם רכיבי COM. מובן, שעבור פעולות אלו של ה Installer בניגוד להתקנת גאדג'ט רגילה - דרושות הרשאות Administrator וגם יופיעו הודעות אימות של UAC.

Protected Mode (Internet Explorer)
מצב מוגן באינטרנט אקספלורר, שאמור למנוע מאתרים לתקשר עם המחשב ועם קבצים שעליו לא יפעל עבור גאדג'טים, היות והללו מותקנים במחשב ויכולים לבצע גישה לקבצים ולמשאבי מחשב בצורה חלקית, באמצעות Object Model שנחשף. למטרת שימוש בגאדג'טים.

Windows Defender
מדובר בתוכנה אנטי-רושעות המשולבת במערכת הפעלה. כל גאדג'ט שמורד יעבור סריקה ע"י התוכנה הנ"ל, וכל קובץ שהגאדג'ט ינסה לגשת אליו ייסרק גם.

בהצלחה.

מה זה Sidebar ומה אלה גאדג'טים

אחד החידושים היפים והחשובים ביותר ב Windows Vista למשתמש הסופי אלה ה Sidebar והגאדג'טים שהולכים יד ביד. בתמונה פה ליד, אתם רואים את ה Sidebar. מבחינה ויזואלית, ה Sidebar הוא רק פס שחור אנכי, עם איזשהו אפקט של שקיפות. כוחו של ה Sidebar לא נמצא בצד הויזואלי שלו עצמו, אלא בשימוש האמיתי שלו - סביבת זמן-ריצה שמארחת סוג מסויים של אפליקציות המכונות Gadgets (גאדג'טים). הללו הן כמעט-אפליקציות לכל דבר. "כמעט" מהסיבות הבאות:

1. הם לא מתקמפלים. בסופו של יום, לא נוצרים לנו פה קבצים בינאריים.
2. הם לא רצים על Process נפרד, ולא מערכת ההפעלה היא זאת שמארחת אותם. הם מופעלים ע"י ה Sidebar והוא זה ש"מארח" אותם. אין להם קיום ללא ה Sidebar
3. הם מוגבלים בגודל, לא מוצגים בחלון ה Alt+Tab וכו'  - חלק מההשלכות של העובדה שה Sidebar הוא זה שמארח אותן והן לא אפליקציות לכל דבר.

 כשה Sidebar כן מכיל גאדג'טים, הוא נראה הרבה יותר יפה ויעיל כפי שאתם רואים פה. הגאדג'טים יכולים להיות במצב Docked - שהם דבוקים לסיידבאר, או Undocked כשהם צפים. במצב שהם צפים, הם יכולים להיות יותר גדולים. הגאדג'ט של השעון הוא דוגמא ל Docked והמזג אוויר הוא Undocked.

היתרון העיקרי בגאדג'טים, הוא שהם יכולים ללוות את המשתמש לכל אורך העבודה במחשב. ה Sidebar יכול "לצוף" כל כל שאר התוכנות (הן מתאימות את גודלן בהתאם) וככה לאפשר זמינות גבוהה לגאדג'טים כל העבודה. לכן, ניתן ליצור כל מיני גאדג'טי-עזר כאלה, שיוכלו לשמש את המשתמש כל הזמן. כמו פתקיות לזיכרון דברים, השערים היציגים של המטבעות השונים בעולם וכדומה.

אפשר ליצור גאדג'טים שהם אפליקציות שלמות (לאו דווקא עזרים, או לאו דווקא דברים שמשתלבים עם אפליקציות אחרות) שרצות ב Sidebar. למשל: IRC Client שיפעל כגאדג'ט ויאפשר את כל הדברים של Client IRC רגיל. פה, אנחנו כבר רואים דוגמא לאפליקציה מלאה, לא כזאת שרק מקלה על המשתמש או משתלבת בתוכנות אחרות - אלא אפליקציה עצמאית לחלוטין שלמעשה בנוייה כגאדג'ט ותהיה זמינה למשתמש כל הזמן.

בתור מפתחים, אנחנו יכולים ליצור גם גאדג'טים שמשתלבים בלוגיקה של האפליקציה שלכם, וישתלבו בתשתיות שלה כמו COM ו WebServices. ככה, המשתמש יוכל לקבל נתונים מחלקים שונים באפליקציה שלנו לכל אורך העבודה במחשב, גם אם הללו לא פתוחים אצלו, ואפילו אם האפליקציה סגורה בכלל. כך, למשל, יוכל  רופא לראות את הפגישות הבאות שלו גם כשהוא משחק סוליטר, ומנהל תחנת משטרה יוכל לראות לכל אורך העבודה מפת GPS שתציין לו איפה נמצאת כל ניידת (דוגמאות שחשבתי עליהן הרגע). גם גאדג'ט שנבנה שמציג, נניח, את הפגישות הבאות באאוטלוק גם כשהאאוטלוק סגור, למעשה ישתמש בתשתיות שלו בשביל להקל על המשתמש.

אנחנו יכולים גם להשתלב בתשתיות של מערכת הפעלה, באמצעות שימוש ברכיבי הCOM שלהן, או לחלופין, באמצעות שימוש ב Gadgets Object Model. מדובר בספרייה של מחלקות שמאפשרות גישה לניהול הריצה של הגאדג'ט (מידע שהוא ישמור, הגדרות ויזואליות וכדומה) וגם קבלת מידע ממערכת ההפעלה, גך שאפשר יהיה ליצור גאדג'ט שישתלב בצורה הזאת במערכת הפעלה (ויציג בקלות כמה פריטים יש בסל מיחזור, יתנה ביצוע פעולה מסויימת בכמות הRAM הפנוייה, או סתם יציג כל הזמן נתונים על המחשב).

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

המונח גאדג'ט משמש את מיקרוסופט בעוד מקומות, וכדאי לדעת על מה מדובר - כדי לא להתבלבל:
Windows Vista Gadgets - מה שדיברנו עליו עכשיו.
Windows Live Gadgets - גאדג'טים שמיועדים לרוץ ב Live.com
Windows SlideShow Gadgets - גאדג'טים שאמורים לרוץ על מסך חיצוני של מחשב נייד.

בפרק הבא - ניגש לכתוב את הגאדג'ט הפשוט הראשון שלנו, כזה שיאפשר לעשות חיפוש ממספר מנועי חיפוש ישירות מה Desktop בתור דוגמא לקלות שבה אפשר לבנות גאדג'ט.