S++为什么要遍历进程呢？

[Mishasama]

就是有点好奇为什么要这样操作。
因为每打开一个新的进程S++似乎都想要注入一下，感觉这种操作有点奇怪，毕竟又不是通过你启动的。
这是有什么功能是需要到这样的操作吗？这行为有点像QQProtect.exe啊😂

[Mossimos]

需要监听 Steam 启动

SteamTools/src/BD.WTTS.Client/Services/Mvvm/Steam/SteamConnectService.cs

Line 251 in eb53d36

public void Initialize()

具体用来实现目前是这里
判断当前登录用户 筛选当前用户的游戏库

[Mishasama]

监听启动的话不是只要监听特定的进程，比如STEAM.EXE就好了吗？真有必要谁都摸一下？
STEAM 用户相关的信息也只需要 STEAM 的数据文件夹或者 STEAM 进程的内存数据就好了吧？

撇开安全问题（可能会碰到网游反外挂的 G 点等）不说，这逻辑感觉挺浪费系统资源的啊……

[rmbadmin]

监听启动的话不是只要监听特定的进程，比如STEAM.EXE就好了吗？真有必要谁都摸一下？ STEAM 用户相关的信息也只需要 STEAM 的数据文件夹或者 STEAM 进程的内存数据就好了吧？

撇开安全问题（可能会碰到网游反外挂的 G 点等）不说，这逻辑感觉挺浪费系统资源的啊……

本身也没有什么好方法直接监听特定进程，不去获取所有进程筛一遍怎么知道哪个进程是steam进程（除非steam的进程由steam++启动，这是唯一可以避免这样操作的方法），windows上或许可以让程序遍历而是使用ManagementEventWatcher来监听指定进程启动但其本质依然是从所有进程中筛选指定进程，这个过程都无法避免先得获取所有进程，只是一个是程序操作一个是调用系统操作，并且过多得使用windows的api会让程序不便于跨平台。

我还没见过哪个网游反外挂对于扫描进程这种事都得管得，也没有注入任何进程，仅仅只是获取每个进程的名称筛选，这个逻辑也并不会占用多少系统资源。

[Mishasama]

监听启动的话不是只要监听特定的进程，比如STEAM.EXE就好了吗？真有必要谁都摸一下？ STEAM 用户相关的信息也只需要 STEAM 的数据文件夹或者 STEAM 进程的内存数据就好了吧？
撇开安全问题（可能会碰到网游反外挂的 G 点等）不说，这逻辑感觉挺浪费系统资源的啊……

本身也没有什么好方法直接监听特定进程，不去获取所有进程筛一遍怎么知道哪个进程是steam进程（除非steam的进程由steam++启动，这是唯一可以避免这样操作的方法），windows上或许可以让程序遍历而是使用ManagementEventWatcher来监听指定进程启动但其本质依然是从所有进程中筛选指定进程，这个过程都无法避免先得获取所有进程，只是一个是程序操作一个是调用系统操作，并且过多得使用windows的api会让程序不便于跨平台。

进程监控,监视进程启动与退出最稳定的方法，不占CPU，不漏进程！

不知道这个有没有帮助呢？会不会好一些？

至于跨平台的问题，那用 JAVA 会不会比 .NET 更合适呢……据说工资也更高一些😂

我还没见过哪个网游反外挂对于扫描进程这种事都得管得，也没有注入任何进程，仅仅只是获取每个进程的名称筛选，这个逻辑也并不会占用多少系统资源。

我主要是这么想的：
也许光这一个程序做枚举进程的这个行为用不了多少资源，但是在日常应用中，整个系统环境并不是像开发测试环境的虚拟机那样只有这一个程序在运行。包括反外挂等安全监控程序都会监视每个程序的每一个敏感操作，每多一个这样的操作就会导致一连串的资源占用的叠加甚至冲突，最终就有可能导致各种漏或者卡死（卡的很可能是别人的设计有问题的程序）。
虽然说反外挂可能并不会单就因为枚举进程这一行为就 BAN 你，但它检测你的这个行为是一定存在的，并且会因此而消耗额外的系统资源。而且你这个操作是循环执行的，意味着这个占用是永远都不会释放的，只要对方的程序有问题，那你这个操作就会让他的问题加剧。（比如我提到过另外一个类似的问题：#2679 dwmapi 的内存泄漏）
至于为什么我纠结你这个问题……

