מה זה OLE object? — איך embedding ו-linking עובדים, והמלכודות במסמכים עסקיים

“עשיתי double-click על טבלה במפרט Word, והתפריט הפך לתפריט של Excel.” זה מה שקורה כשהטבלה מונחת במסמך לא כתמונה רגילה אלא כ-OLE object.

OLE הוא ראשי תיבות של Object Linking and Embedding. הוא משלב נתוני מסמך שנוצרו באפליקציה אחרת לתוך מסמך מארח, או ב-embedding או ב-linking. מבחינה טכנית, הישות היא COM object שאפשר להטמיע במסמך או לקשר אליו.¹²

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

המאמר הזה מיועד לאנשי IT בעסקים קטנים ובינוניים ולמפתחי אפליקציות עסקיות. הוא מתחיל בהשוואה בין embedding ל-linking, ואז עובר לפעולות יומיומיות, תיקונים לפי תסמין, וההסתייגויות ל-Access ולאבטחה. הפנימיות כמו COM ו-Structured Storage מרוכזות בפרק 7, וההחלטות על תפעול ותכנון עתידי בפרק 8.

1. קודם המסקנות: embedding הוא “עותק בתוך המסמך”, linking הוא “הפניה למקום אחר”

ההבדל בין embedding ל-linking הוא איפה נשמרים הנתונים עצמם. ניידות, גודל קובץ, ואיך עדכונים קורים — כולם נובעים מההבדל הזה.³

embedding מתאים למקרים שבהם רוצים שהמסמך יהיה עצמאי מקובץ המקור. linking מתאים למקרים שבהם כמה מסמכים חולקים את אותם נתונים ורוצים ששינויים במקור ישתקפו. עדכוני קישור, עם זאת, אינם בהכרח אוטומטיים. האם הם אוטומטיים או ידניים נקבע בהגדרה בצד המסמך.⁴⁵⁶

flowchart TB
    accTitle: ההבדל בין embedding ל-linking
    accDescr: embedding שומר את הנתונים עצמם במלואם בתוך מסמך המארח, מה שהופך את המסמך לעצמאי אבל גדול יותר, ואילו linking שם במסמך רק הפניה, הגדרת עדכון ובדרך כלל מידע תצוגה בעוד הנתונים עצמם נשארים בקובץ מקור הקישור, כך שהמסמך נשאר קטן ושינויים במקור יכולים להשתקף לפי הגדרת עדכון הקישור (אוטומטית או ידנית)
    doc["מסמך מארח (מסמך Word וכו')"] --> emb["embedding: שומר את הנתונים עצמם"]
    doc --> lnk["linking: הפניה, הגדרות ו-(בדרך כלל) מידע תצוגה"]
    emb -.-> self["עצמאי אבל גדול יותר"]
    lnk --> src["קובץ מקור הקישור (הנתונים חיים כאן)"]
    src -.-> upd["שינויי מקור יכולים להשתקף (תלוי בהגדרה)"]

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

“הנתונים בתוך המסמך” ו”אפשר לערוך בכל מחשב” הם שני דברים שונים. גם, אם נשאר presentation cache, רק המראה האחרון עשוי להיות מוצג גם כשאפליקציית המקור או מקור הקישור אינם זמינים. להפריד בין “זה נראה”, “אפשר לערוך” ו”זה מעודכן” הוא הבסיס של triage.⁷⁸

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 25, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. איפה פוגשים OLE objects ואיך הם נכנסים למסמך

2.1 פוגשים אותם ב-Word, Excel, Access ובמסמכים עסקיים ישנים

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

מסדי נתונים ששמרו תמונות עובדים או תמונות מוצרים בשדות OLE Object של Access הם נכס קיים טיפוסי נוסף. לשימוש הזה יש בעיית ניפוח, ופרק 5 מכסה את החלטת המעבר.⁹

2.2 “Insert Object” ו-“Paste Special”

Insert Object מאפשר לבחור בין יצירת אובייקט חדש ליצירה מקובץ קיים. יש גם אפשרות תצוגה “Display as icon”.

