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.) (1 người xem)

Liên hệ QC

Người dùng đang xem chủ đề này

Tôi tuân thủ nội quy khi đăng bài

phuongnam366377

Thành viên thường trực
Tham gia
25/10/19
Bài viết
214
Được thích
223
Nôi dung Bài Viết do ChatGPT biên soạn theo ý của Tôi ....--=0--=0--=0 ... 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)​


Mã:
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?
 
Lần chỉnh sửa cuối:

Tôi
1758171900940.png
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?

1758171838637.png

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?
 
Nhưng nếu biết ngôn ngữ cao này rồi liệu có dùng vba và excel nữa không anh? hay bỏ luôn
 
Nhưng nếu biết ngôn ngữ cao này rồi liệu có dùng vba và excel nữa không anh? hay bỏ luôn
Suy đoán thôi :

Windows càng ngày càng phát triển thì nó phình to ra đủ thứ xong buộc họ phải loại bỏ bớt nhưng thư viện không cần thuyết cho bên thứ ba viết và phân phôi nó tạo hệ sinh thái cho dân code két viết kiếm sống và phục phục lại công việc mà các hàm đã loại bỏ
theo chiết lý sau mà ChatGPT nó nói đúng

"Microsoft từ nhiều năm nay đi theo triết lý: những gì lõi hệ điều hành phải tinh gọn, còn hệ sinh thái mở thì để bên thứ ba phát triển."

1/ thực ra hai thư viện loại bỏ thì Fso hoàn toàn có thể viết lại là các Hàm Wrapper Từ Delphi xuất ra hay hơn nhiều lần sử dụng System.IOUtils,

2/ còn Regex thì tái sử dụng lại thư viện System.RegularExpressions viết các hàm Wrapper nó ra củng dùng tốt

Tìm trên GPE này là thấy vài năm trước viết đã viết xong mục số 1 rồi .. còn mục số hai là không bao giờ dùng cả nên ít quan tâm chắc rảnh viết xuất ra COM DLL cho cho vui

làm xong cái như Fso từ nhiều năm trước rồi viết COM DLL trên Delphi 12 nó quá đơn giản thôi sử dụng thư viện System.IOUtils, được Delphi thiết kế đa nên tảng và hiện đại trong đó có nhiều hàm đã xử lý đa luồng mặc định

Úp Cái Class chơi cho ai xem hiểu được gì thì hiểu còn không bỏ qua
Mã:
type
  TcFso = class(TAutoObject, IcFso)
  protected
    function DriveExists(const Path: OleVariant): WordBool; stdcall;
    function ChangeExtension(const Path, Extension: OleVariant)
      : OleVariant; stdcall;
    function GetDirectoryName(const FileName: OleVariant): OleVariant; stdcall;
    function GetExtension(const FileName: OleVariant): OleVariant; stdcall;
    function GetFileName(const FileName: OleVariant): OleVariant; stdcall;
    function GetFileNameWithoutExtension(const FileName: OleVariant)
      : OleVariant; stdcall;
    function GetFullPath(const Path: OleVariant): OleVariant; stdcall;
    function GetPathRoot(const Path: OleVariant): OleVariant; stdcall;
    function GetRandomFileName: OleVariant; stdcall;
    function GetTempFileName: OleVariant; stdcall;
    function GetTempPath: OleVariant; stdcall;
    function GetHomePath: OleVariant; stdcall;
    function GetDocumentsPath: OleVariant; stdcall;
    function GetSharedDocumentsPath: OleVariant; stdcall;
    function GetLibraryPath: OleVariant; stdcall;
    function GetCachePath: OleVariant; stdcall;
    function GetPublicPath: OleVariant; stdcall;
    function FileExists(const FileName: OleVariant): WordBool; stdcall;
    function FolderExists(const Directory: OleVariant): WordBool; stdcall;
    function ForceDirectories(const Dir: OleVariant): WordBool; stdcall;
    function DeleteFile(const FileName: OleVariant): WordBool; stdcall;
    function RenameFile(const OldName, NewName: OleVariant): WordBool; stdcall;
    function ExtractFilePath(const FileName: OleVariant): OleVariant; stdcall;
    function ExtractFileDir(const FileName: OleVariant): OleVariant; stdcall;
    function ExtractFileDrive(const FileName: OleVariant): OleVariant; stdcall;
    function ExtractFileName(const FileName: OleVariant): OleVariant; stdcall;
    function ExtractFileExt(const FileName: OleVariant): OleVariant; stdcall;
    function ExpandFileName(const FileName: OleVariant): OleVariant; stdcall;
    function ExtractShortPathName(const FileName: OleVariant)
      : OleVariant; stdcall;
    function GetCurrentDir: OleVariant; stdcall;
    function SetCurrentDir(const Dir: OleVariant): WordBool; stdcall;
    function CreateDir(const Dir: OleVariant): WordBool; stdcall;
    function RemoveDir(const Dir: OleVariant): WordBool; stdcall;
    function FixPath(const Value: OleVariant): OleVariant; stdcall;
    function FileIsReadOnly(const FileName: OleVariant): WordBool; stdcall;
    function ExpandUNCFileName(const FileName: OleVariant): OleVariant; stdcall;
    function FileCopy(const Source, Dest: OleVariant): WordBool; stdcall;
    function GetShortName(const sLongName: OleVariant): OleVariant; stdcall;
    function IsFileInUse(const FileName: OleVariant): WordBool; stdcall;
    function GetFileType(const FileName: OleVariant): OleVariant; stdcall;
    function GetFiles(const Dir, Extension: OleVariant; InSub: WordBool)
      : OleVariant; stdcall;
    function GetDirectoryRoot(const Dir: OleVariant): OleVariant; stdcall;
    function IsUNCPath(const Dir: OleVariant): WordBool; stdcall;
    function IsUNCRooted(const Dir: OleVariant): WordBool; stdcall;
    procedure CopyFiles(const SourceFileName, DestFileName
      : OleVariant); safecall;
    function CopyFilterListFile(const SourcePath, DestPath,
      Extension: OleVariant; InSub: WordBool): OleVariant; stdcall;

  end;


