2026-01-03 22:06:35
说起文本模式界面库，也许有人听过 Turbo Vision 2.0，这货是当年 Borland C++ 3.1 （不是 Turbo C 2.0）背后的商用界面库 TV2 的开源版，经过多年迭代，如今是一款支持 unicode 和现代 C++ 跨平台的 TUI 库了：
项目地址：https://github.com/magiblot/tvision
主要特性：
Linux 下大部分 TUI 程序都是平铺窗口，无法重叠，更无法自由拖动，而 Turbo Vision 2.0 完全像用图形界面程序一样，鼠标操作这些窗口自由移动，扩大缩小，全屏化：
而且 Linux 下面大部分程序对 ALT+ ，CTRL+ ，SHIFT+CTRL+ 等组合键支持非常有限，而 TV2 对不同平台的键盘鼠标做了很好的兼容，让你在远程终端里也能自由的使用各种组合键和功能键。
用过 Borland C++ 3.1 的人一定会以为 BC31 重生了，某种意义上来讲是的，不要觉得技术古老，Linux 下面 TUI 发展几十年，没一个打得过 Turbo Vision 2 的：
这是 TV2 做的终端模拟器 tvterm，各位天天用 tmux 分屏模拟，但 tmux 发展了那么长时间都不支持子窗口互相重叠覆盖，鼠标拖动，TV2 可以让你像用桌面软件一样灵活的操作各个子窗口。
Vim/NeoVim 直到 2019 年才支持 popup/floatwin 可以实现上面类似的效果，而 Turbo Vision 2 在三十年前就做到了。
过去 TV2 只支持 ANSI 编码，无法显示中文，如今中文，日文都能正常显示：
包括 emoji：
你在 Linux 下大部分 TUI 程序想调整下设置都只能编写配置文件，配置 vim 也只能写 vimrc，但 TV2 里有丰富的 TUI 设置对话框：
大部分设置，对话框里点点鼠标就能搞定，毫无学习门槛，无需看很多帮助才知道怎么写配置：
当然 TV2 也有内置帮助系统，它有一套类似 .chm 等帮助系统，内部包含索引，跳转，可以在 TUI 内随时查看你的帮助文件，比如下面的快捷键帮助，基本上和 Windows 程序一脉相承：
最后是编程接口，linux 下一堆 tui 接口，比如 ncurses 这样的都是比较初级的原始的，没有任何高级控件，同时接口也是 C 的，而 TV2.0 基本上所有高级控件你都可以直接使用，写起代码来类似传统的 Qt 程序：
class HelloApp : public TApplication {
public:
HelloApp();
void showHelloDialog();
};
HelloApp::HelloApp() :
TProgInit(&TApplication::initStatusLine,
&TApplication::initMenuBar,
&TApplication::initDeskTop) {
// 启动时显示对话框
showHelloDialog();
}
void HelloApp::showHelloDialog() {
// 创建对话框 (x, y, width, height)
TDialog *dialog = new TDialog(TRect(0, 0, 40, 9), "Hello World");
if (dialog) {
// 居中对话框
dialog->options |= ofCentered;
// 添加 "Hello World" 静态文本 (居中显示)
TStaticText *text = new TStaticText(
TRect(2, 2, 38, 5),
"\003Hello World" // \003 表示居中对齐
);
dialog->insert(text);
// 添加 OK 按钮 (居中)
TButton *button = new TButton(
TRect(14, 5, 26, 7),
"~O~K",
cmOK,
bfDefault
);
dialog->insert(button);
// 显示模态对话框
deskTop->execView(dialog);
// 清理
TObject::destroy(dialog);
}
}
int main() {
HelloApp app;
app.run();
app.shutDown();
return 0;
}
基本就是类似 Qt 的编程方式：事件驱动+控件组合+OOP，不是 ncurses 那种 select/read 标准输入，自己解码半天终端控制码，在琐碎的控制各处显示，自己控制状态切换和重绘，写的你想吐。
Linux 下面基于 ncurses 二次封装的库也很多，但大多是个人项目，浅层封装，Turbo Vision 过去作为支持 Borland C++ 3.1 这种商用级 IDE 的界面库，不是这些玩票项目可以比得了的。
编程语言 TMBASIC 也是用 Turbo Vision 2 做的界面：
补充点历史，Turbo Vision 最初是 Borland 公司用 Pascal 实现的，用于 Turbo Pascal，后来在做 Borland C++ 3.x 的时候用 C++ 重新实现了一个版本，用于支持 BC31 的界面，在 BC31 里包含头文件和静态库，你可以直接用它构建 TUI 程序，接着 Borland 在 1997 年将 C++ 版本的完全开源了，就是我们上面说的这套的源头；
而 Pascal 版本的 Turbo Vision 一直没开源，Free Pascal 后面又根据 C++ 开源的版本重新实现了一套叫做 Free Vision 的界面库给 Free Pascal 做 IDE 用：
我很喜欢它的设置界面，根本不用读文档写配置文件，直接对话框里全部帮你归好类了：
c
是不是很眼熟？Free Pascal 的 IDE，背后使用的 Free Vision，和上面的 Turbo Vision 同出一源。
PS：Turbo Vision 还出过几本书：
想看的话到开头项目主页里有链接。
The post C++ 最好用的 TUI 界面库 Turbo Vision 2.0 appeared first on Skywind Inside.
2025-12-27 00:32:00
就一年没清理 C 盘，今天清理出 140GB 的东西来，而且还没影响使用，所有程序都在往你的 C 盘拉屎。不要网友问我怎么清理下来的：
1）右键 C 盘属性，清理；
2）自己到 TEMP 目录手动清空，注意有三个 Temp：AppData 下面两个，Windows 目录下有一个；
3）SpaceSniffer 找占用大的目录，清空不合理的，这个需要一点经验，拿不准可问下 AI 某目录能不能清空；
4）清浏览器缓存；
5）最后 CCleaner 跑一遍。
上面一系列任务做完基本就清理出 100GB 的内容了，然后再使用 Dism++ 删除系统还原点后，又多出 40GB 来：
最开始剩余空间只有 130GB，现在有 272GB 剩余，可以做一次年度全盘备份了。
The post 如何清理你的系统盘（C: 盘)？ appeared first on Skywind Inside.
2025-10-30 13:48:00
Rust 并不适合开发游戏，它更擅长有明确定义，边界清晰的项目，这样你类型体操一遍做完问题不大，比如重构个已经十年没变过的 C 模块，但游戏领域并没有明确的定义，策划案不停修改，你的代码不但要求快速迭代还要求不停重构，那么类型体操在这过程中就变成锁死你的紧箍咒。
参考文章：3 年写了 10 万行代码开发者吐槽：当初用 Rust 是被忽悠了
这里解释一下，为什么当项目没有明确定义时，rust 为啥会显得笨拙？因为此时不但需求会随时间变来变去，更要命的是你没有一份十年没变过的 C 代码做参考，对项目整体实现缺乏全局的认识，只有自底向上的方法不断尝试和修正自己，不段反思和改进中上层代码，才能像盲人摸象那样逐步认清楚整个世界因该是啥样。
而此时类型体操会在这时勒得你喘不过气来，一个之前需要横着用的变量现在需要竖着用了，你思来想去发现你完全没办像其他语言那样改成法竖着用了，于是你只有引入更大范围的重写才能解决问题，你觉得这样很难受，去 rust 社区寻求帮助，但发现他们并不会帮助你真的解决语言问题，只会一个劲的指责你 “你觉得痛苦正是因为你对 rust 不熟悉导致的” 或者 “rust 逼迫你更大范围重写正是逼你尽早写出更好的代码”，他们这么说在定义清晰的项目里的确没问题，越早重构越好，但在定义不清晰的项目上里存在大量中间设计，你今天改成这样，八成不是最终形态，隔几天可能还要改，而此时 rust 却逼迫你每次都提前费精力进行更大范围的重写，即使这时完全没必要的，过两天就不需要的，他也不许你像其他语言那样用快速实现的方式应对新的中间状态，等需求稳定了，技术方案也收敛的情况下再进行迭代和完善，然后你就抓狂了！
网友 FENG DONG：项目没有明确定义时候，需要设计 cost function，然后让代码沿着 gradient 演进。但 Rust 不是一种可微的语言。
网友 Aaltonen：游戏开发是 “巨型可变状态球” （giant balls of mutable state），需求像 gradient descent 一样逐步演进，但 Rust 的借用检查器（borrow checker）和所有权模型强制你 “一次性想好”，导致小改动引发大重构。
那么 Rust 适合开发游戏引擎么？我只能说 depends，主要到了现在也没啥 rust 开发游戏引擎的成功例子啊，一天到晚到处搞营销的 rust 游戏引擎 bevy 基本上类似个玩具，到现在都没啥靠谱的商业游戏案例，顶多几个独立小游戏之类，而且它要求用 rust 来写业务逻辑，这个上面已经论述过，它并不适合开发游戏业务逻辑；
其次游戏引擎有很多部件，有需要高度优化各种汇编技巧的性能部分（类似 ffmpeg），有需要同各种系统图形 api 打交道的抽象硬件层部分（不断同 direct3d，opengl，vulkan 还有各种系统 api 打交道），还有需要大量整合第三方（基本是 c++ 库，比如 imgui, box2d, sdl, bgfx, physx）的胶水层，这些也并不适合 rust。除非你觉得 ffmpeg 这样的项目适合用 rust 重写，或者可以用 rust 把大量久经考验的第三方库全部发明一遍。
最后，成熟的游戏引擎里都是有各种 hack 或者 dirty trick 的，rust 做这些并不是特别方便。
配图：“But it’s SAFE !!”
The post Rust 适合开发游戏吗？ appeared first on Skywind Inside.
2025-10-24 00:04:59
我的博客使用的 wordpress 一直架设在 bluehost.cn 上，差不多十多年了，前两天突然就不能访问了，后台也登录不进去，一查 bluehost.cn 主页，原来停止服务了，很多和我一样在上面运营十多年的网站都是说停就停，然后完全不提供数据备份的时间，连个电话都不给你打一个，就是邮件垃圾箱里提前几天给你发了一封告知邮件，人家 linode 之类的欠费停止你服务后，任然给你机会备份走，结果它完全不给。
所以没有啥完全稳定会一直存在的服务商，幸亏我机器上有备份，调查了以下几家虚拟主机提供商，他们的业务发展情况及稳定性，最后迁移 bluehost.com 了，帖子和评论都恢复了，但是页面访问统计没恢复到，因为页面访问统计插件是把数据存在别的 mysql 表里的，但之前用的备份插件又是只导出 wordpress 标准表格，所以包括访问统计，upvote 之类的数据全部清零了，无所谓了，还好访问量不算啥重要的东西，希望这次 bluehost.com 能多用两年。
之前我用过 bluehost.com 的，指示图 bluehost.cn 服务器在香港，国内访问会快点后面才选他，看来太小众的还是有问题。这次 bluehost.com 的服务器在亚利桑那，虽然远点，但国内访问起来，只要不下载，看个页面什么的也还算顺利。
有人问我为何不用静态页面？发布到 github pages 上那种，因为我这个 wordpress 博客以及个人 wiki 只依赖一家服务商，但是 github pages 页面需要依赖 github，评论需要依赖 gihtub issues+插件，计数器又需要依赖别的什么服务，依赖的服务太多了，上网那么多年我从不相信有什么服务可以一直持续下去的，所以依赖自然也少越好。
除了服务外，依赖的项目也是越少越好，之前那些 github pages 使用的基于 issues 的插件突然作妖，要收费，不收费就给你插广告，闹得天怒人怨，你还没办法，历史评论是博客相当重要的数据，依赖 github issues 作为评论数据存储的机制还有个致命方案是你还不能方便的导入导出，你会被绑死在 github issues 这个方案上，完全无法掌握自己的数据，不说 github 停止服务，一旦它一朝更改 api 规则（跟 twitter 一样）就只有哭了。
最后 wordpress 的功能真的很强大，插件生态也非常丰富，我也比较熟悉，有啥需求大概都能搞得定。
The post 博客迁移服务商 appeared first on Skywind Inside.
2025-09-30 17:50:00
不怕不识货，就怕货比货，以下七点帮你了解差距究竟有多大：
第一：微信桌面 Qt 版引用了来自 Telegram 的 GPL 代码，对二进制 grep 一下字符串 desktop-app 就可以看到。有人找相关负责人提了一年了，结果连删掉字符串都懒得删。
第二：微信这么喜欢抄 Telegram 却不多抄点好的，比如微信群历史服务器只能保存两周，图片更短，当时没下载的图片几天后想看看就发现被服务器清除了，而 tg 全球十亿用户，消息存服务器四五年都不会删；
第三：什么年代了，微信附件大小最大 100M（不知改了没？）tg 随便存 10G 附件，一存好几年！一年前群里存的视频现在都找的到；
第四：微信那么挣钱的产品，结果给你搞个朋友圈合照都看不清脸的究极图片压缩，号称节省存储空间，好意思么？语音质量被压缩的经常听不清楚，飞书和钉钉的语音都比它清晰一万倍；
第五：微信用起来比 Telegram 卡有很多原因，其中一个重要原因就是微信使用单消息队列，所有消息挤压在一起，每次切换到微信就要同步一半天，包括全局消息和每个群最近的几百条消息，必须要同步完才能近一步操作，几秒时间消息列表不断更新跳变，点击无响应，导致想发给老婆的话明明点了老婆头像，最后因为列表跳变发到了同事群或者小孩班级群里去了，闹出了无穷无尽的笑话；但 Telegram 之所以不卡一个重要设计就是消息使用多队列，同时不需要等消息同步完才能操作，多个消息队列可以一边同步一边操作，每次切换过去你都可以立即流畅的操作，各个群的最近消息历史会使用并行的多个消息队列在后台并行同步，根本不影响你操作；
第六：微信非常耗电，有一次我手机只有 5% 的电了，希望能撑到出租车到家，所以我开启了节能模式，想着应该没事，正在结束着不同应用时来了条信息，我手贱条件反射的点了上去，瞬间就后悔了，熟悉的微信界面弹了出来，然后一个消息同步，手机被卡住不动，界面不停更新，手机瞬间变烫，几秒时间一下给我手机干没电自动关机了；
第七：微信技术团队比较喜欢吧屁大点事情说的玄乎其玄，不就是用了一个现成的叫 amrNB 的窄带语音编码器么，还只能编解码 8khz 的音频，明明有更好的做法，却用这种老旧淘汰的东西损失很多质量换来一点空间：
居然还做了三个通宵，还是他们当时广研最有技术含量的东西，这是在进一步自我暴露么？
所以真的不要和 Telegram 比，一比你发现全是差距。
The post 微信比 Telegram 落后在哪里？ appeared first on Skywind Inside.
2025-05-24 00:27:00
我小学时用的 GMT-92 学习机写程序，就是 FC 6502 那一套，但比后辈小霸王强多了：右上方有磁带盒，有很多扩展软件以磁带形式发布，自己写的 BASIC 程序也可以录制到磁带上下次接着写，小霸王那种没有存储设备一关机你的代码就没有的环境是根本没法学习编程的，因为代码完全无法积累，每次重来，你永远写不了复杂的软件，而这台 GMT-92 最核心的地方就是提供磁带存储，让我可以写稍微复杂点的代码，我就抱着一本 BASIC 说明书开始抄写上面的各种例子代码，然后修改部分不停验证学编程的:
那时我想做一个空战游戏，但是我只会每次循环控制一个飞机从左边移动到右边，完全不知道该如何同时控制多架飞机，因为身边没人教，没网络，书店里没游戏开发书籍，也没处问人，只能去书店看相关的电脑书籍得知有些操作系统是有多任务功能的，可以同时运行几段程序，我心想这就是我想要的，可 GMT 根本没有多任务这个功能怎么办呢？
连续数周没想出解决方案来，上课想，吃饭想，后来脑袋里面一遍遍的过以往学习过的电脑知识，让他们俩俩互相搭配，看看有没有新的可能性，突然我想起书店里介绍多任务原理的文字来，每个任务执行一小段时间片再去执行下一个任务的时间片，切换够快就能产生同时运行的效果，然后我忽然灵机一动，是不是我需要同时控制的多架飞机也可以这样每架飞机每次动一小步，然后快速切换下一架动一小步模拟出多架飞机同时移动的效果呢？
没有多任务系统，我能不能仿照实现呢？然后脑袋里一遍遍琢磨各处细节越想越觉得没问题，然后周末一整天，上午实现了一个基础，下午不停调试，居然被我做出来了，一个简单的空战游戏，多个敌人和主角可以正常同时移动，后来我才知道，这种每次更小一小步保存状态下次继续的方式就是经典的状态机模型，游戏做出来把我同学和身边小伙伴吓了一跳，也把我爹吓了一跳，他终于觉得或许我有潜力搞这个，才在后来初中时真的下决心给我买了台正儿八经的电脑，联想 486DX 66MHz，4MB 内存，DOS 系统，我才正儿八经的有条件开始自学 C 语言和汇编。
The post 你是在什么电脑上学编程的？ appeared first on Skywind Inside.
