מה זה COM /‏ ActiveX /‏ OCX — הסבר מרוכז על ההבדלים והקשרים

שלוש המילים COM /‏ ActiveX /‏ OCX בדרך כלל מגיעות כחבילה אחת בפרויקטים לגאסיים של Windows.

• ספק שולח .ocx
• על מסך של Access או VB6 יושב רכיב מסתורי
• אומרים לכם ‘זה COM’, וברגע הבא ‘זה ActiveX’
• אחר כך מגיעות בבת אחת מילים כמו regsvr32, 32bit /‏ 64bit, ומצב IE

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

flowchart TB
    accTitle: המבנה שבו השיחה מפסיקה להתחבר
    accDescr: כשמונחים קרובים כמו COM, ActiveX ו-OCX מופיעים באותו שטח בבת אחת, השיחה מפסיקה להתחבר, אבל אם מפרידים מה הבסיס, מה הרכיב ומה הקובץ, החקירה, המעבר וההסבר נעשים קלים יותר.
    mix["שלוש המילים מופיעות בבת אחת"] --> lost["השיחה לא מתחברת"]
    split["מפרידים לבסיס, רכיב וקובץ"] --> clear["חקירה, מעבר והסבר נעשים קלים"]

איור 1: למאמר הזה מטרה אחת. להפריד ‘מה הבסיס, מה הרכיב, ומה הקובץ’.

במאמר הזה נסדר את מה זה COM, מה זה ActiveX, מה זה OCX, לפי סדר שבו נראים ההבדלים והקשרים. בייחוד נבהיר מה הבסיס, מה הרכיב, ומה הקובץ.

תוכן העניינים

1. תחילה המסקנה (בקצרה)
2. COM /‏ ActiveX /‏ OCX במאמר הזה
3. תחילה, סידור בעמוד אחד
   • 3.1. תרשים קשרים
   • 3.2. סידור מקוצר של המונחים
4. מה זה COM
   • 4.1. בקצרה
   • 4.2. מה חשוב ב-COM
   • 4.3. פתק שורה למונח
5. מה זה ActiveX
   • 5.1. בקצרה
   • 5.2. ActiveX אינה ייעודית לדפדפן
6. מה זה OCX
   • 6.1. בקצרה
   • 6.2. מה ההבדל מ-.dll
7. סידור ההבדלים בטבלה
8. איפה זה היה בשימוש
9. למה קל להתבלבל
10. איך כדאי להתייחס לזה היום בפועל
11. אי-הבנות נפוצות
12. נקודות בדיקה כשחוקרים
13. סיכום
14. מקורות

מפת הידע של המאמר

‏COM הוא הבסיס שדרכו רכיבים ב-Windows מתקשרים באמצעות חוזה בינארי, ו-ActiveX הוא ההקשר של רכיב לשימוש חוזר שמבוסס על COM ו-OLE/‏Automation, ומשמש להטמעה בתוך host או container. ‏OCX הוא רק סיומת קובץ שנפוצה כמימוש של אותו בקר ActiveX, ולא המושג עצמו. ‏ActiveX נמצא בשימוש ממושך לא רק בדפדפן אלא גם בצד אפליקציות Windows, למשל VB6, ‏MFC ושימוש ב-wrapper COM מ-WinForms. ‏CLSID ו-ProgID, ספריית טיפוסים, ומודל ה-apartment של STA/‏MTA תומכים בזיהוי ובקריאה של COM, ורישום עם הרשאות מנהל דרך regsvr32, יחד עם התאמת ביטים בין 32bit ל-64bit, קובעים את פריסת ה-OCX. ‏ActiveX בצד הדפדפן ממשיך לפעול בהנחה של מצב IE כגשר לתאימות לאחור.

