我现在要仔细看一下这个Delphi代码，看看有没有什么问题。首先，这个程序的主要功能是在系统关机或重启时保存应用程序的状态，特别是资源管理器的路径和打开的应用程序及其文件信息，然后在下次启动时加载这些状态。
首先看uses部分，里面包含了SHDocVw、Windows等单元，这些都是处理窗口、系统进程、COM对象等需要的单元，看起来没问题。接着定义了一个TForm1类，里面有几个方法，包括FormCreate、FormDestroy，以及处理WM_QUERYENDSESSION消息的方法。私有方法里有保存和加载应用状态的函数，还有获取资源管理器路径和应用程序列表的函数。
接下来是GetExplorerPaths函数，用来获取所有打开的Explorer窗口的路径。这里使用了IShellWindows接口遍历所有Shell窗口，然后获取它们的路径。不过这里有一个疑问，如果用户打开的是库或者其他特殊文件夹，SHGetPathFromIDList是否能正确获取路径呢？可能在某些情况下会失败，可能需要处理异常或者检查返回值。另外，代码中CoInitialize和CoUninitialize是否正确配对？在函数内部调用了CoInitialize，然后try...finally里CoUninitialize。但Delphi中的COM对象通常在主线程已经初始化了COM库，比如通过Application.Initialize，所以在函数里再次初始化会不会有问题？比如可能已经初始化过，再次调用CoInitialize可能会返回S_FALSE，但这里可能没问题，因为每个线程需要自己初始化。不过在这个函数里，应该是在主线程调用的，可能不需要再初始化，反而可能引起问题。需要检查CoInitialize的调用是否必要，或者是否应该使用CoInitializeEx等更合适的函数。
然后是GetApplicationsWithFiles函数，这里试图获取所有顶层可见窗口，然后通过进程ID获取进程的可执行文件路径。这里用了GetTopWindow和GetNextWindow遍历所有窗口，然后过滤掉系统进程。不过这里有一个问题，系统路径的判断是否正确？例如，系统进程可能不在System32目录下，比如SysWOW64中的进程，或者某些服务进程可能在别的位置。另外，获取进程路径时，是否应该使用更可靠的方法？比如使用QueryFullProcessImageName函数，因为GetModuleFileNameEx在某些情况下可能无法获取64位进程的路径，如果当前程序是32位的话。此外，代码中在过滤系统进程时，用了ExtractFilePath(modName)和sysPath比较，但modName可能包含不同的路径格式，比如长路径和短路径，或者大小写不同，所以用SameText是否正确？比如，系统路径可能是C:\Windows\System32\，而modName可能返回的是c:\windows\system32\，这时候SameText是正确的。不过这里可能还是会有漏掉的情况，比如其他系统目录下的进程，比如C:\Windows\SysWOW64\，或者驱动进程等。
在SaveApplicationState方法中，创建了TIniFile实例，然后保存应用程序和资源管理器的路径。这里可能存在路径过长的问题吗？INI文件通常对键值长度有限制，但一般来说不太可能超过。另外，保存资源管理器的路径时，键名是Path加序号，比如Path0、Path1等，读取时没有问题。但是如果有多个Explorer窗口，保存的顺序是否会影响恢复时的顺序？恢复的时候可能需要按顺序打开，但代码里只是简单保存和读取，可能没问题。
在WMQueryEndSession方法中，调用了SaveApplicationState，然后继承处理。这里是否正确处理了关机消息？根据Delphi的消息处理机制，调用inherited会调用默认的消息处理，但WM_QUERYENDSESSION需要返回Result := 1来表示允许关机。代码中在inherited之后设置了Message.Result := 1，但可能inherited的处理会覆盖这个值？需要确认Delphi中TForm的默认处理是怎样的。可能正确的做法是在处理完保存之后，直接设置Message.Result := 1，而不调用inherited，或者确保inherited之后不影响结果。例如，可能应该先调用inherited，然后再设置Result，或者反过来？
在LoadApplicationState方法中，读取INI文件并显示信息，这里用了ShowMessage来显示每个应用程序和路径，可能在实际使用中需要改为实际启动这些应用程序和打开资源管理器窗口。当前的代码只是演示加载，但没有实际恢复应用状态的功能。用户可能需要根据保存的信息启动对应的程序，并打开文件或路径。
另外，程序在FormCreate时加载状态，FormDestroy时保存状态。但正常关机时，FormDestroy可能不会被调用，因为应用程序可能被系统直接终止。因此，依赖FormDestroy来保存可能不可靠，这也是为什么在WM_QUERYENDSESSION消息中显式调用SaveApplicationState的原因。这部分逻辑是合理的。
现在看可能的错误点：
1. 在GetExplorerPaths函数中，获取IShellBrowser和IShellFolderView可能存在问题。例如，某些Shell窗口可能不支持这些接口，导致QueryInterface失败，但代码中使用了Succeeded来检查，因此不会崩溃，但可能无法获取所有Explorer窗口的路径。此外，代码中使用了SVGIO_BACKGROUND和获取IPersistFolder2的方式是否正确？可能应该使用不同的方法来获取当前路径，比如通过获取IShellFolderView接口的Folder对象，然后获取路径。
2. 在GetApplicationsWithFiles中，遍历窗口时，可能获取到一些非文件相关的应用程序，比如浏览器、聊天软件等，这些程序可能没有打开文件，但会被记录。而代码中的逻辑是将所有可见窗口的进程的可执行文件名作为键，窗口标题作为值保存。这样在恢复时，可能无法准确重新打开这些应用程序的文件，因为标题可能不包含文件路径。例如，记事本如果打开了文件，标题是“文件名 - 记事本”，但代码只是保存了标题，而没有解析出具体的文件路径。因此，这部分逻辑可能无法正确获取到应用程序打开的文件信息，导致恢复时无法重新打开文件。
3. 在保存应用程序时，使用TIniFile.WriteString，键是应用程序的文件名（比如notepad.exe），值是该窗口的标题。但如果有多个同一应用程序的实例（比如多个记事本窗口），后面的实例会覆盖前面的，因为键是相同的。这会导致只能保存最后一个实例的信息，前面的会被覆盖。因此，应该如何处理多个实例的情况？可能需要用不同的键，比如包含进程ID或其他唯一标识符，但进程ID在下次启动时会变化，所以不可行。或者将值存储为列表，但INI文件的结构可能不支持，需要用到不同的节或者格式。
4. 在获取进程路径时，如果进程是UWP应用（如Windows 10/11的现代应用），GetModuleFileNameEx可能无法正确获取路径，或者路径不存在，导致保存错误的信息。这时候可能需要不同的方法来处理UWP应用，但代码中没有考虑这一点。
5. 在资源管理器路径获取中，如果用户打开的是库（如文档、图片等），SHGetPathFromIDList可能无法正确转换为文件系统路径，返回空或错误路径。例如，库的路径是虚拟的，实际对应的可能是多个文件夹。此时保存的路径可能无效，恢复时无法正确打开。
6. 在WM_QUERYENDSESSION处理中，系统可能只给应用程序有限的时间来保存状态，如果保存过程耗时较长，可能导致系统终止应用程序，导致数据未完全保存。需要确保SaveApplicationState的执行速度足够快，或者使用异步方式保存，但代码中是同步操作，可能存在风险。
7. 在加载应用程序状态时，只是用ShowMessage显示信息，而没有实际启动应用程序和打开文件或路径，所以程序目前的功能不完整，无法真正恢复状态。
8. 在GetExplorerPaths函数中，CoInitialize和CoUninitialize的调用是否正确？如果主线程已经初始化了COM库（比如通过Application.Initialize），在这里再次调用CoInitialize可能会增加引用计数，但最终调用CoUninitialize会减少，可能导致主线程的COM库被意外卸载。正确的方法应该是确保COM库在主线程正确初始化和释放，而不在函数内部进行。例如，在Delphi的Forms单元中，Application对象可能在初始化时已经调用了CoInitialize，因此在这里再次调用可能会导致问题，比如返回S_FALSE，但多次调用CoInitialize是允许的，只要每个CoInitialize对应一个CoUninitialize。然而，如果在多线程环境下可能会有问题，但这里应该是在主线程执行的，所以可能不会有问题。不过，这种在函数内部初始化和释放COM的方式可能不太推荐，更好的做法是依赖主线程已经初始化的COM状态，并且不在函数内调用CoInitialize/CoUninitialize。或者改为使用CoInitializeEx并检查返回值，处理不同的情况。
9. 在GetExplorerPaths函数中，使用ShellWindows.Item(i).QueryInterface(IShellBrowser, ShellBrowser)是否正确？IShellBrowser接口是否适用于所有Shell窗口？可能某些窗口（如IE浏览器窗口）也会被枚举到，导致获取到非资源管理器窗口的路径。例如，SHDocVw中的IShellWindows会包括IE的窗口，所以需要进一步判断窗口的类型，是否是资源管理器的窗口。例如，检查窗口的NameSpace属性或者其它标识，确保只处理Explorer的实例。
10. 在GetExplorerPaths中，处理PIDL后是否正确释放了内存？代码中调用CoTaskMemFree(PIDL)是正确的，因为SHGetPathFromIDList的参数需要释放。
可能的改进点：
- 在获取Explorer路径时，过滤掉非文件系统的路径，或者处理虚拟文件夹的情况。
- 在保存应用程序时，处理多实例的情况，避免键名冲突。
- 使用更可靠的方法获取进程的可执行文件路径，特别是对于64位进程和UWP应用。
- 在恢复应用状态时，实际启动应用程序并打开相应的文件或路径，而不是仅显示消息。
- 处理可能出现的异常，例如在访问进程或窗口时可能出现的权限问题，或者进程已终止的情况。
- 在WM_QUERYENDSESSION处理中，确保尽快完成保存操作，避免超时。
- 考虑使用更可靠的方法来获取应用程序打开的文件，例如通过窗口标题解析文件名，或者使用更高级的API（如ITaskbarList等）。
现在针对代码中的错误，可能的实际错误包括：
1. **在GetExplorerPaths中，未能正确获取所有资源管理器窗口的路径**：因为IShellWindows可能包括IE或其他Shell窗口，而不仅仅是资源管理器。这会导致保存的路径包含非资源管理器窗口的信息。需要进一步过滤，只处理资源管理器的实例。
例如，可以检查窗口的NameSpace是否为文件夹，或者检查应用程序的类名是否为“CabinetWClass”（资源管理器窗口的类名）。
2. **在GetApplicationsWithFiles中，无法正确获取进程路径的问题**：当程序是64位而当前程序是32位时，使用GetModuleFileNameEx可能无法获取64位进程的正确路径。此时应改用QueryFullProcessImageName函数，该函数在Vista及更高版本中可用，并且可以正确处理跨架构的进程路径。
3. **在保存应用程序时，多个实例被覆盖的问题**：使用进程文件名作为键名，导致多个实例只能保存最后一个。应该使用不同的键结构，例如将进程ID包含进去，或者使用节中的多个条目。
4. **资源管理器的路径保存为顺序键可能导致恢复顺序混乱**：如果用户有多个资源管理器窗口，按什么顺序保存和恢复可能会影响用户体验。但通常恢复时按任意顺序打开可能问题不大。
5. **在GetExplorerPaths中的COM初始化问题**：主线程可能已经初始化了COM，函数中再次初始化可能导致引用计数增加，但这里可能不会有问题，因为每次CoInitialize都对应一个CoUninitialize。不过更安全的方法是不在函数内部调用CoInitialize，而是假设主线程已经初始化了COM为STA模式。
6. **在WMQueryEndSession中，调用inherited后设置Message.Result是否正确**：默认情况下，TForm处理WM_QUERYENDSESSION可能不会设置Result，但需要确保在消息处理后Result被正确设置为1，以允许系统关机。正确的做法可能是直接设置Message.Result := 1而不调用inherited，或者确认调用inherited不会覆盖该值。
例如，查看VCL的TForm的WMQueryEndSession处理，可能默认调用DefWindowProc，其返回值取决于是否处理了消息。为了确保返回1，应该在处理完后设置Message.Result := 1，并且可能不需要调用inherited。或者调用inherited之后，再设置Result为1，以确保覆盖默认的返回值。
例如：
procedure TForm1.WMQueryEndSession(var Message: TWMQueryEndSession);
begin
SaveApplicationState;
Message.Result := 1; // 允许关机
// inherited; // 可能不需要调用，因为父类处理可能不设置Result
end;
因为如果调用inherited，父类可能会处理消息并设置Result为0或其他值，导致系统无法正常关机。因此，正确的做法可能是不调用inherited，直接设置Result := 1。
总结可能的错误：
- GetExplorerPaths中没有过滤非资源管理器窗口，导致保存了IE或其他Shell窗口的路径。
- GetApplicationsWithFiles使用GetModuleFileNameEx可能无法正确获取64位进程路径。
- 在保存应用程序时，多个实例被覆盖。
- WMQueryEndSession中调用inherited可能导致Result被覆盖，从而阻止正常关机。
现在需要针对这些错误进行修正。例如，修正GetExplorerPaths中的过滤条件，只处理资源管理器窗口；使用QueryFullProcessImageName获取进程路径；处理多实例保存；以及调整WMQueryEndSession的消息处理。
以下是针对代码中存在的问题进行修正的步骤和解释：步骤 1：过滤资源管理器窗口在 GetExplorerPaths 函数中，需要确保只处理资源管理器窗口。可以通过检查窗口的类名来实现：[Delphi] 纯文本查看 复制代码 var
ShellWindow: IShellWindow;
HWND: HWND;
ClassName: array[0..255] of Char;
begin
// ... 其他代码 ...
if VarType(ShellWindows.Item(i)) = varDispatch then
begin
ShellWindow := IShellWindow(ShellWindows.Item(i));
HWND := ShellWindow.HWND;
GetClassName(HWND, ClassName, SizeOf(ClassName));
if SameText(ClassName, 'CabinetWClass') or SameText(ClassName, 'ExploreWClass') then
begin
// 处理资源管理器窗口
end;
end;
// ... 其他代码 ...
end;
步骤 2：使用 QueryFullProcessImageName 获取进程路径修改 GetApplicationsWithFiles 函数以支持获取64位进程路径：
[Delphi] 纯文本查看 复制代码 function TForm1.GetApplicationsWithFiles: TStringList;
var
// ... 其他变量 ...
modName: array[0..MAX_PATH] of Char;
len: DWORD;
begin
// ... 其他代码 ...
hProcess := OpenProcess(PROCESS_QUERY_INFORMATION or PROCESS_VM_READ, False, pid);
if hProcess <> 0 then
try
len := MAX_PATH;
if QueryFullProcessImageName(hProcess, 0, modName, len) then
begin
// 处理路径
end;
// ... 其他代码 ...
end;
步骤 3：处理多实例应用程序修改保存应用程序的方法，使用进程ID作为键的一部分：
[Delphi] 纯文本查看 复制代码 // 在保存时包括进程ID
Ini.WriteString('Applications', Format('%s_%d', [ExtractFileName(modName), pid]), title);
// 读取时遍历所有键并处理
Ini.ReadSection('Applications', sl);
for i := 0 to sl.Count - 1 do
begin
// 解析进程名和ID
end;
步骤 4：正确处理 WM_QUERYENDSESSION 消息确保消息处理正确允许系统关机：
[Delphi] 纯文本查看 复制代码 procedure TForm1.WMQueryEndSession(var Message: TWMQueryEndSession);
begin
SaveApplicationState;
Message.Result := 1; // 直接允许关机
// 不调用 inherited，避免覆盖Result
end;
修正后的代码示例（部分关键修改）：
[Delphi] 纯文本查看 复制代码 function TForm1.GetExplorerPaths: TStringList;
var
ShellWindows: IShellWindows;
i: Integer;
ShellWindow: IShellWindow;
HWND: HWND;
ClassName: array[0..255] of Char;
// ... 其他变量 ...
begin
Result := TStringList.Create;
// 主线程已初始化COM，移除CoInitialize和CoUninitialize
try
ShellWindows := CoShellWindows.Create;
for i := 0 to ShellWindows.Count - 1 do
begin
if VarType(ShellWindows.Item(i)) = varDispatch then
begin
ShellWindow := IShellWindow(ShellWindows.Item(i));
HWND := ShellWindow.HWND;
GetClassName(HWND, ClassName, SizeOf(ClassName));
if SameText(ClassName, 'CabinetWClass') or SameText(ClassName, 'ExploreWClass') then
begin
// 原有的获取路径逻辑
if Succeeded(ShellWindow.QueryInterface(IShellBrowser, ShellBrowser)) then
begin
// ... 获取路径并添加到结果 ...
end;
end;
end;
end;
finally
// 移除CoUninitialize
end;
end;
function TForm1.GetApplicationsWithFiles: TStringList;
var
// ... 其他变量 ...
begin
// ... 其他代码 ...
hProcess := OpenProcess(PROCESS_QUERY_INFORMATION or PROCESS_VM_READ, False, pid);
if hProcess <> 0 then
try
len := MAX_PATH;
if QueryFullProcessImageName(hProcess, 0, modName, len) then
begin
// 过滤系统路径
sysPath := IncludeTrailingPathDelimiter(GetEnvironmentVariable('SystemRoot')) + 'System32\';
if not SameText(ExtractFilePath(modName), sysPath) then
begin
// 使用进程ID作为键的一部分
Result.Values[Format('%s_%d', [ExtractFileName(modName), pid])] := title;
end;
end;
// ... 其他代码 ...
end;
procedure TForm1.WMQueryEndSession(var Message: TWMQueryEndSession);
begin
SaveApplicationState;
Message.Result := 1; // 允许关机
end;
解释：- 过滤资源管理器窗口：通过检查窗口类名是否为 CabinetWClass 或 ExploreWClass，确保只处理资源管理器实例，避免包含IE等其他Shell窗口。
- 使用 QueryFullProcessImageName：该API更可靠，支持获取64位进程路径，解决了32位程序获取64位进程路径的问题。
- 多实例处理：在保存应用程序信息时，将进程ID包含在键名中，避免多个实例被覆盖。读取时可根据需要解析进程ID（尽管恢复时进程ID会变化，但至少保存了每个实例的信息）。
- 正确响应关机消息：直接设置 Message.Result := 1 确保系统知道应用程序允许关机，不调用 inherited 避免默认处理可能覆盖结果。
这些修正确保了代码更可靠地捕获和保存应用程序及资源管理器的状态，正确处理系统关机消息，避免常见错误。 | 
发表于 2025-2-14 11:14
|
发表于 2025-2-14 13:31