Paste Special מאפשר לבחור את פורמט הנתונים, ובנוסף, אם להטמיע או לקשר. הערכים שמנויים שם כ-“… Object” הם האפשרויות שמדביקות כ-OLE. גם הנתונים שנשמרים וגם הדרך שבה עורכים אותם אחר כך שונים מהדבקת תמונה רגילה.¹⁰¹¹

שני אלה תואמים לדיאלוגים הסטנדרטיים של OLE, Insert Object ו-Paste Special, ו-MFC מספק classes להצגתם. ההבדל בין הנתיב שיוצר אובייקטים מ-copy and paste או drag and drop לבין הנתיב שיוצר אותם ישירות מ-class רשום או מקובץ מוסבר בפרק 7.1.¹⁰¹²

3. מה קורה ב-double-click

3.1 המארח הוא ה-“container”, האפליקציה שעושה את העריכה היא ה-“server”

כשמסמך Word מכיל טבלת Excel, Word הוא ה-OLE container שמארח אותה, ו-Excel, שמטפל בעריכת הטבלה, הוא ה-OLE server. מסמך שמטפל בנתונים מכמה אפליקציות בתוך מסמך אחד נקרא compound document של OLE.¹²

Word לא מממש את כל תכונות העריכה של Excel. המנגנון משתמש בתכונות של אפליקציית המקור כשפועלים על האובייקט. לכן עריכה דורשת את אפליקציית המקור גם כשהנתונים עצמם שמורים בתוך המסמך.

3.2 double-click מריץ את ה-“verb הראשי” שהאובייקט בחר

OLE object מגדיר את הפעולות שאפשר לבצע עליו כ-verbs: Edit לטבלה, Play לאודיו, וכן הלאה.

אפליקציית המארח מגיבה ל-double-click או לפעולה דומה בקריאה ל-IOleObject::DoVerb. מה שהפעולה כברירת מחדל, ה-verb הראשי (OLEIVERB_PRIMARY), עושה נקבע על ידי האובייקט, לא על ידי המארח. DoVerb מפעיל אוטומטית את אפליקציית ה-OLE server ומבצע את הפעולה המתאימה לאובייקט הזה. double-click לא תמיד אומר Edit.¹³

3.3 מתי העריכה קורה בתוך Word ומתי נפתח חלון נפרד

אם גם האובייקט המוטמע וגם המארח תומכים ב-In-Place Activation, אפשר לערוך את האובייקט בתוך חלון המארח. סרגל התפריטים מוחלף ב-composite menu bar שממזג את התפריטים של ה-container ושל ה-server. זה המנגנון שבו תפריטי העריכה של Excel מופיעים בתוך Word. לחיצה מחוץ לאובייקט מבטלת את ה-activation ומחזירה את התפריטים המקוריים.¹⁴

