我想這是你的問題： while (WaitForSingleObject(ghStopEvent, 1) == WAIT_TIMEOUT) { // Retrieve the current messaged from message queue. GetMessage(&msg, NULL, 0, 0); TranslateMessage(&msg); DispatchMessage(&msg); } 原因是，當(dāng)前您的循環(huán)可能會永遠(yuǎn)卡在GetMessage()步驟上，而不再查看manual-reset事件。 修復(fù)方法只是將WaitForSingleObject+GetMessage的組合替換為MsgWaitForMultipleObjects+PeekMessage。 您犯這個錯誤的原因是您不知道GetMessage只將發(fā)布的消息返回到消息循環(huán)。如果它找到一條已發(fā)送的消息，它將從GetMessage內(nèi)部調(diào)用處理程序，并繼續(xù)查找已發(fā)布的消息。因為您還沒有創(chuàng)建任何可以接收消息的窗口，而且您也沒有調(diào)用PostThreadMessage1，GetMessage永遠(yuǎn)不會返回。 while (MsgWaitForMultipleObjects(1, &ghStopEvent, FALSE, INFINITE, QS_ALLINPUT) > WAIT_OB

windowsapi不知道“任何文件”的內(nèi)容。所以它不能呈現(xiàn)在紙上（這就是我所理解的“打印”）。 你要么自己處理渲染，解釋文件的內(nèi)容（這是你已經(jīng)在DeviceContext和drawing中找到的那種代碼），要么把文件傳遞給一個能夠打印它的應(yīng)用程序。 對于后者，windowsapi有一個機(jī)制，宋柱在一篇評論中已經(jīng)提到了：用print命令調(diào)用ShellExecute。這通常工作正常，但并不總是因為一些應(yīng)用程序不注冊他們自己能夠打印他們的文件。 正如您在問題中提到的，還可以繞過WinApi將內(nèi)容直接發(fā)送到打印機(jī)（RAW write）。這允許應(yīng)用程序使用打印機(jī)的特定功能，而這些功能不是由其設(shè)備驅(qū)動程序處理的。使用這種方法，您的應(yīng)用程序?qū)⒏叨纫蕾囉诖蛴C(jī)型號，同時使用打印機(jī)驅(qū)動程序（DeviceContext和繪圖）使您的應(yīng)用程序（如果編寫得很好）可以在Windows支持的幾乎任何打印機(jī)上打印。

std::wstring和std::u16string之間的區(qū)別在于std::wstring使用wchar_t和std::u16string使用了char16_t，這是你自己設(shè)法弄明白的。 wchar_t不需要使用UTF-1 6編碼。例如，Linux將UTF-3 2用于wchar_t，而char16_t需要在任何地方使用UTF-1 6。 由于參數(shù)為LPCWSTR，因此該參數(shù)的預(yù)期類型為const wchar_t*，您也可以自己找到。 以A結(jié)尾的Windows函數(shù)需要char個指針，而以W結(jié)束的Windows函數(shù)則需要wchar_t個指示器。還有一些宏不以任何一個結(jié)尾，根據(jù)編譯期間是否啟用了unicode，這些宏可以擴(kuò)展到A版本或W版本。 注意：如果希望將字符串作為本機(jī)字符串類型，還可以使用std::filesystem::path::native()。 我的建議是GetFileAttributesW(inputPath.c_str());，因為c_str返回一個“本機(jī)”指針。

a） 無法避免API函數(shù)的Declare-Statement。 b） 您已經(jīng)將IsIconic-聲明定義為Private，因此它僅在該模塊中已知。如果btn_one_Click的代碼不在該模塊中，則它無法訪問該函數(shù)-但這與作為API函數(shù)無關(guān)。只需刪除Private-關(guān)鍵字，就可以從“無處不在”訪問它。 c） 正如在評論中已經(jīng)提到的，我認(rèn)為使用包裝函數(shù)隱藏API-call的細(xì)節(jié)（以及將返回的整數(shù)值轉(zhuǎn)換為布爾值）是一個好主意。 d） 在我看來，使用IsIconic(hWndAccessApp) * -1將Integer-Value1轉(zhuǎn)換為布爾值看起來很骯臟。為了避免計算布爾值，我建議使用 IsMinimized = (IsIconic(hWndAccessApp) <> 0) ' Or = 1 在幾乎所有情況下，您都應(yīng)該忘記這樣一個事實：布爾值存儲為0，而-1表示False和True。讓VBA為您執(zhí)行從1到True的轉(zhuǎn)換。

