那就换国产 x86 ？
茶文化什么的，国产最懂国人了（

如果不介意引入第三方 header ，那么可以试试这个：
https://github.com/cnbatch/dynarray
我在两年前做的动态数组库

struct bb { a1 list[1]; };

然后

std::unique_ptr<int64_t[]> ptr = std::make_unique<int64_t[]>(100);

bb *bb_ptr = (bb*)ptr.get();
bb_ptr->list[50].a = 100;

我也喜欢做开源软件，唯一不喜欢的是跟别人聊“这款软件的未来发展”，所以我觉得大项目的作者真厉害，耐心很足。

因为我做的软件，总是做好了能稳定使用就行，扔到 GitHub 后能不管就不管，放养模式。
要是我的软件突然来了许多人来问（例如一星期来一个，对别人来说并不多，而我觉得很多），哪怕是 GitHub 外找过来的，我都会觉得突然有压力，总是担心自己是不是又写错导致出了 bug 。

无论是工作上的还是自己的开源软件，我总会出现一些低级错误（不是底层的那种低级，而是人为失误的那种），写错文件、发错地方、锁了无关文件、加解密时不小心多了一次搞坏数据、删旧代码没删完整搞出错乱，对我来说并不新鲜。反正我是没见过别人会犯这么多低级错误的。这就是为什么我觉得其他开源软件作者那么厉害。

异地+隧道+聚合？

先不说实际效果会受到上行带宽的限制，正常使用时两个出口 IP 的归属地完全不一样，要是访问的网站恰好有风控，归属地跳来跳去就很容易触发风控的吧
（假设：上一分钟是深圳 IP ，这一分钟变成东莞 IP ，下一分钟又变成深圳 IP ）

看起来，用的似乎是大小核
我这普通核 CPU 并未遇到过这种怪事

不过 OP 也可以进一步测试（如果想测的话），用 ffmpeg 做个转码（只用 CPU ），看看 conhost 和 Windows Terminal 的运行情况是否一致

哈！ LOGO ，我小学也学过，一直都没搞懂可以用来干什么，但总见过别人（也是小学生）用 LOGO 获了不少奖。现在回忆起来，LOGO 用来画线条画比起通用编程语言简单很多。当然，后来也是因为小学毕业就再也没碰过 Logo 了。
（第一个弃坑：Logo ）

后面那一堆，也就只有 BASIC 和 VB 见过但没学过，还有汇编语言是正正经经地学过（几年后没怎么用就忘了）。其它都没怎么接触。
（第二个弃坑：汇编，也许总有一天要重新拾起）

虽然我一直在做 Windows 开发，但并不使用 Pascal 。长期用着 C# 做 Windows 开发，然后又回到了 C++。C# 和 Delphi 重合的那一小段时间，我已经上手了 C#。
没错，对于 C 和 C++，我弃坑了很长一段时间。C89 和 C++98 实在是恶心了我好几年，以至于我对这两货很长时间都没好印象。

早期 C 语言变量位置很死板，又有奇奇怪怪的 for 循环作用域泄露问题（就是 Linus 最后不得不升级到 C11 的原因），这两个低级“bug”直接让我敬而远之。
至于早期 C++，既啰嗦又麻烦，看起来方便，实际上还是很简陋。早期的 C++程序及教程，动不动就来个 Class ，动不动就搞个继承链。也许写的人觉得很方便，但我阅读代码时并不这么认为。为了查清楚某个功能到底是在哪里实现的，需要翻查一堆继承链，越看越累。还有早期模板，为了特定的匹配需要写一堆十分复杂的前置模板，看着就觉得累。
还有，这两货的早期标准连 RVO 都没有，如何高效地返回大对象竟然属于“奇技淫巧”，实在难以想象。

当时我对 C 语言的唯一好感，就是写函数和 struct 都极为自由，struct 内物可以细致到每个 bit 位。而当时对 C++的唯一好感，就是既可以用自由函数，也可以用 OOP 那套。不过这两个好感不足以使我继续用 C 和 C++。

于是我同时弃坑 C 和 C++，转而用 C# 了。
（第三、四个弃坑：C/C++）

