Hết thời scrrun.dll & vbscript.dll: Chuẩn bị chuyển sang giải pháp hiện đại (Delphi 12, .NET, C++, v.v.) (4 người xem)

[phuongnam366377]

Nôi dung Bài Viết do ChatGPT biên soạn theo ý của Tôi .... ... xin mời vào đây bà tám và bàn luận

Hết thời​

Tóm tắt: Microsoft đã “dọn dẹp” và không còn ưu tiên duy trì scrrun.dll (Scripting Runtime) và vbscript.dll (VBScript.RegExp). Những thư viện này làm tốt nhiệm vụ ở thời VB5/VB6, nhưng hiện đã lỗi thời, tiềm ẩn rủi ro bảo mật và không phù hợp cho các ứng dụng dài hạn. Thay vì bám víu vào chúng, đây là lúc cộng đồng và bên thứ ba tạo ra các DLL/COM/ADD-IN hiện đại — ví dụ: COM DLL viết bằng Delphi 12, .NET, hoặc C++ — để thay thế toàn diện chức năng Regex + FileSystem và hơn thế nữa.

---

Vì sao nên “khai tử”​

• Cổ lỗ sĩ: Thiết kế từ cuối thập niên 90 — không hỗ trợ các tính năng hiện đại (ví dụ regex nâng cao, Unicode full, performance tuning).
• Không được cập nhật: Microsoft đã deprecate VBScript; các bản vá/tiện ích mới sẽ không ưu tiên cho những thư viện này.
• Rủi ro bảo mật: Script runtime từng là vector cho nhiều lỗ hổng (CVE). Giảm diện tích tấn công là hợp lý.
• Không linh hoạt: Kiến trúc COM cũ, khó tích hợp vào hệ sinh thái hiện đại (xử lý 64-bit, async, multi-thread).
• Giam chân sáng tạo: Khó mở rộng cho tính năng mới; phải phụ thuộc Microsoft để sửa lỗi.

---

Ảnh hưởng với hệ sinh thái VBA / Office​

• Code cũ dùng Scripting.Dictionary, FileSystemObject, TextStream, VBScript.RegExp có thể vận hành kém ổn định trên Windows/Office đời mới.
• Người dùng cuối có thể gặp lỗi “ActiveX component can’t create object” khi Windows không còn đăng ký các DLL này.
• Các dự án lâu dài nên tránh phụ thuộc vào scrrun.dll/vbscript.dll.

---

Xu hướng thay thế (đúng — và bền)​

1. COM DLL do bên thứ ba / team nội bộ phát triển
   • Viết wrapper hiện đại cung cấp: Regex, FileSystem, Dictionary, IO…
   • Ngôn ngữ: Delphi 12, C++ (WinAPI/PCRE2), C# (.NET COM Interop).
   • Lợi ích: tương thích VBA qua CreateObject, hỗ trợ 64-bit, kiểm soát được security và updates.
2. Add-in / XLL / XLAM cho Excel
   • Bao gói chức năng dưới dạng add-in → dễ triển khai, cập nhật và phân phối.
3. Dùng .NET qua COM Interop hoặc .NET 6/7/8 hosting
   • Regex mạnh mẽ (System.Text.RegularExpressions), thao tác file hiện đại, async IO.
4. Thư viện native (C/C++)
   • Hiệu năng cao, dễ đóng gói cho môi trường enterprise.

---

Tại sao​

• Delphi 12 (RAD Studio) hỗ trợ nhanh cho việc tạo COM servers, build cho Win64 dễ dàng.
• Thư viện chuẩn cung cấp TFile, TDirectory, TPath và các thư viện regex mạnh (PCRE).
• Dễ wrap các API thành class COM (TComObject, TAutoObject) để VBA gọi bằng CreateObject("Vendor.Regex").
• Triển khai nhanh, footprint nhẹ, phù hợp cho dev chuyên nghiệp quen Windows-native.

---

Mẫu kiến trúc (ý tưởng) cho một “Modern Scripting Runtime”​

Thư viện: ModernScripting.dll

• MyRegex (COM class)
  • IsMatch(pattern As WideString, input As WideString) As Boolean
  • Match(pattern, input) As Variant (trả về array/collection)
  • Replace(pattern, input, repl) As WideString
  • Split(pattern, input) As Variant
• MyFileSystem (COM class)
  • ReadAllText(path As WideString) As WideString
  • WriteAllText(path, content, overwrite As Boolean)
  • GetFiles(path, mask, recursive As Boolean) As Variant
  • FileExists(path) As Boolean, CreateFolder(path), DeleteFile(path)
• MyDictionary (COM class) — optional: hash map hiện đại

API design notes:

• Dùng BSTR/WideString cho Unicode.
• Trả SAFEARRAY(VARIANT) cho danh sách/collection để dễ dùng trong VBA.
• Cung cấp cả method sync + (nếu cần) async callback / event.

---

Ví dụ ngắn: cách VBA sẽ dùng (sau khi bạn build DLL)​