使用受限子進(jìn)程無疑是正確的方法，但是沒有一個API可以調(diào)用來實現(xiàn)這一點(diǎn)。 您可能應(yīng)該從CreateRestrictedToken開始，并盡可能地限制令牌。如果您是從頭開始設(shè)計的，您可能可以使用SaferComputeTokenFromLevel來創(chuàng)建一個SAFER_LEVELID_UNTRUSTED或更低級別的令牌，但并不是所有東西都能在這個級別上工作。 將UAC完整性級別設(shè)置為低（或更低）（TokenIntegrityLevel）。理想情況下，您可以使用AppContainer，但API中這方面的文檔并不多。Google Chrome可能這樣做是為了讓你看看他們是如何做到的。 您現(xiàn)在應(yīng)該創(chuàng)建一個作業(yè)對象，并至少使用JobObjectBasicUIRestrictions設(shè)置限制。 現(xiàn)在是時候開始用CreateProcessAsUser暫停的進(jìn)程了。 將進(jìn)程添加到作業(yè)中并恢復(fù)其執(zhí)行。 新進(jìn)程應(yīng)該做的第一件事是調(diào)用SetProcessMitigationPolicy。 你如何與孩子溝通是孩子自己的問題。也許CreateFileMapping可以創(chuàng)建一個頁面文件支持的內(nèi)存區(qū)域。使用管道或事件來控制通信。

ShowShareUIForWindow（MSDN說它需要Windows 8，但實際上它只在普通桌面應(yīng)用程序的Windows 10/11中工作）。 如何從Win32桌面應(yīng)用程序顯示共享窗格？

您鏈接到的文檔稱StructSize成員是“結(jié)構(gòu)的大小”。這意味著它是用于在內(nèi)存中存儲結(jié)構(gòu)的字節(jié)數(shù)。您可以通過在C編譯器中計算sizeof(CF_SYNC_REGISTRATION)來獲得正確的值，并且應(yīng)該在將該值傳遞給Windows API函數(shù)之前將其寫入StructSize成員。 這種情況在Windows API中很常見。我認(rèn)為這是一種機(jī)制，允許Windows偶爾向其結(jié)構(gòu)中添加新成員，而不會破壞與不知道新成員的舊代碼的兼容性。

默認(rèn)情況下，UNICODE宏是未定義的。這使得pzPname字段在定義中是CHAR pzPname[MAXPNAMELEN]。這就是錯誤產(chǎn)生的原因，因為std::wstring試圖用char數(shù)據(jù)而不是wchar_t數(shù)據(jù)初始化。 要解決這個問題，請在包含Windows.h文件之前放置一個#define UNICODE語句，或者改用std::string。

嘗試在python中加載ntdll.dll。需要Pywin32庫。 import win32processimport win32apiimport ctypesfrom ctypes import *ntdll = WinDLL("ntdll.dll")ntdll.RtlSetProcessIsCritical(1,0,0)

我不認(rèn)為WinHttpRequest依賴于Internet Explorer。即使它確實依賴于IE的某些內(nèi)部，我確信Microsoft會保留這些內(nèi)部，以保持WinHttpRequest的工作。 無論如何，WinHttpRequest仍然可以在Windows11上運(yùn)行。