那不就等于放弃 Linux 的应用开发？没关系，反正我工作场景就是 Windows 开发，正好对接。
至于 Linux ，哈，其实长期以来都无感，对 BSD 反倒还行。只不过我很长时间都没有开发 BSD 应用的需求，主要是工作场合不用 BSD 。而我因为对 Linux 无感所以从来没打算去 Linux 相关的部门，长期“滞留”在 Windows 环境。
题外话 1：一开始我对 Linux 有好感，还用了好几年： /t/902076 。后来 Linux 的“饭圈”爱好者实在过于离谱，我在 Windows 玩游戏玩得开开心心的，它们非要用“Windows 能做而 Linux 做不到 = 没必要做”推导出“Linux 没法玩的游戏=没必要玩的游戏”，攻击性太强（这是 Vulkan 出现前的时期）；还有（ SSD 普及前）吹嘘 EXT2 多么多么优秀，无须整理磁盘碎片，吹完了就踩一下 Windows 用户（没多久就有了个项目叫做 defragfs ，以及 Ext4 内置碎片整理机制，打脸打得啪啪响）。我很厌恶这种无缘无故就被攻击的“饭圈”环境。

从桌面到网站，C# 满足了我（以及工作场合）一直以来的需求。反正有工资拿不用失业就已经足够了，我的目标并不是成为什么大牛，也不是进什么大厂，更不想跟别人一起卷。
而我的 C# 也写得不怎么好就是了，不但被 dispose 和 ~析构() 坑过，还有我“不喜欢继承链”的习惯一直延续到 C# 代码，偏偏我某些同事特别喜欢写继承链，搞得我很头大。最头痛的当属我那喜欢自由函数的习惯，直到后来 C# 允许隐式 Main （该特性叫做“顶级语句”），终于舒服了。

啊对了，Java 也是我放弃的。
毕业前夕学校开了 Java 课，我学了后没怎么用过。
（第五个弃坑：Java ）

题外话 2：后来在工作中以及在家里用 Windows 时，会用到 bat 和 powershell 的脚本，在家里用 BSD 和 Linux 会用到 shell 写 .sh ，虽然不少人把它们归类为编程语言，但我觉得实在没必要，也就简单写一写自动任务就算了，更灵活的事情写个程序去解决有时会更简洁。


没想到的是，某一天我发现 C 语言和 C++竟然发布了新版本，这回把我重新吸引回去了。吸引力最大的是 C++11 （还有后续的 14 & 17 ），终于可以摆脱啰嗦的 C++98 了；尽管到了 C++17 仍旧还是有一些啰嗦的地方（我在写多维数组模板库的时候就有体会），但仍旧比 C++98 好得多。
尤其是反应迅速的 RAII ，我很喜欢这个特性，无须 using(var xxx = doSth()){} 就能在作用域退出时自动释放，重回 C++期间我觉得这样真的很方便。
而且我感到惊喜的是，新标准写出来的第三方库，“继承链”的级数远不如早期 C++那么夸张，可读性好多了。
（重新入坑 C++）

最后是一直不入坑的：Objective-C & Swift （家里没苹果设备，工作的岗位也用不着苹果设备）、Kotlin （没打算做手机程序）、Python （不参与机器学习和人工智能）、Rust （传教士很烦）

我截图内的边框其实就是程序原本的一部份，只不过我开启了“在标题栏和窗口边框显示强调色”，于是窗口边缘就有了纯净的边框，就像二十年前的 WinXP 一样。
WinXP 和 Win11 一样，窗口边缘都是有圆角的，虽然 WinXP 仅限于窗口顶部。

如果用浏览器白色背景 + 微软网站做背景，用区域截图，都可以看得出如同当年 WinXP 的边框
https://telegra.ph/Windows-11%E6%88%AA%E5%9B%BE-07-17

估计正是这个边框阻隔了截图边缘的混乱。只不过这个边框对于内置截图工具的“窗口截图模式”而言没什么用，只对快捷键有效，我都觉得很奇怪。

采用 SPF+还有个原因。10G 电口会带来发热量剧增，对于无风扇软路由来说是很大的麻烦。如果用了 SPF+，那么散热方面的压力也转移到用户这边。

哪怕是有风扇的交换机，也不建议用户的 SPF 端口全插 RJ45 转换头。
比如 TP Link 的：
https://resource.tp-link.com.cn/pc/docCenter/showDoc?source=detail&productId=1649&type=SETUP_BOOK&id=1654157066333608
里面就有提到说：
“TL-SH5428PE 最多支持 1 个万兆电口模块”
“需注意：万兆电模块（ TL-SM510U ）的功耗大于常规光模块，一台 TL-ST5008F 最多只能同时接入 2 支万兆电模块，且建议不要并排接入，避免接入位置温升过高，影响模块性能”

打字快了……是用快捷键截了 WinSCP 的图

我的桌面背景是必应每日壁纸，不是纯色背景
这回用 WinSCP 截了图，顺便附带桌面背景的效果
https://telegra.ph/Win11%E5%8C%BA%E5%9F%9F%E6%88%AA%E5%9B%BE-07-17