sequenceDiagram
    accTitle: מ-double-click עד In-Place Activation
    accDescr: אפליקציית המארח מגיבה ל-double-click בהרצת ה-verb הראשי דרך DoVerb של IOleObject, OLE מפעיל את אפליקציית ה-server, ואם גם המארח וגם ה-server תומכים ב-In-Place Activation האובייקט המוטמע נערך בתוך חלון המארח עם תפריטים ממוזגים ולחיצה מחוץ מבטלת את ה-activation ומחזירה את התפריטים המקוריים (אם אחד מהם לא תומך, העריכה קורה בחלון נפרד)
    participant U as משתמש
    participant C as אפליקציית מארח (Word וכו')
    participant S as OLE / אפליקציית server
    U->>C: double-click על האובייקט המוטמע
    C->>S: מריצים את ה-verb הראשי דרך DoVerb
    alt שניהם תומכים ב-In-Place Activation
        S->>C: מפעילים את ה-server, ממזגים את התפריטים
        U->>C: עורכים במקום
        U->>C: לוחצים מחוץ לאובייקט
        C->>S: מבטלים activation, מחזירים את התפריטים המקוריים
    else אחד הצדדים לא תומך
        S->>C: עורכים בחלון נפרד
    end

איור 2: עריכת אובייקט מוטמע במקום דורשת תמיכה גם מה-container וגם מה-server. בלעדיה, העריכה קורה בחלון נפרד.

איך אובייקט נפתח תלוי בסוג האובייקט, ב-verb שרץ, ובמה שהאפליקציות תומכות.

In-Place Activation הוא מנגנון שמניח embedding; הוא לא בשימוש לקישורים. המימוש שלו גם אופציונלי גם ל-container וגם ל-server. עצם העובדה ש”אותו מסמך נפתח אחרת” אינה עילה לקרוא לזה תקלה.¹¹⁴¹³

4. triage לפי תסמין: לא מתעדכן, גדול מדי, לא נפתח

4.1 הטבלה נראית, אבל שינויים במקור הקישור לא משתקפים

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

העבודה של לאתר את מקור הקישור שייכת לרכיב COM שנקרא moniker. כשהעברת file server, שינוי שם תיקייה, שינוי נתיב share, מחיקת קובץ המקור או דומה הופכים את המיקום החדש לבלתי ניתן למעקב, פתרון הקישור נכשל. זה קישור שבור.

אם נשמר presentation cache, הטבלה הישנה נשארת במסמך. זה שטבלה מוצגת אינו ראיה שהקישור בריא. אם האובייקט נוצר בהגדרה שלא שומרת cache, גם המראה האחרון הזה לא נשאר.⁷⁸

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

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

4.2 מסמך Word או Excel גדול באופן חריג

בודקים אם נחוצה עריכה מחדש, ושוקלים מחדש אם המסמך צריך להחזיק את הנתונים עצמם. embedding משכפל את הנתונים ושומר אותם בתוך המסמך, כך שהמסמך גדול בדרך כלל מאשר כשאותו תוכן מקושר. גם presentation cache נשמר בדרך כלל, כך שהמסמך לא בהכרח מכיל רק את הנתונים שמשמשים לעריכה.⁴⁷

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

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

4.3 double-click לא פותח ולא עורך את האובייקט

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

אם אפליקציית המקור חסרה, אפשר להשתמש רק בתצוגה, בתנאי שנשמר presentation cache. נתוני תצוגה ב-cache מתוכננים להיות זמינים מה-container גם כשאפליקציית ה-server לא רצה או לא זמינה.⁷

אם האובייקט הודבק עם “Display as icon”, עם זאת, רואים את האייקון אבל לא את התוכן. לאובייקט שלא מחזיק cache בכלל, גם המראה האחרון לא נשאר. האם יש cache תלוי בערך OLERENDER שצוין בזמן היצירה.⁸

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

1. בודקים תאימות גרסה של האפליקציה. ייתכן שתידרש המרת הטיפוס, ול-OLE יש דיאלוג סטנדרטי להמרה.
2. בודקים רישום COM class (CLSID) חסר או פגום. תיקון הרישום עשוי לדרוש התקנה מחדש של האפליקציה או דומה.
3. בודקים חסימה על ידי הגדרות אבטחה, וקלקול בצד המסמך.¹⁰

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

5. ב-Access, מפרידים “רק לשמור” מ”צריך התנהגות OLE”

5.1 תמונות בשדה OLE Object נוטות לנפח את מסד הנתונים

טיפוס הנתונים OLE Object של Access הוא טיפוס שדה להטמעה או קישור של אובייקטים כמו גיליונות Excel, מסמכי Word, שרטוטים וצלילים בטבלה. הגבול העליון שלו הוא בערך 1 GB.⁹

שימוש בטיפוס הזה רק כדי לשמור תמונות עובדים או תמונות מוצרים הופך את יעילות האחסון לבעיה. Microsoft מסבירה שטיפוס Attachment גמיש יותר מטיפוס OLE Object ומשתמש באחסון ביעילות רבה יותר כי הוא לא יוצר תמונת bitmap של קובץ המקור.⁹

מעבר לטיפוס Attachment, עם זאת, לא מסיר את מגבלות הגודל.

אלה מגבלות של טיפוס Attachment ב-Access. הן חלות על נושא אחר מאשר הגבול של בערך 1 GB של טיפוס OLE Object.¹⁶

5.2 לאחסון בלבד, משתמשים בטיפוס Attachment או בתיקייה עם ניהול נתיבים

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

זה עניין אחר אם צריך התנהגות ייחודית ל-OLE כמו קישור או activation. במקרה כזה, מקבלים את ההחלטה עם השארת המצב הקיים כאחת האפשרויות. במקום “להחליף מיד כי זה טיפוס OLE Object”, קודם מפרידים אם זה אחסון בלבד או אם זה צריך לעבוד כאובייקט.⁹¹⁶

6. אבטחה: מטפלים ב-embedding רגיל וב-OLE packages אחרת

6.1 מסמך הופך לנקודת כניסה להרצת אפליקציה אחרת

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

בפועל, CVE-2014-4114, פגיעות שמריצה קוד שרירותי דרך קבצי PowerPoint ודומים שמכילים OLE object מעוצב, שימשה בהתקפות ממוקדות. כי פורמטי Office ואחרים שיכולים להחזיק OLE objects יכולים להפוך לווקטורי תקיפה, “רק התכוונתי לקרוא את המסמך” הופך לנקודת כניסה להרצה.¹⁷

6.2 חוסמים הפעלת OLE Package ברמת הארגון

OLE packages (Object Packager) ראויים לתשומת לב מיוחדת. זה מנגנון ישן שעוטף קובץ שרירותי לתוך מסמך כ-OLE object, והוא יכול להחזיק גם קבצים להרצה. פגיעות remote code execution שנוגעת ל-Object Packager גם פורסמה.¹⁸

מסיבה זו, איסור הפעלת OLE Package ב-Word, Excel ו-PowerPoint דרך הגדרות Registry הוא אמצעי hardening. המדריך של Microsoft המיושר עם Essential Eight של ממשלת אוסטרליה מראה את ההליך להפצת סקריפט PowerShell להגדרות האלה לארגון דרך Intune.¹⁹

מפצלים את נוהג התפעול לשלוש נקודות.

• לא פותחים, ולא נותנים לאחרים לפתוח, אובייקטים במסמכים ממקור לא ידוע. מתייחסים ל-activation כפעולה באותו משקל כמו פתיחת קובץ אחר.
• חוסמים הפעלת OLE Package ברמת הארגון. זה כמעט אף פעם לא נחוץ בעבודה רגילה, לכן לא סומכים על זהירות אישית בלבד.
• לא מטילים איסור גורף שמתפרש גם על embedding ו-linking רגילים במסמכים פנימיים. שופטים את הסיכון של packages ומסמכים מעוצבים בנפרד משימוש עסקי קיים.

מסקנת המאמר הזה אינה “לאסור OLE בכלל”. במקום לעצור עבודה באיסור אחיד גם על טבלאות Excel מוטמעות רגילות, הנקודה היא להתמקד באובייקטים ממקור לא ידוע וב-OLE packages.

7. פנימיות: התפקידים של COM, Structured Storage ו-monikers

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

7.1 שלושת היסודות של OLE compound documents

OLE compound documents נשענים על COM, Structured Storage ו-Uniform Data Transfer. בנוסף ל-IUnknown של COM, אובייקט חושף ממשקים ייעודיים ל-compound documents כמו IOleObject ו-IViewObject2. אובייקט מקושר מממש בנוסף IOleLink.²

בנתיב העברת הנתונים, ה-OLE server מציע את הנתונים שלו דרך IDataObject ואומר ל-container, דרך פורמטי clipboard ייעודיים, אם אפשר להדביק כ-embedding או כקישור. זה מה שמוביל לאפשרויות ב-Paste Special.¹²

עם זאת, לא כל פעולת יצירה עוברת דרך IDataObject. יצירת אובייקט חדש מ-Insert Object, או יצירה מקובץ קיים, היא נתיב נפרד שיוצר את האובייקט ישירות מ-class רשום או מקובץ. המכניקה של ה-clipboard ושל drag and drop עצמם מכוסה ב-“איך clipboard ו-drag-and-drop עובדים”.

7.2 Structured Storage הוא “מערכת קבצים בתוך קובץ אחד”

Structured Storage יוצר, בתוך קובץ אחד, היררכיה של storages (IStorage), שתואמים לתיקיות, ושל streams (IStream), שתואמים לקבצים. אפשר לקנן substorages ו-streams תחת ה-root storage.²⁰

המימוש הסטנדרטי ש-COM מספק הוא compound files. זה פורמט קובץ יחיד שאפשר לטפל בו באופן עצמאי ממערכות קבצים כמו FAT ו-NTFS, והפורמט עצמו מפורסם כ-MS-CFB (Compound File Binary File Format).²¹²²

ה-container מספק את המקום שבו האובייקט נשמר. אובייקט שנשמר דרך IPersistStorage כותב את הנתונים שלו ל-IStorage שהוא מקבל. מימוש שמשתמש ב-IPersistStream שומר ל-IStream במקום זאת.²

flowchart TB
    accTitle: מבנה פנימי של compound file
    accDescr: ל-compound file יש, תחת ה-root storage שלו, היררכיה של storages שתואמים לתיקיות ו-streams שתואמים לקבצים, אובייקטים מוטמעים שנשמרים דרך IPersistStorage נשמרים ב-substorages ואובייקטים שנשמרים דרך IPersistStream ב-streams, storage של אובייקט מוטמע יכול לשאת CLSID שמזהה את אפליקציית המקור (יכול גם להיות ריק), stream של presentation cache נשמר בדרך כלל אבל יכול להיעדר לפי ההגדרה בזמן היצירה, והכל עובד כמערכת קבצים בתוך קובץ אחד
    root["root storage (גוף המסמך)"] --> s0["stream: נתוני גוף"]
    root --> st1["storage: embedding (IPersistStorage)"]
    st1 --> s1["stream: נתוני אובייקט"]
    st1 --> s2["stream: presentation cache (רגיל)"]
    st1 -.-> cls["CLSID יכול לזהות את המקור (אופציונלי)"]
    root -.-> s3["stream: persistence של IPersistStream"]

איור 3: נבנית היררכיה בתוך המסמך, והאובייקט שומר את הנתונים שלו עצמו. מבחינים בין persistence דרך storage לבין persistence דרך stream.

רשומת directory יכולה לשאת CLSID שמזהה את אפליקציית המקור של האובייקט. אם ה-storage של ה-embedding מכיל CLSID, אפשר לקבוע איזו אפליקציה צריכה לפתוח את האובייקט. ה-CLSID יכול להיות ריק, עם זאת, וגם ה-presentation cache יכול להיעדר לפי ההגדרה בזמן היצירה.²²⁸

7.3 המעבר ל-.docx לא גרם לפורמט האחסון של OLE להיעלם

בפורמטי Office הישנים .doc / .xls, הקובץ עצמו הוא compound file. גוף המסמך נשמר כ-streams, ואובייקטים מוטמעים כ-substorages.

ה-.docx / .xlsx הנוכחיים הם פורמטי Open XML מבוססי ZIP, אבל הבינאריים של הטמעות OLE ישנות, oleObject*.bin, עדיין נשמרים בפורמט compound file. מצד שני, כשמסמכי Office חדשים מוטמעים זה בזה, קובץ כמו .xlsx יכול לשבת בתוך ה-ZIP כמו שהוא.²²

כלומר, ה-compound file אינו רק “פורמט מסמך ישן”; הוא שורד בתוך מסמכים נוכחיים כפורמט אחסון מקונן.

7.4 monikers עוקבים אחרי מיקום הקישור; הגדרות הקישור שולטות בעדכונים

moniker הוא רכיב COM שמבטא את מיקום האובייקט כשם ופותר אותו כשצריך. הפתרון הזה נקרא binding. אובייקט מקושר משתמש ב-monikers כדי לנהל מתן שמות, מעקב ו-activation של מקור הקישור.¹⁵

IOleLink הוא הממשק שמספק ל-container ניהול של מקור הקישור. הנוכחות או ההיעדר שלו מאפשרים ל-container להבחין בין embedding לקישור. גם כשמסמך שמכיל קישור נשמר, נתוני הקישור עצמם נשמרים במקור הקישור. מה שנשאר במסמך הוא מידע הניהול של הקישור עצמו, כמו השם והמיקום והגדרת העדכון, ובדרך כלל presentation cache.¹⁵

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

8. איך חיים עם OLE היום: לא מוסיפים תלויות חדשות, מכירים את הקיימות

המדיניות הבסיסית היא להימנע מהסתמכות על embedding של OLE בתכנונים חדשים, ולטפל בנכסים קיימים ב”שמירה על סביבה שיכולה לפתוח אותם” וב”עשיית inventory”. האם להמשיך להשתמש נקבע מקרה-מקרה.

החלטות Access והאבטחה תואמות כל אחת גם לחומר של Microsoft עצמה.⁹¹⁹

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

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

ה-inventory צריך לזהות שלושה דברים: השרתים שמחזיקים מקורות קישור, המסמכים שמכילים embeddings, ומסדי הנתונים שמשתמשים בטיפוס OLE Object. ברגע שהתלויות האלה ידועות, אפשר לבנות מעברים, hardening והמרות לתוך תוכנית.

9. סיכום

OLE object הוא COM object לטיפול בנתוני מסמך של אפליקציה אחרת כ-embedding או כקישור. embedding שומר את הנתונים בתוך המסמך; linking מפנה לנתונים במקום אחר. מתחילים בליישר את ההבדל הזה.²⁴⁵

אחר כך, חושבים על תצוגה, עריכה ועדכון בנפרד. גם אם נשאר presentation cache, אי אפשר לערוך את האובייקט בלי אפליקציית המקור, ואי אפשר לעדכן אותו אם אי אפשר לעקוב אחרי מקור הקישור. איך זה נפתח ב-double-click גם משתנה לפי סוג האובייקט, ה-verb והתמיכה ב-In-Place Activation.

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

COM, ה-clipboard ו-drag and drop, וה-compound documents במאמר הזה הם פנים שונות של המילה OLE. הפרדת התפקידים של תשתית רכיבים, העברת נתונים ושילוב למסמכים מקלה לעקוב אחרי מה שקורה בתוך נכסים עסקיים ישנים.

מאמרים קשורים

• COM, ActiveX ו-OCX — ההבדלים והקשר ביניהם
• איך clipboard ו-drag-and-drop עובדים — טיפול נכון ב-OLE data transfer באפליקציות עסקיות
• STA ו-MTA ב-COM — threading model, ואיך נמנעים מ-hang
• למה תהליכי EXCEL.EXE נשארים אחרי אוטומציית COM של Excel ב-C# — דפוסי שחרור הפניות והחלטת ההחלפה
• ActiveX / OCX: להשאיר, לעטוף או להחליף
• הארכת חיים ומעבר של אפליקציות עסקיות ב-VB6 / Access — טבלת החלטה להשאיר, לעטוף או להחליף

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בחקירה ובמעבר של נכסי מסמכים ומסדי נתונים ישנים שמערבים OLE ו-COM (יציאה מטיפוס OLE Object של Access, inventory של מסמכים מוטמעים והמרתם ל-PDF, טיפול גורף בקישורים שבורים), בתחזוקה ובשינוי של אפליקציות עסקיות שכוללות רכיבי COM, ובתכנון אפליקציות משולבות Office. אפשר להתייעץ גם מהשלב של “אין לי מושג מה קורה כשאני עושה double-click על המסמך הזה”.

• Windows Custom Software Development
• פיתוח רכיבי COM
• ייעוץ טכני וסקירת תכנון
• יצירת קשר

קישורים

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

מה ההבדל בין embedding ל-linking?

ההבדל הוא איפה נשמרים הנתונים עצמם. embedding שומר את נתוני האובייקט במלואם בתוך מסמך המארח. המסמך הופך לעצמאי מקובץ המקור, כך שמסירה למחשב אחר אף פעם לא שוברת הפניה (אם כי עריכה דורשת גם את אפליקציית המקור במחשב המקבל; בלעדיה אפשר רק לצפות ב-presentation cache אם אחד נשמר, ואובייקט שמוצג כאייקון אי אפשר לבדוק בכלל). בתמורה הקובץ גדל, ושינויים בנתוני המקור לא משתקפים במסמך. linking שם במסמך רק הפניה (שם ומקום של מקור הקישור), את הגדרת העדכון ומידע תצוגה, בעוד הנתונים עצמם נשארים בקובץ מקור הקישור. המסמך קטן ושינויים במקור הקישור יכולים להשתקף בו (אוטומטית או ידנית, לפי הגדרת העדכון של הקישור), אבל אם מקור הקישור מועבר או משנה שם כך שאי אפשר יותר לעקוב אחריו, הקישור נשבר. בוחרים איך להדביק בדיאלוג Paste Special או Insert Object.

למה אי אפשר לפתוח או לערוך אובייקט מוטמע במסמך ב-double-click?

הסיבה הנפוצה ביותר היא שאפליקציית המקור של האובייקט הזה לא מותקנת במחשב הנוכחי. עריכת אובייקט מוטמע מפעילה את אפליקציית המקור (OLE server), כך שבלי זה אפשר רק לצפות ב-presentation cache אם אחד נשמר, ואם האובייקט מוצג כאייקון אי אפשר אפילו לראות את התוכן. אם אפליקציית המקור קיימת והאובייקט עדיין לא נפתח, חושדים בסדר הזה: מקרה שבו הבדל גרסה דורש המרה, רישום COM class (CLSID) חסר או פגום שאפשר לתקן בהתקנה מחדש או דומה, קלקול בצד המסמך, ומקרה שבו הגדרות אבטחה חוסמות activation.

למה קבצי Word ו-Excel הופכים גדולים באופן חריג עם אובייקטים מוטמעים?

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

אחרי שהעברנו את ה-file server, האובייקטים המקושרים במסמכים הפסיקו להתעדכן. למה?

כי מה שאובייקט מקושר מחזיק בתוך המסמך אינו הנתונים עצמם אלא רק מידע השם והמיקום של מקור הקישור (moniker), הגדרת העדכון, ו-presentation cache. כשמיקום מקור הקישור משתנה דרך העברת file server, שינוי שם תיקייה, שינוי נתיב share או דומה, ואי אפשר יותר לעקוב אחרי המיקום החדש, פתרון הקישור נכשל ורק ה-presentation cache הישן נשאר במסמך (לאובייקט שנוצר בהגדרה שלא שומרת cache, גם התצוגה הזו לא נשארת). כדי לתקן, מצביעים מחדש את נתיב מקור הקישור למיקום החדש מ-Edit Links בכל מסמך. שימו לב שאם הנתיב נכון והאובייקט עדיין לא מתעדכן, הקישור עשוי פשוט להיות מוגדר לעדכון ידני ולא שבור, לכן בודקים גם את הגדרת שיטת העדכון. אם יש הרבה מסמכים, עושים inventory של המסמכים שמכילים קישורים לפני ההעברה, ואם אפשר בונים עדכון קישורים גורף לתוך התוכנית.

שמעתי ש-OLE objects הם סיכון אבטחה. בסדר להמשיך להשתמש בהם?

המבנה של OLE, שמביא אובייקט של אפליקציה אחרת לתוך מסמך ומריץ אותו בצד שפותח, הוא גם אמצעי משלוח נוח לתוקפים, ופגיעויות arbitrary code execution דרך OLE objects מעוצבים שימשו בהתקפות ממוקדות אמיתיות. OLE packages, שיכולים לעטוף קובץ שרירותי, מסוכנים במיוחד, והנחיות ציבוריות כמו Essential Eight של ממשלת אוסטרליה ממליצות לאסור הפעלת OLE Package ב-Word, Excel ו-PowerPoint דרך הגדרות Registry. אין צורך באיסור גורף שמתפרש גם על embedding ו-linking רגילים במסמכים פנימיים; נקודת האמצע המציאותית היא לא לפתוח אובייקטים במסמכים ממקור לא ידוע, ולחסום הפעלת OLE Package ברמת הארגון.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

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