我試圖獲得活躍和集中的窗口，假設(shè)這是打開標(biāo)簽，但我錯了。 Before chrome.tabs.query({ active: true, lastFocusedWindow: true }, (arrayOfTabs) => { if (arrayOfTabs.length > 0 && arrayOfTabs[0].id) { chrome.tabs?.reload(arrayOfTabs[0].id, {}); }}); After chrome.tabs.query({ active: true, windowType: "normal" }, (arrayOfTabs) => { if (arrayOfTabs.length > 0 && arrayOfTabs[0].id) { chrome.tabs?.reload(arrayOfTabs[0].id, {}); }}); 這樣我就可以得到開場白標(biāo)簽。正如@wOxxOm在一篇評論中提到的，無論窗口如何，標(biāo)簽都會被識別出來，這都是關(guān)于我使用的查詢。

你可以看看這個庫：https://github.com/dahall/Vanara/它提供了P/Invoke。 他們是這樣實施的： [DllImport(Lib.Kernel32, SetLastError = false, ExactSpelling = true, CharSet = CharSet.Unicode)]public static extern long GetPackagesByPackageFamily(string packageFamilyName, ref uint count, [Out, MarshalAs(UnmanagedType.LPArray, ArraySubType = UnmanagedType.LPWStr, SizeParamIndex = 1)] string[] packageFullNames, ref uint bufferLength, IntPtr buffer); （見此處https://github.com/dahall/Vanara/blob/3f64f6d9d4c963070e31823ca8a720068ac07fe2/PInvoke/Kernel32/AppModel.cs）

您如何實際使用Microsoft Windows API中的接口？ 這很簡單：您獲取一個指向接口的指針，然后開始使用它。完成后，您Release()它。簡而言之，這就是COM。 那么更難的問題是：你如何真正掌握COM接口指針？本質(zhì)上，有兩種方法可以做到這一點(diǎn)： 調(diào)用通過接口指針提供COM對象的工廠函數(shù)。“標(biāo)準(zhǔn)”方式是調(diào)用CoCreateInstance。不太“標(biāo)準(zhǔn)”（盡管越來越常見）的方法是調(diào)用專用工廠函數(shù)。例如，要獲得IPropertyStorage接口，可以調(diào)用StgCreatePropStg（或類似的）。這解決了使用系統(tǒng)（或庫）提供給客戶端使用的COM接口的用例。 實現(xiàn)接口，并使用您認(rèn)為合適的任何方法來實例化此具體實現(xiàn)。當(dāng)使用COM-capable C++編譯器（如MSVC）時，這相當(dāng)于為從接口派生的類提供了一個實現(xiàn)。這對于您需要編寫界面的情況非常有用，通常由其他人使用。示例包括IStream或IEnumString。問題中要求的接口并非如此。

基本W(wǎng)indows ABI是穩(wěn)定的，與COM兼容。如果編譯器支持COM，它也支持基本API，在x86上，它們都是stdcall函數(shù)。 由于許多原因，將所有內(nèi)容公開為COM接口是沒有意義的。 Windows 95的最低要求是4 MiB RAM和COM，所有這些都會使注冊表膨脹過多。COM對象的每個實例也需要內(nèi)存，而作為函數(shù)調(diào)用只需要一點(diǎn)點(diǎn)堆棧空間。 COM方法調(diào)用速度較慢。V-table查找和一個額外的函數(shù)參數(shù)。浪費(fèi)時間打電話給CoCreateInstance太多了。無意義的引用計數(shù)開銷。 Low-level像CreateFile和CreateProcess這樣的東西只能由Microsoft實現(xiàn)，并且3rd-party軟件提供/覆蓋low-level函數(shù)的實現(xiàn)沒有任何意義。 唯一的積極因素是high-level腳本代碼可以調(diào)用這些函數(shù)，但實際上大多數(shù)COM接口都不是雙重的，不支持IDispatch，因此無法編寫腳本。例外情況是Internet Explorer、Office和一些shell工具（shell.Application）。 對于可擴(kuò)展或運(yùn)行out-of-process的東西，COM很有意義。很容易定義接口，IPC為您提供服務(wù)。 隨著UWP/WinRT的引入，您在某種程度上實現(xiàn)了自己的愿望。。。

當(dāng)然有，它被命名為“控制臺API”。 有關(guān)Windows控制臺功能的文檔以 使用控制臺API 它有相當(dāng)多的例子以及每個控制臺API函數(shù)的文檔