[Feat] 希望增加文件拖拽功能

[weskongxing]

Use the search function to see if this feature has already been suggested.

• I have searched for duplicate issues.

Description of new feature

在对话时附加文件只能通过点击添加附加文件选项再去弹出的资源管理器中选择，这很不方便，希望能增加直接拖拽文件到对话框来添加文件的功能，这样会方便很多

App Version

0.8.0

[monkeycathyd]

我试了试原本就可以拖，拖拽不了应该是因为你是管理员权限运行的软件，Windows禁止低权限的窗口往高权限窗口拖拽

[weskongxing]

有办法让管理员模式也能拖拽么

[weskongxing]

如果不行的话就关闭这个issue吧

[AuroraZiling]

是系统硬性限制

[weskongxing]

系统硬性限制是真没办法，只能用复制粘贴的方式适应了

[monkeycathyd]

除非给整个系统管理员批准模式关掉才行，但是很不建议这么干
不过rufus有点特殊：打开就要管理员，但是提权之后还可以把ISO拖进窗口里，好奇这是怎么实现的

[weskongxing]

可能是有什么办法能读取到被拖拽的这个文件的路径吧，然后自动填进去

[DearVa]

如果是基于WindowMessage的拖放（旧版拖放），可以通过Win32 API来设置允许UAC绕过；但是复杂的拖放（Avalonia所用的基于COM的）就无法绕过

[monkeycathyd]

如果是基于WindowMessage的拖放（旧版拖放），可以通过Win32 API来设置允许UAC绕过；但是复杂的拖放（Avalonia所用的基于COM的）就无法绕过

我让AI帮我分析了下（我不怎么懂代码这块），还真是

● 答案：ChangeWindowMessageFilterEx API

  你观察到的现象完全正确——Windows Vista 起引入的 UIPI（User Interface Privilege Isolation，用户界面特权隔离）
  确实会默认阻止低权限进程（如普通用户运行的 Explorer）向高权限进程（如以管理员身份运行的 Rufus）发送 WM_DROPFILES
  等窗口消息。

  Rufus 之所以能"突破"这个限制，靠的是微软官方提供的 ChangeWindowMessageFilterEx API。关键代码在 src/rufus.c:3886-3889：

  // Enable drag-n-drop through the message filter
  ChangeWindowMessageFilterEx(hDlg, WM_DROPFILES, MSGFLT_ADD, NULL);
  ChangeWindowMessageFilterEx(hDlg, WM_COPYDATA, MSGFLT_ADD, NULL);
  // CopyGlobalData is needed since we are running elevated
  ChangeWindowMessageFilterEx(hDlg, WM_COPYGLOBALDATA, MSGFLT_ADD, NULL);

  这不是"绕过"安全机制，而是微软专门设计的一种自主放行机制：

  - 高权限进程主动声明：ChangeWindowMessageFilterEx
  只能由高权限进程自身调用，低权限进程无法强制高权限进程接收消息。这就避免了安全问题——是受保护的一方（admin
  进程）自己决定"我愿意接收来自低权限进程的拖拽消息"。
  - MSGFLT_ADD：将指定的消息 ID 加入"白名单"，允许它穿透 UIPI 屏障。
  - WM_DROPFILES：这就是拖拽文件时发送的窗口消息。Rufus 收到后，在 src/rufus.c:3008 的 WM_DROPFILES 分支中用
  DragQueryFileW 提取文件路径，然后加载 ISO 镜像。

  同理的 WM_COPYDATA

  顺便注意到 Rufus 还放行了 WM_COPYDATA 和 WM_COPYGLOBALDATA，这是因为 Rufus
  通过命令行参数支持单实例运行（后续启动的实例通过消息将参数转发给已有实例），而如果是 Explorer
  右键菜单触发的命令，也需要跨权限传递数据。

  总结

  这并非安全漏洞，而是 Windows
  留给高权限进程的知情选择权：默认拦截一切，但允许高权限进程根据自己的需要放行特定消息。Rufus 只放行了拖拽文件所需的
  WM_DROPFILES，而不是全盘关闭 UIPI，做到了安全性与可用性的平衡。

[DearVa]

目前唯一可行的解法是将视觉树获取、按键监听等单独拉一个UAC进程运行，主程序则是非提升的进程，二者通过RPC通信

[weskongxing]

这么说有希望解决🤔

[DearVa]

这么说有希望解决🤔

大重构。这样架构上确实更规范，减少软件自身卡死导致连带系统快捷键一起卡死的可能性，同时也可以把视觉树这部分容易内存泄漏的模块解耦出去。