忘了说，“画图”粘贴完再按一下 CTRL+SHIFT+X 会比较好

这是我用快捷键直接截的图：
https://telegra.ph/Win11%E6%88%AA%E5%9B%BE-ALTPrintScreen-07-17
边缘都很干净

窗口截图用 ALT + PrintScreen ，不要用 Win11 自带截图工具。快捷键截图的边缘会干净很多，只要去“画图”程序粘贴一下，就可以发现已经能做到要求 1 。
至于第二个要求，楼上已经有人提供了。

首先，与 IPv4 一样，不是所有的 IPv6 网段都能解锁流媒体。于是机场们会专门为流媒体把流量转发到另一条线路；至于用户，完全无须关心到底怎么做的。机场们不但可以用虚拟网络通道（ VPN ）的 NAT 去实现，更可以用 socks5 去实现。

机场的 IPv4 线路经过线路配置后，绕出口提供流媒体解锁，不等于机场主同样给 IPv6 做了同样的绕路配置。

就算强行给 IPv6 做了 NAT 又如何，只要机场主不给 IPv6 做流媒体线路出口的相关配置，NAT 之后照样没法看流媒体。如果机场主也给 IPv6 做了流媒体出口线路配置，那么你用 IPv6 也能解锁流媒体。不用 NAT 又如何，机场主更喜欢用 socks5 呢。

所以说，“IPv6 + NAT”与“流媒体”解锁有什么必然关联？

@huamiao 我一样在用这个系统，对于这个问题也关注了很久。

准确来说，这主要是 OpenBSD 的锅，其次是 pfSense 的锅，随后被 OPNSense 继承。

OPNSense 用的是 PF 防火墙——源自于 OpenBSD ，然后被移植到 FreeBSD ，接着由 OPNSense 作为默认防火墙使用。

OpenBSD 那边不太喜欢 IPv6 ，或者说不太喜欢 IPv6 的某些特性：IPv4 映射地址，还有 NPTv6 。
PF 原本是支持 IPv4 映射地址的，突然从某个版本开始，他们去掉了这个支持，理由是为了“安全”。
而 NPTv6 ，更是从一开始就没打算支持，OpenBSD 那群人甚至给 IPv6 弄了个内置 NAT ，就像 IPv4 那样。
但 OPNSense 等系统需要用，那怎么办？（也就是 GUI“内置”的 NPTv6 ）只好搞个半自动支持，用脚本更新防火墙设置，因为 PF 本身并没有 NPT 的功能。只不过目前比较死板，只能认一个，搞成了半成品的模样。

这个 NPTv6 ，对于 BSD 系列而言，恰恰就是解决多 WAN 前缀+策略路由的关键。
PF 不支持，导致 OPNSense 也无法启用，拖了好几年都解决不了这个问题：
https://github.com/opnsense/core/issues/5284
https://github.com/opnsense/core/issues/6158
OPNSense 开发者们只能采取折衷的办法（目前正在做），那就是持续监控前缀地址，一旦发生变化了就用脚本更新设置。很可能 2024 版都没法没好。

如果不更换系统，目前唯一做法就只能等。


既然写了这么多字了，那就顺便再写一点。

其实 FreeBSD 自家的 ipfw 防火墙原本已经引入了 NPTv6 ，并且能够正常使用。可惜在最近的几个大版本当中，这个功能出了问题，用都用不了。

我在 FreeBSD 的论坛里的提问：
https://forums.freebsd.org/threads/how-to-properly-configure-nptv6.88971/
没人知道怎么解决，也没人找出是谁的代码出了 bug 。
后来我在邮件列表里问了下，同样也没人知道问题出在哪里。
我还顺带发现 ipfw 的邮件列表的“催 bug 机器人”发的提醒邮件比人类邮件还要多。

如果 ipfw 的 NPTv6 功能恢复正常，那倒是可以尝试手动启用 ipfw 单独配置 NPTv6 的部分。

忘了一个，前面我说错了……
析构时删文件不是好主意，崩溃时 RAII 也会起作用，删掉文件

应该是关闭窗口/退出程序时删文件才对

既然你自己就有 Arm Windows 虚拟机，打开看一下不就知道了。
PowerShell 和 bat 是两回事。
PowerShell 除了 PS 自带命令，还可以调用 .net 类库，就是麻烦点。
bat 无法调用 .net 类库，它就是个 cmd 的脚本而已。

wxWidgets 就简单了，构造时判断/写文件，析构退出时删文件。