flowchart LR
    accTitle: מפת הידע של COM, ‏ActiveX ו-OCX
    accDescr: תרשים שמראה את היחס שבו COM הוא הבסיס, ‏OLE/‏Automation ו-ActiveX נערמים מעליו, ומגיעים ל-OCX כקובץ מימוש; את מנגנון הזיהוי והקריאה של COM — CLSID, ‏ProgID, ספריית טיפוסים ומודל ה-apartment; את אילוץ הרישום עם הרשאות מנהל ואת התאמת הביטים דרך regsvr32; ואת התלות של ActiveX בצד הדפדפן במצב IE.
    com["‏COM (Component Object Model)"]
    activex["ActiveX"]
    ocx["OCX"]
    ole_automation["OLE/Automation"]
    clsid["CLSID(Class ID)"]
    progid["ProgID(Programmatic Identifier)"]
    vb6["Visual Basic 6.0(VB6)"]
    type_library["ספריית טיפוסים (TLB)"]
    dotnet["‏.NET (מ-Core ואילך)"]
    com_apartment_model["מודל ה-apartment של COM‏ (STA/MTA)"]
    regsvr32["regsvr32"]
    admin_rights["הרשאות מנהל"]
    bitness_match_requirement["דרישת התאמת bitness"]
    ie_mode["מצב IE"]
    mfc["MFC(Microsoft Foundation Classes)"]
    windows_forms["Windows Forms"]
    dumpbin["dumpbin"]
    activex -->|"משתמש ב"| com
    ocx -->|"מממש את"| activex
    ole_automation -->|"משתמש ב"| com
    activex -->|"משתמש ב"| ole_automation
    com -->|"משתמש ב"| clsid
    progid -->|"משתמש ב"| clsid
    vb6 -.->|"משתמש ב"| type_library
    dotnet -.->|"משתמש ב"| type_library
    com -->|"משתמש ב"| com_apartment_model
    regsvr32 -->|"מאוטמט את"| com
    regsvr32 -.->|"מחייב"| admin_rights
    ocx -->|"מוגדר באמצעות"| regsvr32
    ocx -->|"מחייב"| bitness_match_requirement
    activex -.->|"מחייב"| ie_mode
    vb6 -->|"משתמש ב"| activex
    mfc -.->|"משתמש ב"| activex
    windows_forms -.->|"משתמש ב"| activex
    ocx -->|"נבדק באמצעות"| dumpbin

בתרשים, קו מלא מציין קשר שמתקיים תמיד וקו מקווקו מציין קשר מותנה (תנאי ההתקיימות מפורטים בהסבר של כל קשר בעמוד המפורט). רשימת כל הקשרים (סך הכול 18, עם אסמכתה ורמת ודאות) והגדרות המושגים המרכזיים מרוכזות בעמוד המפורט של מפת הידע (ביפנית). נתונים: JSON-LD / Turtle

1. תחילה המסקנה (בקצרה)

קודם ניסוח גס אבל שימושי:

• COM הוא הבסיס. חוזה בינארי שדרכו רכיבים ב-Windows מתקשרים זה עם זה
• ActiveX הוא הקשר רכיב מבוסס COM. בייחוד נוטה להופיע כבקר שמוטמע בתוך host
• OCX הוא קובץ מימוש נפוץ לבקר ActiveX. נתקלים בו כסיומת קובץ
• כלומר, אם תופסים בערך כCOM = מנגנון, ActiveX = הקשר הרכיב, OCX = קובץ — התמונה מתבהרת
• הזיכרון ActiveX = הדבר המסוכן הישן של הדפדפן נכון בחצי, ולא מספיק בחצי השני. ActiveX אינה ייעודית לדפדפן
• מדברים על OCX = ActiveX כמעט כמילים נרדפות, אבל למעשה זה ערבוב בין מושג לסיומת קובץ
• זו לא טכנולוגיה שמעמידים במרכז פיתוח חדש כיום, אבל באפליקציות Windows קיימות, ב-Office, ב-Access, ב-SDK של ציוד וב-Web פנים-ארגוני עדיין נתקלים בה

תחילה מתחילים מהפרדת השלושה האלה:

1. האם זה סיפור על COM
2. האם זה סיפור על בקר ActiveX
3. האם פשוט רואים קובץ .ocx וקוראים לו כך

כשזה מתברר, הערפל מתפזר לא מעט.

flowchart TB
    accTitle: שלוש השאלות להפרדה בהתחלה
    accDescr: מתחילים מלהפריד האם הסיפור שמולנו הוא על מנגנון COM, על רכיב בקר ActiveX, או פשוט על ראיית קובץ ocx וקריאה לו כך.
    q{"על מה מדברים כרגע"}
    q --> a["COM = סיפור על מנגנון"]
    q --> b["ActiveX = סיפור על הקשר רכיב"]
    q --> c["OCX = סיפור על קובץ"]

איור 2: כשמתבלבלים, חוזרים לשלוש האפשרויות האלה. COM הוא מנגנון, ActiveX הקשר רכיב, OCX קובץ.

2. COM /‏ ActiveX /‏ OCX במאמר הזה

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

• COM: מודל הרכיבים של Windows עצמו. הבסיס לממשקים, GUID, רישום וקריאה
• ActiveX: בקר שאפשר להטמיע, או ההקשר של שימוש בו, מבוסס על COM. בפועל בדרך כלל מתכוונים במיוחד לבקר ActiveX
• OCX: סיומת קובץ נפוצה למימוש בקר ActiveX. .ocx

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

לכן גם המאמר הזה יתקדם בעיקרון לפי ActiveX = סיפור שמתקרב לבקר ActiveX.

