Monthly Archives: February 2022

用 Lazarus 做界面合适吗?

也许你没留意,很多你经常用的桌面软件是用 Lazarus 开发的。 作为 Delphi 的开源替代品,我一直是比较喜欢 Lazarus 的,虽然有些小众。技术有两种,有些是用来挣钱养家,用来赶进度大规模集团作战的;还有一类是出于兴趣,单纯觉得好玩,会不自觉的有空就翻出来当爱好的,比如 Lazarus 就是一个很好玩的玩具。 因此不用成天纠结 “谁是 GUI 天下第一” 之类内卷的问题,抱着轻松和评测+鉴赏的心情了解下或许也不错。 在此之前,得先说两句 Delphi,姚冬老师,知乎编程板块无人不知,给了 Delphi 这样的评价: Delphi 是神作,它在 RAD(快速应用开发)领域长时间没有对手,直到BS架构取代CS架构。Delphi 的特点就是简单、开发快,单纯就写个基本可用的应用来说,可能至今都没有比他更快的。 为啥作为国内最早使用 Qt 的人,却会给 Delphi 那么高的评价呢?中小应用开发 “至今没有比他更快的技术”这么高的评价,必然是有原因的,无独有偶,另一位 Qt 大神也发表示过对 Delphi 继承者 Lazarus 的喜爱: Delphi 的继承人有两个,第一个是 C# Winform,几乎是把 Delphi … Continue reading

Loading

Posted in 编程技术 | Tagged | Leave a comment

网游通信协议如何防止封包篡改?

第一层:协议非对称加密交换密钥,对称加密传输内容,保护好服务端私钥,防止中间人攻击。流式加密,同样包发两次内容不一样。 第二层:不用标准序列化工具如 protocolbuf,用修改版或者自己实现的。 第三层:客户端加密加壳防止调试和注入,程序签名防止篡改二进制。 第四层:重要代码放虚拟机或者脚本里运行(脚本字节码需需改),一般黑客主要分析反汇编,你复杂逻辑多套几层他就晕了。 第五层:关键数据不落内存,一律使用 getxx,setxx 之类的接口,后面将真实数据经过变换以后才落内存。 第六层:守护进程动态跟踪监控情况。 第七层:决定性逻辑永远放在服务端。 第八层:服务端定期校验消息合理性,比如十秒内最大的移动步长是多少,实际发上来的合理不合理,不合理就踢掉,比如按键点击频率是否超过正常人。 第九层:不定期弹出反外挂答题,答正确奖励经验,错误就掉线。 第十层:必须要放在客户端计算的内容将输入和结果 hash 同步给其他客户端验算,不对就踢掉。 第十一层:当检测到客户端触碰到某规则不要急着踢掉它,而是有概率被踢掉,还要随机几秒踢掉,这样黑客发现一会这里断一会那里断,就蒙圈了。 第十二层:发现某黑客/外挂工具利用某漏洞破解了游戏,先看影响大不大,再看他挣不挣钱,影响一般又不挣钱的话可以先养着他,等他挣钱了用户多了,大型活动之前,一条指令就把它封了,用户退款都可以弄得他爬不起来。 。。。。。 手机打字慢,先写这些,没有绝对安全,就是合理的策略加攻防成本。

Loading

Posted in 游戏开发 | Tagged | 2 Comments

给 Qt5 引入 C# / Delphi 的 Anchor Layout

在前文 用 MFC 写 GUI 程序是一种什么样的体验? 中提过 Anchor Layout 可以很简单的设定让控件跟随窗口四条边大小变化的策略: 比如右下角的两个按钮,设置的 anchor 是 “right,bottom” 他们在窗口扩大缩小时,会跟右和下两条边保持恒定距离,左上角的文字是 “left,top” 的 anchor,他会保持恒定的左边距和上边距,中间文字框的 anchor 是四个方向的 “left,top,right,bottom” 他会和窗口四条边框保持相同边距,因此会随窗口扩大而扩大。 这种布局方式最早是 Delphi / C++ Builder 引入的,非常简单实用,后来被 C# Winform 原封不动的抄了过去,而 QtWidgets 里用了另一套规则,虽然用起来更精细了,却没有 anchor layout 这么简单直白。 虽然 QtQuick 和 QGraphicsItem … Continue reading

Loading

Posted in 编程技术 | Tagged | Leave a comment

用 MFC 写 GUI 程序是一种什么样的体验?

本文来自知乎问题:MFC、WTL、WPF、wxWidgets、Qt、GTK 各有什么特点? 感觉我说了太多 Qt 的事情了,今天只说一下 MFC ,到底过时在哪里,都在说 “MFC 就是 xxx” 类似的话,我来补充点细节,增加点感性认识,到底 MFC 过时在哪里?想要用好 MFC 可以怎么办? 虽然 MFC 也有 DIALOG 的设计器,似乎可以拖一下控件,做个 hello world, 计算器之类的好像也很简单,但是稍微复杂那么一点就麻烦了,比如布局,MFC 里的控件只能设置绝对坐标和大小,那么如果你的窗口扩大或者缩小了,想自动改变内部特定控件的大小和位置怎么办?比如 C# 里随便设置一下各个控件的 docking 和 anchor 就能: C# 里给控件设置 docking/anchor:窗口变大变小后就能自动调整控件的位置和大小 就能让某些控件随窗口变大而移动,某些控件随窗口变大而变大,而某些控件不变,这在任何 GUI 库里都是最基础的功能,都可以在设计器里点两下就做到的事情,MFC 却需要重载 WM_SIZE, WM_SIZING 消息来自己写代码每次手工计算所有控件的新坐标和大小,想写的通用点,还得上千行的代码,枚举所有子控件,根据额外信息重新计算位置大小,虽然 … Continue reading

Loading

Posted in 编程技术 | Tagged | 1 Comment

怎么样打包 pyqt 应用才是最佳方案?

早先看一堆人说 PyQt 打包麻烦,部署困难的,打出来的包大(几十兆起步),而且启动贼慢,其实 Python+PyQt 打包非常容易,根本不需要用什么 PyInstaller,我手工打包出来的纯 Python 环境只有 5MB,加上 PyQt 也才 14MB。 很多人用 PyInstaller 喜欢加一个 -F 参数,打包成一个单文件: 这样的单文件看起来似乎很爽,其实他们不知道,这其实是一个自解压程序,每次运行时需要把自己解压到 temp 目录,然后再去用实际的方式运行一遍解压出来的东西: Process Explorer 把雷达图标拖动到 pyqt_hello.exe 的窗口上,可以看到有两个 pyqt_hello.exe 的文件,外面那个是你打包出来的,里面那个才是真正的程序(虽然可执行都是一个),看看它下面依赖的 python310.dll 是在哪里?这不就是一个临时解压出来的目录么: 看到没?这就是你 PyInstaller 打包出来的 30MB 的程序,每次运行都要临时解压出 71MB 的文件,运行完又删除了,那么如果打包出来的可执行有 100MB,每次运行都要释放出 200-300 MB 的东西出来,所以为什么 … Continue reading

Loading

Posted in 编程技术 | Tagged , | 1 Comment