你看，就连安全软件的主动防御系统都跳出来了。虽然说你并没有做什么坏事，但这么一交互就证明了你这个操作所消耗的系统资源并不仅仅只有你自己枚举所需要的资源，它还额外牵动了其它“多管闲事”的家伙一起来吃资源，这才是最可怕的。（你知道臭名昭著的 QQProtect.exe 也要来关心你吗？我把 QQ 卸载了之后我的 CPU 终于不一直处于睿频的状态了。）

我想一个相对优秀的程序设计不是说非得要把别人的垃圾程序也要照顾好，但至少要想办法尽量不要让别人的黑锅跟自己沾上边。不然未来你的用户就可能给你带来无穷无尽的兼容适配或者其他本不属于你的问题，甚至非议。你觉得呢？

[AigioL]

遍历所有进程的问题之前也有一个 issue 相关 #220
现在代码中应该都仅使用 Process.GetProcessesByName 仅根据进程名去匹配

像操作进程这种基本的东西如果需要调用平台 api 去优化，也过于离谱，尤其是在 Windows 上第一方的 dotnet 中
不过其他语言中似乎都没有这种根据进程名获取进程的实现，甚至只能调用 shell 去查询所有进程再字符串比较

跨平台在 UI 方面是个大坑，dotnet 的方案都挺拉跨的，主要还是微软对 SkiaSharp 这个项目感觉不怎么重视，不像 JetBrains 的 Skiko

在 dotnet 6 上这个函数的实现，看上去还是获取了所有进程之后筛选的
https://github.com/dotnet/runtime/blob/7a62f17ec09ed21cc290b18138da1f44b122f154/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Windows.cs#L20-L50

dotnet 7 中使用了 WinAPI 改进了这个实现
https://github.com/dotnet/runtime/blob/bceefa9fe6e46e3d0cf7d52786ee0666adccd2e5/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/Process.Windows.cs#L22-L43

https://github.com/dotnet/runtime/blob/953d290e756d29707b9829e3ea00ef8f2fc31a9f/src/libraries/System.Diagnostics.Process/src/System/Diagnostics/ProcessManager.Win32.cs#L274-L318

如果你觉得这个函数有什么更好的实现方案，可以给 https://github.com/dotnet/runtime 提交 pr 或者 issue
此项目中具体的业务场景有什么更好的方案也可以提 pr 或者其他语言的实现代码

[rmbadmin]

#2679 的问题不是因为枚举进程而是程序确实有使用dwmapi实现一些功能。
至于你发的PsSetCreateProcessNotifyRoutine，也依然有一些问题，这个回调默认也是监听了全部进程启动的，筛选的过程依然要自己去在回调内实现，并且其回调方法返回的关键信息也只有进程pid，意味着程序依然要根据回调的pid去再次获取进程信息才能拿到进程name进行过滤，这样做或许性能上确实能有一些提升，并且不用循环遍历进程确实是个好事，但可能却触及到更敏感的权限安全问题，安全软件主动防御应该依然会跳出来。
并且根据你的截图显示 Steam++尝试修改受保护的文件或文件夹，这点让我比较疑惑，枚举进程这个过程并没有任何修改操作。

[Mossimos]

实际代码就是只匹配特定进程 的 但是你得在程序启动时 扫描全部进程 才能获取到对应的是否启动啊。
程序如果不一定实际扫描一次进程 那就只能启动的适合扫描一次然后就完全无法获取对应进程是否启动了。
Windows API 没有提供监听程序启动的事件 所有现在基本所有程序有监控启动的基本都是一直去获取进程列表比对。

https://github.com/BeyondDimension/SteamClient/blob/0b79150fd3c20b021697cc3251c21bcc43e1bff7/src/BD.SteamClient/Services.Implementation/SteamServiceImpl.cs#L33
这里是扫描的匹配进程
#if MACCATALYST || MACOS "steam_osx", #else "steam", #endif "steamservice", "steamwebhelper",

以及这里 还获取的程序的启动参数 判断是否是蒸汽中国
https://github.com/BeyondDimension/SteamClient/blob/0b79150fd3c20b021697cc3251c21bcc43e1bff7/src/BD.SteamClient/Services.Implementation/SteamServiceImpl.cs#L141