flowchart TB
    accTitle: הרוחב של המילה ActiveX והמיקוד של המאמר הזה
    accDescr: היסטורית המילה ActiveX שימשה בתקופה מסוימת במשמעות רחבה יותר, אבל מה שגורם היום בפועל לבלבול הוא בקר, הטמעה, host, דפדפן ורישום, ולכן המאמר הזה ממקד את עצמו בסיפור שמתקרב לבקר ActiveX.
    word["המילה ActiveX"] --> wide["היסטורית גם משמעות רחבה יותר"]
    word --> now["מה שגורם היום לבלבול הוא סביב הבקר"]
    now --> focus["המאמר הזה מתקדם בכיוון הבקר"]
    now -.-> items["הטמעה, host, דפדפן, רישום"]

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

3. תחילה, סידור בעמוד אחד

3.1. תרשים קשרים

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

flowchart LR
accTitle: היחס בין COM,‏ OLE,‏ ActiveX ו-OCX
accDescr: תרשים המראה ש-COM הוא בסיס החוזה הבינארי, שמעליו OLE ו-Automation, שעליהם נשען הקשר הבקר של ActiveX, שהבקר מופץ בדרך כלל כקובץ OCX, ושה-host או ה-container הוא זה שמארח את הבקר.
    COM["COM‏
בסיס החוזה הבינארי"] --> OLE["OLE / ‏Automation‏
מנגנון הטמעה ואוטומציה"]
    OLE --> AX["ActiveX‏
הקשר בקר מבוסס COM"]
    AX --> CTRL["בקר ActiveX"]
    CTRL --> OCX["OCX (‎.ocx)‏
צורה נפוצה כקובץ מימוש"]

    HOST["Host / ‏Container‏
IE / ‏Access / ‏VB6 / ‏MFC / ‏WinForms"] --> CTRL

איור 4: תרשים קשרים שבו COM הוא הבסיס, ומעליו נערמים OLE / ‏Automation, ‏ActiveX ו-OCX, וה-host נושא את הבקר.

מה שחשוב כאן — COM ו-ActiveX אינן אותה מילה.

• COM הוא הבסיס
• OLE / ‏Automation הוא מנגנון להטמעה ולאוטומציה
• ActiveX מופיע כהקשר הבקר שמשמש מעליו
• OCX הוא קובץ נפוץ למימוש הבקר הזה

לכן, אם שואלים האם ActiveX זה COM — התשובה היא הבסיס הוא COM, אבל ActiveX אינו COM עצמו.

3.2. סידור מקוצר של המונחים

אם רוצים לזכור בקיצור המקסימלי, זה מספיק:

• COM הוא מנגנון
• ActiveX הוא הקשר הרכיב
• OCX הוא קובץ

4. מה זה COM

4.1. בקצרה

‏COM הוא קיצור של Component Object Model, ומדובר בחוזה בינארי שדרכו רכיבים ב-Windows מתקשרים זה עם זה.

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

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

לדוגמה, אלה הדברים האופייניים ל-COM (המשמעות של כל מילה מסוכמת בשורה אחת בסעיף 4.3).

• ספירת הפניות (reference counting) באמצעות IUnknown
• חיפוש ממשק באמצעות QueryInterface
• זיהוי מבוסס GUID כמו IID או CLSID
• שימוש in-process באמצעות DLL
• שימוש out-of-process באמצעות EXE

בקיצור, COM הוא הבסיס לתרבות המרכיבים (component) של Windows.

flowchart TB
    accTitle: הרעיון של חוזה בינארי
    accDescr: COM מחבר רכיבים דרך חוזה בינארי, הבטחה שנשמרת בצורה שאחרי הקומפילציה ולא לפי צרכי קוד המקור או מפרט השפה, ולכן אפשר להשתמש ברכיב שנבנה ב-C++ משפה אחרת או מאפליקציה אחרת.
    part["הרכיב〔המימוש מוסתר〕"] --> contract["חוזה בינארי〔ההבטחה שנחשפת〕"]
    contract --> user["שפה אחרת / אפליקציה אחרת"]
    contract -.-> note["ההבטחה נשמרת גם אחרי הקומפילציה"]

איור 5: הליבה של COM היא ‘להסתיר את המימוש ולחבר רק דרך החוזה’. לכן אפשר להשתמש ברכיב מעבר לשפה.

4.2. מה חשוב ב-COM

אם רוצים רק את הבסיס, אלה החשובים ב-COM:

• מרכז הממשק
  • קובעים מה חושפים לפני המימוש
• זיהוי באמצעות GUID
  • מזהים מחלקה או ממשק באופן ייחודי
• הפרדה בין ה-host למימוש
  • הצד הקורא לא צריך לדעת את המימוש הפנימי
• חוצה תהליכים
  • אפשר להשתמש לא רק באותו תהליך אלא גם כרכיב בתהליך אחר

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

flowchart TB
    accTitle: ארבעת עמודי היסוד של COM
    accDescr: תכנון ממוקד ממשק, זיהוי ייחודי באמצעות GUID, הפרדה בין ה-host למימוש, ויכולת לחצות תהליכים — ארבעה עמודים שהופכים את COM לתכנון שימוש חוזר מבוסס חוזה.
    com["הבסיס של COM"] --> p1["מרכז הממשק"]
    com --> p2["זיהוי באמצעות GUID"]
    com --> p3["הפרדה בין host למימוש"]
    com --> p4["חוצה תהליכים"]

איור 6: ארבעת העמודים שתומכים ב-COM. כבר מתקופה מוקדמת היה בו תכנון שימוש חוזר מבוסס חוזה.

4.3. פתק שורה למונח

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

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

flowchart TB
    accTitle: התנהגות הבסיס סביב IUnknown
    accDescr: IUnknown, הבסיס של כל ממשקי COM, שואל ממשק אחר עם QueryInterface, מגדיל ומקטין ספירת הפניות עם AddRef ו-Release, ומשחרר את הרכיב כשהמונה מגיע ל-0.
    iu["IUnknown〔הבסיס לכולם〕"] --> qi["שואל עם QueryInterface"]
    qi --> got["אם קיים, מוחזר מצביע"]
    iu --> rc["מנהל את המונה עם AddRef ו-Release"]
    rc --> zero["כשמגיע ל-0, הרכיב משתחרר"]

איור 7: שלוש המתודות של IUnknown, שבמרכז טבלת המונחים, מתחלקות לשתי עבודות — ‘לשאול’ ו’לספור’.

5. מה זה ActiveX

5.1. בקצרה

הכי קל להבין את ActiveX כרכיב תוכנה לשימוש חוזר מבוסס COM, ובייחוד כבקר שמוטמע בתוך host או container.

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

עדיף לא לתפוס את ActiveX כטכנולוגיה ענקית שעומדת בגאווה לבדה, אלא כרכיב שפועל כשהוא מוטמע בתוך host כלשהו — כך לא טועים בכיוון.

flowchart TB
    accTitle: רכיב שפועל כשהוא מוטמע ב-host
    accDescr: בפועל, ברוב המקרים כשאומרים ActiveX הכוונה לבקר ActiveX, שמצביע על רכיב כמו כפתור, grid, גרף, viewer או רכיב אינטגרציה עם ציוד, שמוטמע בתוך host או container ופועל שם.
    host["Host / ‏Container"] --> ctrl["בקר ActiveX"]
    ctrl --> ex1["grid או לוח שנה"]
    ctrl --> ex2["viewer או רכיב אינטגרציה עם ציוד"]
    ctrl -.-> note["לא טכנולוגיה ענקית שעומדת לבדה"]

איור 8: הכי קל לתפוס את ActiveX כ’רכיב שפועל כשהוא מוטמע’ — כך לא טועים.

5.2. ActiveX אינה ייעודית לדפדפן

הרושם ActiveX = הדבר הזה של Internet Explorer חזק למדי. זה לא טעות, אבל זה לא הכול.

הנה כמה מקומות שבהם היה בשימוש בקר ActiveX:

• טפסי Access
• אפליקציות VB6 (‏Visual Basic 6.0)
• container של MFC (‏Microsoft Foundation Class Library)
• סביבת Office / ‏VBA
• שימוש ב-wrapper COM מתוך WinForms
• Internet Explorer, וההקשר של תפעול תואם אליו

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

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

flowchart TB
    accTitle: המקומות שבהם בקר ActiveX היה בשימוש
    accDescr: טפסי Access, אפליקציות VB6, container של MFC, סביבת Office ו-VBA, שימוש ב-wrapper COM מתוך WinForms, ו-Internet Explorer — ActiveX אינה ייעודית לדפדפן ונמצאה בשימוש ממושך גם בצד אפליקציות Windows.
    ax["בקר ActiveX"] --> d["Access, ‏VB6 או ‏MFC"]
    ax --> o["סביבת Office ו-VBA"]
    ax --> w["‏wrapper COM מתוך WinForms"]
    ax --> ie["משפחת Internet Explorer"]
    ie -.-> myth["רק כאן זה נודע"]

איור 9: בלט רק ב-IE. רוב המקומות שבהם היה בשימוש נמצאים בצד אפליקציות Windows.

6. מה זה OCX

6.1. בקצרה

‏OCX היא סיומת קובץ נפוצה למימוש בקר ActiveX. אם מוצאים .ocx בשטח של Windows, אפשר בבטחה לחשוד קודם כול ברכיב COM ממשפחת הבקרים המוטמעים.

המקומות שבהם הוא מופיע הם בערך אלה:

• תפוצה של SDK ספק
• פרויקטים ישנים של VB6 / ‏Access / ‏MFC
• קובץ שמיועד לרישום בתוך תוכנת התקנה
• רכיב שדורש regsvr32

חשוב לזכור ש-OCX הוא צורת קובץ, לא המושג עצמו. לכן, אם רוצים לענות בגסות על מה זה OCX — זה קובץ שנתקלים בו לרוב כמימוש בפועל של בקר ActiveX.

6.2. מה ההבדל מ-.dll

גם כאן קל להתבלבל.

• ‏.ocx מרמז חזק למדי על היותו בקר ActiveX
• ‏.dll יכול להיות ספרייה רגילה, שרת COM, או DLL תלוי שקשור ל-ActiveX

כשרואים .ocx אפשר לחשוד כמעט בוודאות שמדובר בהקשר של ActiveX, אבל כשרואים רק .dll עדיין לא ברור מה הוא.

בפועל נפוץ:

• ‏vendorcontrol.ocx
• ‏vendorhelper.dll
• ‏vendorcore.dll

שורה לצד שורה — דפוס שבו הכוכב הוא ה-OCX, ו-DLL תומך מהצד.

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

flowchart TB
    accTitle: ההבדל במידע שאפשר לקרוא מהסיומת
    accDescr: ocx מרמז חזק על היותו בקר ActiveX, אבל dll עדיין לא ברור אם הוא ספרייה רגילה, שרת COM או DLL תלוי. בפועל נפוץ דפוס שבו OCX הוא הכוכב ו-DLL תומך מהצד.
    q{"מה הסיומת"}
    q -->|"‏.ocx"| ax["אפשר לחשוד כמעט בקר ActiveX"]
    q -->|"‏.dll"| unk["עדיין לא ברור מה הוא"]
    unk --> roles["ספרייה, שרת COM או תלוי"]
    ax -.-> pair["הכוכב OCX ו-DLL תומך מהצד"]

איור 10: מ-.ocx אפשר לחשוד, אבל .dll צריך לבדוק תפקיד לפני שיודעים מה הוא.

7. סידור ההבדלים בטבלה

אם רוצים לזכור לפי הטבלה, קודם כול:

• COM הוא עבודות היסוד
• ActiveX היא תרבות הרכיבים שנשענת מעליו
• OCX הוא קובץ שמלקטים בשטח

8. איפה זה היה בשימוש

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

באופן קונקרטי, אלה המקומות:

• אפליקציות שולחן עבודה
  • VB6
  • MFC / ‏C++
  • טפסי Access
  • סביבת Office / ‏VBA
• דפדפן / Web פנים-ארגוני
  • viewer שמוטמע ב-Internet Explorer
  • רכיב חתימה
  • רכיב העברת קבצים
  • רכיב אינטגרציה עם ציוד היקפי
• אפליקציות ‏.NET קיימות
  • בקר ActiveX קיים שנעטף ומשמש מתוך WinForms
  • מקרים שבהם מאריכים חיים של נכס COM קיים כרכיב UI

גם כאן, בסופו של דבר חוזרים לסיפור ש-ActiveX אינה ייעודית לאינטרנט. מה שנראה כטכנולוגיית Web הוא רק בגלל שהוא בלט מאוד ב-IE — עדיף לראות בו בפועל טכנולוגיית רכיבים מוטמעים של Windows.

flowchart TB
    accTitle: הפער בין המראה למציאות
    accDescr: מכיוון שבלט מאוד ב-IE, ActiveX נוטה להיראות כטכנולוגיית Web ישנה, אבל בפועל היה בשימוש רחב באפליקציות שולחן עבודה, ב-Web פנים-ארגוני ובאפליקציות .NET קיימות, והמציאות היא טכנולוגיית רכיבים מוטמעים של Windows.
    look["הזיכרון מבליטה ב-IE"] --> web["נראה כטכנולוגיית Web ישנה"]
    real["המקומות שבהם היה בשימוש בפועל"] --> r1["אפליקציות שולחן עבודה"]
    real --> r2["דפדפן ו-Web פנים-ארגוני"]
    real --> r3["אפליקציות .NET קיימות"]
    r1 -.-> truth["המציאות היא טכנולוגיית רכיבים מוטמעים של Windows"]

איור 11: הפער בין המראה של ‘טכנולוגיית Web ישנה’ למציאות של ‘טכנולוגיית רכיבים מוטמעים של Windows’.

9. למה קל להתבלבל

9.1. השכבות של המילים שונות, אבל מגיעות לאותה שיחה

• COM הוא סיפור על הבסיס
• ActiveX הוא סיפור על הקשר הרכיב
• OCX הוא סיפור על הקובץ

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

9.2. המילה ActiveX קצת רחבה

‏COM יחסית קבוע במשמעותו. לעומת זאת, ActiveX משמש מעט יותר רחב, גם היסטורית וגם בפועל.

תלוי באדם, הכוונה יכולה להיות ל:

• הבקר עצמו
• קובץ .ocx
• רכיב ישן שפועל ב-IE
• כל רכיב מוטמע מבוסס COM

וזה נוטה להשתבש. בשלב הזה, השיחה כבר לא מתחברת.

9.3. הרצון לקרוא לכול ‘ActiveX’ ברגע שרואים .ocx

מבינים את הרגש הזה. בדרך כלל זה גם מספיק כדי להסתדר.

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

• האם זה רכיב UI
• באיזה host זה פועל
• האם צריך רישום
• מה מצב ה-32bit / ‏64bit
• האם יש תלות בדפדפן

בהמשך נופלים על זה כמו שצריך.

flowchart TB
    accTitle: שלוש הסיבות לבלבול
    accDescr: מגיעים לשיחה אחת נושאים שהשכבה שלהם שונה, המילה ActiveX רחבה במקצת, ורואים ocx וקוראים לכול כך — שלוש הסיבות שיוצרות את הבלבול.
    r1["נושאים משכבות שונות מגיעים לאותה שיחה"] --> mixup["השיחה מתבלבלת"]
    r2["המילה ActiveX רחבה"] --> mixup
    r3["רואים ocx וקוראים לכול כך"] --> mixup
    mixup -.-> risk["בשלב מעבר או חקירה נופלים על זה"]

איור 12: מהות הבלבול היא שנושאים משכבות שונות — בסיס, רכיב וקובץ — מופיעים בו-זמנית באותו שטח.

10. איך כדאי להתייחס לזה היום בפועל

קודם כול, מציאת COM / ‏ActiveX / ‏OCX לא אומרת שצריך מיד לפסול הכול. עם זאת, לטפל בכולם באותה טמפרטורה זה גם מסוכן.

תלות ב-ActiveX בצד הדפדפן

כאן בטוח יותר להסתכל קודם ובחומרה יחסית.

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

לצורך ההחלטה נדרש גם ציר זמן. אפליקציית שולחן העבודה IE11 כבר יצאה משימוש, ומה שנשאר עומד היום הוא מצב ה-IE של Microsoft Edge. לגבי מצב ה-IE הזה, Microsoft הודיעה על מדיניות של תמיכה לפחות עד 2029, ואם יוחלט על הפסקה — הודעה מוקדמת של שנה מראש. כלומר, 2029 היא לא “עד אז אפשר להזניח”, אלא מועד שצריך לחשב אחורה כדי לסיים את ההתנתקות עד אליו. את שלבי ההתנתקות עצמם ריכזנו בנפרד ב-מדריך היציאה ממערכות Web פנימיות תלויות מצב IE.

את ה-ActiveX בצד ה-Web נכון יותר לחשוב עליו במונחי ‘מאיפה מתחילים להתנתק’ ולא ‘איך מאריכים חיים’.

flowchart TB
    accTitle: ציר הזמן של ActiveX בצד הדפדפן
    accDescr: אפליקציית שולחן העבודה IE11 יצאה משימוש, ומה שנותר הוא מצב ה-IE של Edge, ש-Microsoft מתחייבת לתמוך בו לפחות עד 2029 ולהודיע שנה מראש על הפסקה. 2029 אינו מועד שמותר להזניח עד אליו, אלא מועד שיש לחשב אחורה ממנו כדי לסיים את ההתנתקות.
    ie11["אפליקציית שולחן העבודה IE11 יצאה משימוש"] --> iem["מה שנותר הוא מצב ה-IE של Edge"]
    iem --> y2029["תמיכה לפחות עד 2029"]
    y2029 --> plan["מחשבים אחורה כדי לסיים התנתקות עד אז"]
    y2029 -.-> notice["מדיניות של הודעה שנה מראש על הפסקה"]

איור 13: 2029 אינה ארכה אלא מועד סופי. בצד הדפדפן חושבים במונחי ‘מאיפה מתחילים להתנתק’.

תלות ב-ActiveX / ‏OCX בצד שולחן העבודה

כאן אפשר להחליט בצורה מציאותית יותר.

• פועל ביציבות בתוך host קיים
• יעד ההפצה מוגבל
• יש אופק לתחזוקת ספק או תחזוקה עצמית
• ההנחות לגבי הרישום, DLL תלוי ו-bitness ידועות

אם התנאים האלה מתקיימים, החלטה להשאיר היא החלטה רגילה לגמרי.

מצד שני, אם:

• רוצים לטעון OCX של 32bit ישירות לצד 64bit
• רוצים להעביר ל-‏.NET רק את הסביבה
• ההפצה והרישום נכשלים כל פעם מחדש
• עדיין קיימת תלות בדפדפן

אז בטוח יותר לחשוב בנפרד על להשאיר / לעטוף / להחליף.

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

flowchart TB
    accTitle: איך מתפצלת ההחלטה בצד שולחן העבודה
    accDescr: אם פעולה יציבה, הפצה מוגבלת, אופק תחזוקה והנחות ידועות מתקיימים, החלטה להשאיר היא רגילה; אם יש התנגשות bitness, רצון להעביר סביבה ל-.NET, תקלות הפצה או תלות בדפדפן, מפרידים בין להשאיר, לעטוף או להחליף.
    q{"האם התנאים מתקיימים"}
    q -->|"פעולה יציבה והנחות ידועות"| keep["החלטה להשאיר היא רגילה"]
    q -->|"יש נקודות תקיעה"| split["מפרידים בין להשאיר, לעטוף או להחליף"]
    split -.-> view["איפה יוצרים גבול כמשטח חיבור"]

איור 14: בצד שולחן העבודה מפצלים לפי טמפרטורה. מה שנשאל הוא לא טוב או רע, אלא מיקום הגבול.

11. אי-הבנות נפוצות

אי-הבנה 1: COM = ActiveX

לא נכון. COM הוא הבסיס, ו-ActiveX הוא הקשר הבקר שמשמש מעליו.

אי-הבנה 2: ActiveX = Internet Explorer

לא נכון. נכון שהוא נודע בזכות ה-IE, אבל ActiveX אינה ייעודית לדפדפן.

אי-הבנה 3: ActiveX = OCX

בפועל משתמשים בהם במשמעות קרובה למדי, אבל למעשה זה לא זהה. ActiveX הוא סיפור על הקשר ורכיב, ואילו OCX הוא הישות שנתקלים בה כסיומת קובץ.

אי-הבנה 4: OCX זה סתם DLL, לא?

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

אי-הבנה 5: COM כבר טכנולוגיה מתה

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

flowchart TB
    accTitle: איך מתקנים את אי-ההבנות הנפוצות
    accDescr: COM אינו ActiveX עצמו אלא הבסיס, ActiveX אינה ייעודית ל-IE, יש הבדל בין ActiveX ל-OCX כמושג לעומת קובץ, ו-COM אינו טכנולוגיה מתה — סיכום דרך התיקון של אי-ההבנות הנפוצות.
    m1["‏COM = ActiveX ?"] --> a1["‏COM הוא הבסיס, ישות נפרדת"]
    m2["‏ActiveX = ייעודי ל-IE ?"] --> a2["פעיל גם בשולחן העבודה"]
    m3["‏ActiveX = OCX ?"] --> a3["הבדל בין מושג לקובץ"]
    m4["‏COM מת ?"] --> a4["עדיין מופיע באינטראופרביליות"]

איור 15: כל חמש אי-ההבנות נולדות מערבוב בין שכבות שונות.

12. נקודות בדיקה כשחוקרים

כשמוצאים COM / ‏ActiveX / ‏OCX, בדיקה לפי הסדר הזה מקטינה את הסיכוי להסתבך.

1. מה הרכיב הזה בכלל
   • בקר UI
   • viewer
   • אינטגרציה עם ציוד
   • אינטגרציה עם Office / ‏Access
2. איפה זה פועל
   • Access / ‏VBA
   • VB6 / ‏MFC
   • WinForms
   • IE / ‏מצב IE
3. מה הקובץ והמזהה
   • ‏.ocx / ‏.dll / ‏.exe
   • ProgID
   • CLSID
   • Type Library
4. מה מצב הרישום וההפצה
   • האם דרוש regsvr32
   • האם יש DLL תלוי
   • האם דרושות הרשאות מנהל
5. האם ה-bitness תואם
   • 32bit
   • 64bit
   • האם חייב לפעול באותו תהליך
6. איך יטפלו בזה בעתיד
   • להשאיר כמו שהוא
   • ליצור גבול ולעטוף
   • להחליף

12.1. במה בודקים

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

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

flowchart TB
    accTitle: סדר החקירה
    accDescr: בודקים לפי הסדר מה הרכיב, איפה הוא פועל, מה הקובץ והמזהה, מה מצב הרישום וההפצה, והאם ה-bitness תואם, ורק אז מחליטים בין להשאיר, לעטוף או להחליף.
    s1["בודקים מה הרכיב"] --> s2["בודקים איפה הוא פועל"]
    s2 --> s3["בוחנים קובץ ומזהה"]
    s3 --> s4["מוודאים רישום והפצה"]
    s4 --> s5["מוודאים bitness"]
    s5 --> s6["מחליטים בין להשאיר, לעטוף או להחליף"]

איור 16: לא רצים ישר למימוש חדש. ממלאים בסדר הזה, ורק אז קובעים כיוון — כך בטוח יותר.

13. סיכום

אם רוצים לומר את ההבדל בין COM / ‏ActiveX / ‏OCX בצורה הכי גסה, אבל שימושית בפועל, זה כך:

• COM הוא הבסיס
• ActiveX הוא ההקשר של רכיב מוטמע מבוסס COM
• OCX הוא קובץ נפוץ לבקר ActiveX

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

• האם זה סתם .ocx
• האם זו בעיה של כלל COM
• האם זה ActiveX תלוי דפדפן
• האם זה רכיב שאפשר להשאיר בשולחן העבודה

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

14. מקורות

• מה זה COM — למה התכנון של COM ב-Windows עדיין יפה
• איך מתייחסים היום ל-ActiveX / ‏OCX — טבלת החלטה: לשמר, לעטוף או להחליף
• מודל אובייקטי הרכיבים (COM) - Microsoft Learn
• בקרי ActiveX - Win32 apps - Microsoft Learn
• ActiveX Controls - MFC - Microsoft Learn
• ActiveX Control - Access VBA - Microsoft Learn
• מהו מצב Internet Explorer (‏IE) - Microsoft Learn
• שאלות נפוצות על מחזור החיים של IE ו-Edge - Microsoft Learn（מדיניות תמיכה במצב IE לפחות עד 2029）
• regsvr32 - פקודות Windows - Microsoft Learn
• מפתח CLSID - Win32 apps - Microsoft Learn
• Registry Redirector - Win32 apps - Microsoft Learn
• שימוש ב-DevTools במצב Internet Explorer (‏IE) - Microsoft Learn

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

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

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

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

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

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

שאלות נפוצות

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

מה זה קובץ OCX?

‏OCX הוא סיומת קובץ שנפוצה למימוש של בקרי ActiveX. אם מוצאים .ocx בשטח של Windows, אפשר בבטחה לחשוד קודם כול ברכיב COM ממשפחת הבקרים המוטמעים. הוא מופיע לרוב כתפוצה של SDK ספק, בפרויקטים ישנים של VB6 / ‏Access / ‏MFC, כקובץ שמיועד לרישום בתוך תוכנת התקנה, או כרכיב שדורש regsvr32. שווה לזכור ש-OCX הוא צורת קובץ ולא המושג עצמו — זה מקטין את הבלבול.

מה ההבדל בין COM ל-ActiveX?

‏COM הוא החוזה הבינארי שדרכו רכיבים ב-Windows מתקשרים זה עם זה — כלומר הבסיס. ActiveX הוא רכיב תוכנה לשימוש חוזר שמבוסס על COM, ולרוב מתייחסים בו בהקשר של בקר שמוטמע בתוך host או container. אם תופסים את זה כ'COM = מנגנון, ActiveX = הקשר הרכיב, OCX = קובץ' — התמונה מתבהרת. הבסיס של ActiveX הוא COM, אבל ActiveX אינו COM עצמו.

האם ActiveX היא טכנולוגיה ייעודית ל-Internet Explorer?

לא. נכון שהוא נודע בזכות ה-IE, אבל בקרי ActiveX נמצאו בשימוש ממושך גם בצד אפליקציות Windows — בטפסי Access, באפליקציות VB6, ב-container של MFC, בסביבת Office /‏ VBA, ובשימוש ב-wrapper COM מתוך WinForms. עדיף לראות בזה טכנולוגיית רכיבים מוטמעים של Windows ולא טכנולוגיה ייעודית לדפדפן. עם זאת, את התלות ב-ActiveX בצד הדפדפן, בעולם של היום נכון יותר לחשוב עליה במונחי 'מאיפה מתחילים להתנתק' ולא 'איך מאריכים את החיים'.

מה ההבדל בין OCX ל-DLL?

‏.ocx היא סיומת שמרמזת חזק למדי על היותו בקר ActiveX, אבל .dll יכולה להיות ספרייה רגילה, שרת COM, או DLL תלוי שקשור ל-ActiveX. בפועל נפוץ דפוס שבו vendorcontrol.ocx הוא הכוכב, ו-DLL כמו vendorhelper.dll תומך מהצד. אם שואלים 'האם OCX הוא סוג של DLL' — התחושה קרובה, אבל בשלב חקירה או מעבר, בטוח יותר להפריד בין התפקידים.

פרופיל הכותב

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

Go Komura

מנהל KomuraSoft LLC

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