Cơ bản có hết thiếu gì thêm vào là xong
 
Lần chỉnh sửa cuối:
Cái này dùng dc nhờ a xuất dll để vọc
 
Nếu muốn sử dụng SQL trong excel, trong đó thể lấy dữ liệu từ file Excel khác mà không cần mở thì bắt buộc phải viết Add-in bằng C#/Delphi và bỏ hẳn VBA đúng không ạ?
 
Nếu muốn sử dụng SQL trong excel, trong đó thể lấy dữ liệu từ file Excel khác mà không cần mở thì bắt buộc phải viết Add-in bằng C#/Delphi và bỏ hẳn VBA đúng không ạ?
Nếu VBA thì ADODB mà dùng cho nó bình dân tìm trên GPE này đầy

Còn biết ngôn ngữ khác ngoài VBA thì tùy viết theo khả năng Vì dụ Delphi sử dụng FireDAC mà viết, còn C#, C++.............. thong thả tìm hiểu thêm

chốt lại tùy khả năng và thực tế bạn thích gì hay muốn gì xong tìm hiểu và viết
 
Nếu muốn sử dụng SQL trong excel, trong đó thể lấy dữ liệu từ file Excel khác mà không cần mở thì bắt buộc phải viết Add-in bằng C#/Delphi và bỏ hẳn VBA đúng không ạ?
Ngôn ngữ nào cũng dc, vba, python, .net, go, c++, delphi viết dll hoặc com làm dc hết bạn.
 
Viết sản phẩm trên .NET việc đầu tiên là xem bảo mật thế nào đã. Giờ AI nó hỗ trợ đến tận giường thì dễ hơn nhiều rồi nhưng tôi thấy việc bảo mật cũng mệt vì nhiều công cụ quá, với dân nghiệp dư đọc ong cả thủ :)
WinForm .NET tuy hiện đại nhưng nhiều công cụ đi kèm chưa hỗ trợ ngon lành như với Framewwork 4.8 trở xuống.
 
tại thấy GPE nhiều bài c++ quá nổi gió tôi dò c++ builder trong 1 tuần + ChatGPT thế mà viết đầy hàm ra

và cái quan trong hơn nữa là biết tái sử dụng Pascal vào C++ builder quá tốt

tự nhiên vọc chơi biết viết C++ Builder và cả thuần C++ đơn giản trên Delphi nhờ kết hợp cùng Em ChatGPT. nếu ko có ChatGPT dễ gì một tuần tôi viết

đầy hàm có điều chưa muốn úp hết lên GPE ...
 