Dim rx As Object, fs As Object
Set rx = CreateObject("ModernScripting.MyRegex")
Set fs = CreateObject("ModernScripting.MyFileSystem")

If rx.IsMatch("\b\d{4}\b", "Mã: 2025") Then
    MsgBox "Tìm thấy 4 chữ số!"
End If

Dim content As String
content = fs.ReadAllText("D:\logs\sample.txt")
MsgBox Left(content, 120)

---

Lộ trình di chuyển nhanh (practical migration roadmap)​

1. Inventory: liệt kê toàn bộ chỗ dùng Scripting.* và RegExp.
2. Phân loại: đơn giản (InStr/Split/Like đủ), phức tạp (regex nâng cao, tệp lớn).
3. Ưu tiên thay thế:
   • Ngay: Replace RegExp bằng wrapper .NET/Delphi.
   • Trung hạn: chuyển FSO → MyFileSystem (Delphi/WinAPI).
   • Dài hạn: thay Dictionary bằng MyDictionary hoặc TCollections custom.
4. Xây dựng wrapper: tạo COM DLL (Delphi 12) với interface rõ ràng.
5. Chạy thử & roll-out: deploy DLL, test trên môi trường 32/64-bit, đóng gói installer.
6. Tài liệu & mẫu: viết guide cho dev dùng API mới, cung cấp polyfills cho legacy.

---

Lợi ích khi xây dựng hệ sinh thái bên thứ ba​

• Chủ động: bạn tự fix, nâng cấp, support theo nhu cầu.
• Bảo mật: giảm lỗ hổng do code cũ; có thể áp chính sách update nhanh.
• Tính năng: hỗ trợ regex hiện đại, Unicode, xử lý file nhanh, multi-threading…
• Tương lai: không phụ thuộc Microsoft; dễ port khi Office/Windows tiếp tục thay đổi.

---

Kết luận & kêu gọi hành động​

Scripting Runtime và VBScript.RegExp từng rất hữu ích — nhưng đã đến lúc loại bỏ những thư viện “ọp ẹp” để nhường chỗ cho giải pháp hiện đại, an toàn và mở rộng. Nếu bạn là dev VBA/IT admin/team dev nội bộ, hãy:

• Không trì hoãn việc lên lộ trình thay thế scrrun.dll/vbscript.dll.
• Xây dựng hoặc chọn một COM DLL/ADD-IN hiện đại (Delphi 12 là một lựa chọn xuất sắc).
• Chuẩn hoá API để giảm chi phí bảo trì trong tổ chức.

---

Nếu bạn muốn, mình có thể tiếp tục và viết bài chi tiết hơn (bản web-ready HTML + meta, hoặc bản tiếng Việt/Anh chuẩn SEO), hoặc soạn mẫu project Delphi 12 (skeleton code) cho MyRegex + MyFileSystem để bạn bắt tay vào xây dựng luôn. Bạn muốn mình làm hướng nào tiếp theo?

 

[phuongnam366377]

GitHub - jpbro/VbPcre2: PCRE2 Wrapper for VB6

PCRE2 Wrapper for VB6. Contribute to jpbro/VbPcre2 development by creating an account on GitHub.

github.com

Tôi

Bạn nói rất đúng, đây là “cái bẫy” mà nhiều người không để ý

• VbPcre2 gốc là DLL ActiveX 32-bit viết cho VB6.
• Khi đưa sang VBA (Office), nhất là Office 64-bit, thì:
  
  • Phải chạy trong chế độ 32-bit (cực kỳ hạn chế).
  • Hoặc phải build lại wrapper 64-bit → phức tạp.
• Bản thân VBA runtime vốn đã chậm (thao tác chuỗi, lặp, collection). Nếu lại ôm thêm cả lớp wrapper + module VB6 thì khác gì… đeo thêm cục gạch

Kết quả:

• Regex gọi qua COM trung gian bị overhead.
• Trộn với macro Excel (vốn chậm hơn .NET/C++ nhiều lần) thì chạy càng ì ạch.
• Khó triển khai trên nhiều máy, vì phải đăng ký DLL bằng regsvr32, phân biệt 32/64-bit → thêm việc, thêm lỗi.

---

So sánh hướng đi​

1. Ôm DLL cũ (VbPcre2, scrrun.dll, vbscript.dll)​

• Nhanh có regex trong VBA.
• Giới hạn 32-bit.
• VBA overhead lớn, càng chậm.
• Deployment rắc rối, dễ lỗi ActiveX.
• Không future-proof (Windows 12 có thể bỏ hẳn).

2. Viết mới DLL bằng​

• Native 64-bit, hiệu suất cao.
• Toàn quyền mở rộng (Regex hiện đại, Unicode full, async IO).
• Gọn, chỉ expose COM class tối thiểu.
• Triển khai dễ hơn, chỉ 1 DLL bạn kiểm soát.
• Phải tốn công build & maintain (nhưng lâu dài rất xứng đáng).

---

Giống như bạn nói: ôm lại rác rưởi cũ (class + module VB6) thì chỉ làm VBA thêm chậm và rối. Đúng hướng là:

• VBA chỉ làm giao diện gọi DLL.
• Toàn bộ xử lý nặng (Regex, File IO, HashMap, JSON…) chạy trong DLL native (Delphi/C++/.NET).

Khi đó, VBA = mặt nạ mỏng cho Excel, còn “bộ não” nằm trong DLL.

---

Bạn có muốn mình viết mẫu Delphi 12 COM DLL cực gọn (1 class Regex, 1 class FileSystem), để bạn thấy rõ cách mà Excel chỉ cần CreateObject("MyRegex") là chạy, không phải ôm thêm code VB6/VBA nặng nề không?



ChatGPT

Chuẩn luôn, bạn thấy rất đúng vấn đề.
Cộng đồng VB6/VBA có hai “trường phái”:

1. Ôm lại mớ Class + Module VB6/VBA
   • Họ convert code C/PCRE sang VBA class/module, rồi copy vào project Excel.
   • Nghe thì “portable” vì không cần DLL ngoài, chạy được trên 64-bit Excel.
   • Nhưng thực tế:
     • Chậm kinh khủng: VBA không sinh mã máy, chỉ chạy interpreter. Regex mà chạy bằng vòng lặp + chuỗi trong VBA thì CPU “khóc thét”.
     • Cồng kềnh: Excel file to phình ra, bảo trì khó, dễ lỗi runtime.
     • Không thực tế với dữ liệu lớn (ngay cả vài MB text cũng ngắc ngoải).
   Nói nôm na: ôm rác rưởi vào Excel để có “cái gọi là regex 64-bit” nhưng hiệu năng thì tệ hơn cả VBScript.RegExp ngày xưa.

---

1. Làm đúng cách: DLL/COM 64-bit bên ngoài
   • Viết COM DLL (Delphi 12, C++17/23, hoặc .NET 6/7/8).
   • Expose một interface rất mỏng: Regex.IsMatch, Regex.Replace, FileSystem.ReadAllText…
   • VBA chỉ cần CreateObject("MyRegex").
   • Toàn bộ xử lý chạy native 64-bit → nhanh, gọn, ổn định.
   Đây mới là giải pháp chuyên nghiệp: Excel chỉ làm front-end, còn “não” nằm ngoài.

---

Tóm lại:

• Viết lại regex bằng Class/Module trong VBA = “tái chế rác”, chạy chậm, tốn RAM, dễ crash.
• Viết DLL ngoài bằng Delphi/C++/.NET = “nâng cấp hệ thống”, chạy native, an toàn, kiểm soát hoàn toàn.

---

Bạn có muốn mình demo ngay một skeleton DLL Delphi 12 (64-bit COM) với class Regex (gọi PCRE) để bạn thấy nó chỉ vài chục dòng code mà chạy nhanh gấp trăm lần cái mớ VBA class/module không? Chuẩn luôn, bạn thấy rất đúng vấn đề.


Cộng đồng VB6/VBA có hai “trường phái”:

1. Ôm lại mớ Class + Module VB6/VBA
   
   • Họ convert code C/PCRE sang VBA class/module, rồi copy vào project Excel.
   • Nghe thì “portable” vì không cần DLL ngoài, chạy được trên 64-bit Excel.
   • Nhưng thực tế:
     
     • Chậm kinh khủng: VBA không sinh mã máy, chỉ chạy interpreter. Regex mà chạy bằng vòng lặp + chuỗi trong VBA thì CPU “khóc thét”.
     • Cồng kềnh: Excel file to phình ra, bảo trì khó, dễ lỗi runtime.
     • Không thực tế với dữ liệu lớn (ngay cả vài MB text cũng ngắc ngoải).
     Nói nôm na: ôm rác rưởi vào Excel để có “cái gọi là regex 64-bit” nhưng hiệu năng thì tệ hơn cả VBScript.RegExp ngày xưa.

---

1. Làm đúng cách: DLL/COM 64-bit bên ngoài
   
   • Viết COM DLL (Delphi 12, C++17/23, hoặc .NET 6/7/8).
   • Expose một interface rất mỏng: Regex.IsMatch, Regex.Replace, FileSystem.ReadAllText…
   • VBA chỉ cần CreateObject("MyRegex").
   • Toàn bộ xử lý chạy native 64-bit → nhanh, gọn, ổn định.
     Đây mới là giải pháp chuyên nghiệp: Excel chỉ làm front-end, còn “não” nằm ngoài.

---

Tóm lại:

• Viết lại regex bằng Class/Module trong VBA = “tái chế rác”, chạy chậm, tốn RAM, dễ crash.
• Viết DLL ngoài bằng Delphi/C++/.NET = “nâng cấp hệ thống”, chạy native, an toàn, kiểm soát hoàn toàn.

---

Bạn có muốn mình demo ngay một skeleton DLL Delphi 12 (64-bit COM) với class Regex (gọi PCRE) để bạn thấy nó chỉ vài chục dòng code mà chạy nhanh gấp trăm lần cái mớ VBA class/module không?