API Windows được thiết kế cho C, mà vẫn là ngôn ngữ được sử dụng nhiều nhất cho lập trình hệ thống; C API là tiêu chuẩn thực tế cho các API hệ thống và cho hầu hết các ngôn ngữ khác có và có một số cách gọi các hàm C bên ngoài, vì vậy việc viết C API giúp tương thích với các ngôn ngữ khác.
API C chỉ cần một ABI đơn giản, bao gồm gần như chỉ định nghĩa cho quy ước gọi để sử dụng cho các hàm (và một cái gì đó về bố cục cấu trúc). C++ và các ngôn ngữ hướng đối tượng khác, ngược lại, yêu cầu ABI phức tạp, phải xác định cách đối tượng được đặt trong bộ nhớ, cách xử lý thừa kế, cách bố trí vtable, cách truyền các ngoại lệ, nơi đặt dữ liệu RTTI, ... Hơn nữa không phải tất cả các ngôn ngữ đều hướng đối tượng và sử dụng API cho C++ với các ngôn ngữ không hướng đối tượng khác có thể là một nỗi đau thực sự (nếu bạn đã từng sử dụng COM từ C bạn biết ý tôi là gì). Ngoài ra, khi Windows được thiết kế ban đầu thì C++ không được phổ biến rộng rãi trên PC, và C cũng không được sử dụng vì vậy nhiều: thực tế, một phần lớn của Windows 3.11 và nhiều ứng dụng vẫn được viết trong assembly , vì bộ nhớ và các ràng buộc CPU ở thời đại rất chặt chẽ; các trình biên dịch cũng kém thông minh hơn bây giờ, đặc biệt là các trình soạn thảo C++. Trên những máy có lắp ráp bằng tay thường là giải pháp duy nhất, chi phí C++ thực sự không thể chấp nhận được.
Đối với điều con trỏ: API Windows sử dụng hầu như luôn luôn xử lý, tức là con trỏ đục để có thể thay đổi bản chất cơ bản của mọi tài nguyên mà không ảnh hưởng đến các ứng dụng hiện có và dừng ứng dụng. Nó không quan trọng nếu cấu trúc được sử dụng bởi người quản lý cửa sổ để đại diện cho một cửa sổ nội bộ được thay đổi: tất cả các ứng dụng sử dụng chỉ đơn giản là một HWND, mà luôn luôn là kích thước của một con trỏ. Bạn có thể nghĩ đây là một dạng thành ngữ PIMPL. Tuy nhiên, Windows là một cách nào đó hướng đối tượng (xem ví dụ toàn bộ khái niệm "cửa sổ lớp", hoặc, ở một mức độ sâu hơn, làm việc bên trong của hạt nhân NT, mà là rất nhiều dựa trên "đối tượng" khái niệm), tuy nhiên các API cơ bản nhất của nó, là các hàm C đơn giản, bằng cách nào đó ẩn bản chất OO này. Shell, ở phía bên kia, được thiết kế nhiều năm sau, được viết chủ yếu bằng C++ và nó cung cấp một giao diện COM thực sự hướng đối tượng. Một điều thú vị là bạn có thể thấy trong COM tất cả các sự cân bằng mà bạn phải đối mặt trong việc xây dựng một giao diện hướng đối tượng nhưng vẫn là C++, kết quả khá phức tạp, ở một số khía cạnh xấu xí và không thực sự dễ sử dụng bất kỳ ngôn ngữ nào. Các API Windows, thay vào đó, là các hàm đơn giản thường dễ gọi hơn.
Nếu bạn quan tâm đến một hệ thống dựa trên API C++, bạn có thể xem Haiku; cá nhân, đây là một trong những khía cạnh vì tôi khá quan tâm đến dự án đó.
Nhân tiện, nếu bạn định lập trình Win32 chỉ với các API, bạn nên có được một cuốn sách tốt để làm quen với các "đặc điểm" này và các thành ngữ Win32 khác. Hai cái nổi tiếng là Rector-Newcomer và Petzhold.
cảm ơn. từ tất cả các câu trả lời. nó có ý nghĩa hơn bây giờ. – numerical25
Giải thích tuyệt vời. Một câu hỏi mặc dù: nếu Win32 thực sự là đối tượng định hướng, tại sao nó rất khó để có được một con trỏ dụ trong một chức năng WndProc (cho là trái tim của toàn bộ API)? (xem http://www.codeguru.com/forum/printthread.php?t=234315) –
@Jared: bản chất hướng đối tượng nhiều hơn hoặc ít hơn của API Win32 là một khái niệm không có gì để làm với hệ thống kiểu C++. Các lớp cửa sổ là một khái niệm về trình quản lý cửa sổ, không phải của ngôn ngữ cụ thể mà bạn đang sử dụng để truy cập các tính năng WM. Bạn có thể tạo một sự tương ứng giữa các lớp/đối tượng C++ với các lớp/trường hợp cửa sổ, nhưng theo nguyên tắc chúng là những thứ hoàn toàn không liên quan. –