@geelaw 提前建立出来也是有最开始提到的问题的，建立出来的类型一定是在某个程序集中的，于是 A.Integer42 和 B.Integer42 不是同一个 42 ，于是会导致各种类型上的问题。而原生的 const generics 则不存在这个问题。
到头来原本想通过语法糖的方式简化实现，结果反而将一大堆东西复杂化了，最后结论是这个东西一定不能做成语法糖。

@geelaw 不是的，对于后者，新的值只需要提前提供 instantiation 的参数就能让编译器提前生成代码，比如 42 ，你可以通过 rd.xml 之类的方法来指定需要的泛型参数，就能使得从任何地方调用 `G2<42>` 成功，例如：
```xml
<Type Name="G2`1">
<GenericArgument Value="42" Type="System.Int32" />
</Type>
```
而前者的话无法通过 rd.xml 来指定，因为在编译期对运行时创建的新类型一无所知，通过 rd.xml 只能指定类型的名字，而无法编写类型的实现。

@geelaw 弄成语法糖显然是不行的，因为编译器生成的类型只会在它所在的项目编译出来的程序集里存在，假设你在 A 项目里用了个 `Foo<42>`，而 B 项目里用了个 `Bar<42>`，你会发现尽管 42 在两侧值都是一样的，但实际上不是一个类型（前者是 `struct A.IntConstant42`，后者是 `struct B.IntConstant42`），于是相互是不兼容的，于是无法相互传递。而且由于你在 A 处压根不知道 B 处的 `IntConstant42` 类型，隐式转换的代码也是无法生成的（隐式转换操作符不支持从接口转换，也不支持泛型）。
另外就是，这么一来，如果你在运行时通过反射调用包含 const generics 的 API ，那你就不得不现场 emit IL 产生一个新的类型，这和 nativeaot 就是完全不兼容的，通过使用 rd.xml 也无法解决。

msstore 上测试的系统是没有带任何环境的，就是一个全新安装的 Windows ，你可能得找台没有装过环境的系统测试能不能正常安装运行。

@hez2010 况且，explorer 从来都没有 API 让你修改成旧风格的开始菜单，不管是公开的还是私有的 API 都没有，要做这件事只能劫持 explorer 的内存地址。

做个简单的不准确的解释的话就是，假设你点击开始菜单的时候 explorer.exe 会执行一个内部的 `OpenStartMenu` 函数打开开始菜单，现在 Explorer Patcher 想要把开始菜单换成他们自己做的旧风格的开始菜单，那怎么做呢？

于是 Explorer Patcher 的开发者通过逆向工具找到这个内部的 `OpenStartMenu` 函数的地址，比如说是这个地址是 `A`，然后他们写一个 dll 在 explorer 启动的时候注入到 explorer 进程里，这个 dll 被 explorer 成功加载之后就会给地址 `A` 插入一条跳转指令使得只要代码执行到 `A` 这里就会跳转到他们自己做的打开开始菜单的函数地址上。这样当你点击开始菜单的时候，explorer 想要执行 `OpenStartMenu` 函数但是被 patcher 的 dll 篡改掉了，于是执行了 patcher 自己的函数，实现了打开旧风格的开始菜单。

那现在 explorer 因为一些原因，比如修复安全漏洞等等，加了一些代码恰好使得重新编译之后 `OpenStartMenu` 函数的地址变了，这可并没有修改任何的 API ，结果 patcher 仍然是按照以前的 `A` 地址进行篡改，这样必然会导致别的什么东西被改掉了，于是使得正常的 explorer 崩溃了。

这难道是 explorer 自己的问题？

@nothingistrue 然而根本就不是「最低安装目标级别提高到 23 」这种变更。

你要知道各种 explorer patcher 插件的原理：注入他们自己的 dll 到 explorer.exe 进程中，替换掉某个内存地址上的函数指针指向他们插件自己的函数来实现自动自定义逻辑，然后这个内存地址还是通过各种逆向工具 dump 出来的。

explorer 自己往自己某个私有类型里加了个私有函数自己用，结果因为这样使得你的插件应该 hack 的地址偏移变了导致崩溃，这总不能是 explorer 的问题吧？

explorer 的 api 从来都是 undocumeted 的，自然也就不存在任何的兼容性保证。

如果你的 jar 是 target 到 Java8 的话可以直接通过 ikvm 来调用。
使用方法也很简单，c# 项目里直接引用 jar 包就能直接用了。
https://github.com/ikvmnet/ikvm

@thinkershare 算术约束我已经另一个分支实现了 prototype ，只不过最终实现方案还有待讨论。

@nulIptr 我倾向于叫他 const generics ，因为和 rust 的 const generics 比较像。
另外，实现 typescript 那种 literal types 我们之前也考虑过，但是拒绝了，因为无法忍受每一个字面量都需要在运行时带上一个 TypeDesc 的开销，并且单纯的 literal types 除了能做体操之外意义不是很大，所以我们倾向于只做类似 C++ 和 Rust 那样的模板值特化。想要 literal types 的话没必要做在 runtime 层面，停留在 C# 编译器层面就行了。
这个特性目前还有一部分内容在设计中，例如算术约束和依赖类型等，我也是最近才刚刚完成了 CoreCLR 部分的实现。所以 .net 9 能不能有我不是很清楚，只是说最早能在 .net 9 实装。

有一个简单的方法是你可以安装 npcap ，npcap 在 Windows 上实现了个自己的驱动，然后你利用 npcap 的 sdk 进行开发就能不需要碰内核态代码也能做到自己想做的东西。

Windows 在 XP 之前还是暴露了完整的用户态操作 socket 网络栈的能力的，从 Vista 开始因为这么搞容易被病毒利用于是就把用户态能干的事情砍的剩不了多少了。
现在如果你想自定义 Windows 的网络栈的话，可能唯一方法是编写 Windows 驱动。

windows 卡顿一下这个问题可能是什么第三方软件造成的。
我之前买了 LG 的显示器之后装了他家的显示器控制中心软件，鼠标突然就开始随机变得非常卡顿，卸载之后就正常了。

PowerShell 会连接微软服务器校验加载的模块的数字签名，网络不好的话就会启动时间很长，因为一直会等到网络超时。
有个方法是启动 pwsh 的时候带上参数 -noni ，不过这样会导致 PowerShell 不能交互式地处理命令（比如命令执行中途询问你输入什么的）。

@wxf666 估计哪里的内存没释放吧，其实你反复切换语言内存也会一直往上涨不会往下掉，这得跑 memory profiler 才能知道原因，数据结构好好设计一下的话是可以做的内存占用几乎维持刚启动时占用不变的，不过这是个随便写的 demo 无所谓了。
Avalonia 的话有个 80mb 左右的常数内存占用，再往上就看代码的算法和数据结构了，和框架本身关系倒不是很大。
notepad 那俩毕竟是下了大功夫优化了占用的 app 。

@wxf666 我的 tokenizer 没做虚拟化，你粘贴的代码文本是一次性全部进行高亮处理保存在内存里的，而不是只处理显示出来的那些代码。如果你想公平比较的话，建议只贴正好占一个窗口那么多的代码量。

@nikenidage1 Avalonia 官网确实没写。我姑且算是 Avalonia 项目的代码贡献者之一所以有了解到这些东西。

@wxf666 体积主要取决于开发者发布时有没有做代码裁减，默认不开，开了之后成品一般在 30mb 往上，不开的话 100mb 往上。
由于是 gpu 加速渲染，渲染后端走的 angle ，内存占用确实是 100mb+。如果关掉 gpu 渲染走软件渲染的话内存占用就只会有 30mb 左右。
至于那个 ui 设计软件，他们在内存里载入了自己的素材库和本地 ai 模型来辅助设计，内存占用自然比较大。

不过也没什么可说的，Avalonia 的体积就是 30mb 起步，启用 angle 后端做硬件加速渲染内存占用 100mb 起步，仅使用软件渲染内存占用 30mb 起步。

这里放两个拿 Avalonia 写的仿 vscode 的全功能代码编辑器，自带多种主题和多语言的代码高亮，一个是开启 gpu 渲染的 angle 版本，一个是采用软件渲染的 software 版本，并且采用了 nativeaot 编译，你可以试试:

gpu 加速渲染:
https://1drv.ms/u/s!ApWNk8G_rszRgrZ47r4LrTUlPupSRA?e=XcbR18

软件渲染:
https://1drv.ms/u/s!ApWNk8G_rszRgrZ5LOnqPDLtcKyrqA?e=C4AP86

@nikenidage1 Avalonia 11 的内存占用稍微大了一些其实是因为启用了新的 GPU 加速的合成渲染器，这个渲染器性能很好但是有一定的内存占用，虽然这部分内存占用其实不来自 Avalonia ，而是来自 ANGLE （一个 OpenGL ES 库）。
如果想要回归到原来的那种软件渲染可以在你的 Program.cs 的 BuildAvaloniaApp 函数里面加

```csharp
.With(new Win32PlatformOptions
{
RenderingMode = new[] { Win32RenderingMode.Software }
})
```

内存占用立即降到只有 30mb 左右。