Cái này tiện do ko phải khai trong vba còn cái khác phải khai báo
 
bà tám với Con ChatGPT nó viết như sau ...

Ok, mình sẽ liệt kê cho bạn một danh sách các thư viện COM / ActiveX cũ có khả năng bị Microsoft loại bỏ (hoặc đã trong diện deprecated) từ Windows 12 trở đi. Mình cũng ghi chú ngắn gọn lý do và gợi ý thay thế:




Các thư viện COM có nguy cơ bị loại bỏ​


1.​


  • File: vbscript.dll
  • Trạng thái: đã deprecated từ Windows 10, mặc định bị tắt từ Windows 11.
  • Lý do: Bảo mật kém, bị lợi dụng bởi malware.
  • Thay thế: PowerShell, JavaScript (Edge/Node.js), hoặc .NET.

2.​


  • File: scrrun.dll (FSO – FileSystemObject, Dictionary, TextStream, …).
  • Trạng thái: vẫn dùng được nhưng thuộc diện "legacy".
  • Thay thế:
    • System.IO trong .NET (C#, VB.NET).
    • PowerShell (Get-Item, Get-Content, Set-Content, …).
    • Trong VBA: nên chuyển qua API gốc của Office hoặc FileDialog.

3.​


  • File: jscript.dll
  • Trạng thái: có thể loại bỏ, vì Windows đã chuyển sang Chakra/Edge và giờ là V8 trong Edge Chromium.
  • Thay thế: JavaScript chạy trong Edge/Node.js.

4.​


  • File chính: wscript.exe, cscript.exe
  • Trạng thái: vẫn tồn tại nhưng Microsoft không khuyến khích.
  • Thay thế: PowerShell scripts (.ps1).

5.​


  • Ví dụ: mscomm32.ocx, comdlg32.ocx, richtx32.ocx (các control VB6).
  • Trạng thái: chỉ tồn tại để hỗ trợ ứng dụng VB6 cũ.
  • Thay thế: .NET WinForms/WPF, hoặc UI frameworks mới.

6.​


  • File: dao360.dll
  • Trạng thái: rất cũ, đã bị thay thế bằng ADO/OLEDB từ lâu.
  • Thay thế: ADO.NET hoặc ODBC driver mới.

7.​


  • File: msxml2.dll, msxml3.dll, msxml4.dll
  • Trạng thái: chỉ còn MSXML6 được khuyến nghị, các phiên bản trước có thể loại bỏ.
  • Thay thế: XML DOM trong .NET, hoặc JSON + System.Text.Json.

8.​


  • File: msado15.dll
  • Trạng thái: vẫn có, nhưng Microsoft định hướng sang ADO.NET.
  • Thay thế: ADO.NET trong .NET.

9.​


  • File: shdocvw.dll, ieframe.dll
  • Trạng thái: IE đã chết (2022), ActiveX cũng khai tử.
  • Thay thế: WebView2 (Edge Chromium).



Kết luận​


  • Nguy cơ cao bị loại bỏ hẳn: vbscript.dll, scrrun.dll, jscript.dll, wscript.exe/cscript.exe, ActiveX OCX.
  • Nguy cơ vừa: DAO, MSXML cũ, ADODB.
  • Đã chết chắc chắn: IE + các control liên quan.

Nếu bạn viết VBA / VB6 / script cũ, nên chuẩn bị chuyển đổi sang PowerShell, .NET, hoặc WebView2 để tránh bị Windows 12 chặn thẳng.



 
1758675895473.png

Vọc chơi lúc rảnh hai ngày hình thành đồ chơi .....Thời AI biến mọi cái không thể thành có thể khi lập trình
 
qua link sau thử nghiệm viết nhanh khi rảnh trong hai ngày

 
Viết sản phẩm trên .NET việc đầu tiên là xem bảo mật thế nào đã. Giờ AI nó hỗ trợ đến tận giường thì dễ hơn nhiều rồi nhưng tôi thấy việc bảo mật cũng mệt vì nhiều công cụ quá, với dân nghiệp dư đọc ong cả thủ :)
WinForm .NET tuy hiện đại nhưng nhiều công cụ đi kèm chưa hỗ trợ ngon lành như với Framewwork 4.8 trở xuống.
Học nhanh .net là ok làm fontend là đẹp oy backend nên dùng ngôn ngữ nativate
 

Bài viết mới nhất

Back
Top Bottom