- 注册时间
- 2004-8-31
- 最后登录
- 1970-1-1
|
第n次了
至Lee:
记得我以前在wqxsky跟你提意见,虽然说我那时水平不行,什么都不懂,但是你说的话很过分
我也总挑你刺
但是,我绝对不喜欢记仇
希望你能仔细看,如果那些地方不好,希望能指出原因
如果我今天给你提的建议你完全不放在眼里,觉得"胡说八道",觉得我什么都不懂
那就算了,大家也会知道你的RP是什么样
你所做的LavaX虽然从"跨平台"上做的很好
但是功能太少了(你不想承认吗?)
我现在我不跟你争"跨平台"好还是坏,我只从用的好不好这个角度来说(编写效果如何,使用效果如何)
现在我只是给你提意见,并将我的想法表述出来,并非要求你这么做,你可以做参考
虽然我不是很清楚目前LavaX"进化"到什么样了
但是我希望你考虑如下建议:
添加系统库、静态链接库以及动态链接库这3种功能
静态运行库就是编译好的LavaX代码,已经编译好的伪指令
他的用途是升级方便~易管理,节省编译时间(作用不大啊)
系统运行库就是根据不同平台而特意制作的"接口一样、功能一样只是程序不一样"的函数库
(系统库可以说你在为一个机器做解释器的时候就已经完成了)
你可以把他插件化(易与管理、添加与删除):比如某人开发了一个关于图形的一些功能,并把他命名为XGraphic
那么他就可以做一个XGraphic.plugin(如果是.dll也行.sys也行表达出意思就行了)
而某人写的程序用到了XGraphic库,那么解释器就会查看这个平台上(解释器)是否安装了对应的插件以及版本是否够高(版本最好是向下兼容,淘汰除外)
系统运行库还可以写成非汇编(LavaX伪指令),前提是对运行效率要求不是很高
动态运行库的作用主要是程序复用、易管理(升级、修复)、节省编译时间(作用不太大吧)
例如某人写了一个文本编辑器,用到了一些关于文本操作的函数
而他后来又写了一个其他程序,同样用到了文本编辑器所用到的函数
如果他将这些函数写成动态链接库,那么他所写的这2个程序更甚以后写的其他程序,都可以使用这个库而不需要重新编译,不需要增加目标文件的尺寸
如果这个库中的某个函数有bug
那么他就可以只修复这个库的bug而不是把他以前用的所有程序重新修改一次
所谓库可以这么大致分出来:
1、系统库: 这往往是需要很高的执行效率的函数库,例如图形操作,文件操作等,虽然LavaX本身已经有了你所说的"完美"的图形操作函数,但是这些还是不够的,可能由一些"非官方"的开发者编写了更有实际用途或更有效率的图形库,那么他就可以创造一个扩展的图形库
犹如Windows操作系统上安装的DirectX9一样,在刚装机时 这些功能是没有的,用户需要在安装DirectX9才可以使用这些功能,同样 这么设计便与升级,在某些功能升级或是完善的时候,就可以为某些功能的库提供单独的升级版本,而不用把整个系统(解释器)做升级
如果将这些实现了,我想 跨平台就不会那么困难了,因为 有变更的只是这些功能而以,除了这些功能以外的一些运算(打个比方,LavaX1.0的0x00-0x7f的指令)几乎是千篇一律 各平台都可以通用
再打个比方:
一个在160x80黑白平台上所写的程序,他对图形的操作 都是针对1Bit(黑白)以及160x80而设计的
但是 如果这个程序引用了单独提供的一个图形库 并且这个库的某个函数准确的描述了当前平台上的显示设备具体参数(分辨率 颜色等),那么这个程序就可以完美的"向下兼容"
也就是说 如果另一个320x240的彩屏机器上运行这个程序,就可以通过这个库来软转换(并非像NC系列的lava游戏在TC800上运行 出现花屏),这个库会模拟一个真实的160x80黑白显示屏的硬件 而事实上 这并不耗费太多的资源(如你所说,牺牲了一些速度)
2、用户编写的动态链接库:
这个库不是汇编代码,是LavaX伪指令,他的作用只是为了让代码的复用更加方便,以及能够更好的进行升级以及修改(只要保证函数的操作方式一致,即可以向下兼容)
3、用户或官方编写的静态链接库:
这一般是一些对速度没什么大要求的功能,他的出现纯粹是为了编译速度的增快或是减轻解释器的负担,他的组成包括一些编译好的静态库(Lib,LavaX伪指令),以及来调用这些函数的描述(头文件,提供了调用格式以及退回类型---即调用方式)
--------------------------------------------------------------------------
做个假想:
某个主要在320x240 16阶上编写的大型RPG游戏(很精致的那种)
在A某的机器上(T1200)出现了:
运行游戏需要DirectX 9.0(开个玩笑),请到http://xxx下载最新版
在B某的机器上(T1200)出现了:
您的DirectX版本:8.0版本过低,请到http://xxx下载最新版
在C某的机器上(NC2600C)出现了:
本程序要求使用320x240的显示区域,与您的机器:160x80 1位 不符,无法做转换
(程序中判断当前分辨率是否比要求的要小,色深是否在4阶以下)
在D某的机器上(480x240的HPC)系统做了自动的转换
(在DirectX的设置里可以设置转换方式,即1:1放大(不敢想象效果)还是自定义(手动填写分辨率))
在E某(NC1020?哈!)的机器上解释器提示:
系统可用内存不足,无法除始化程序(程序在编译时将记录总共分配的内存,也就是说 在编译LavaX程序的时候 永远不会提示内存空间不足,足不足在解释器的地方将会判断)
而在F某(未知机型)上解释器提示:
动态分配内存失败:系统内存空间不足
而在G某上程序提示:
没有找到音频设备,是否忽略?
在H某上运行某红外传输软件:
没有找到红外设备(确定后退出)
在I某上运行某MP3播放程序:
音质超烂,而且卡
(因为在DirectSound中启用的是软解码并且硬件有限制)
一个LavaX平台构想:
打开LavaX解释器,选设置
找到系统库管理,里面有:
memory.dll | 内存管理库 | 作者 ee 公司:XXX 备注:XXX 版本:XXX 安装时间:XXX
file.sys | 文件系统库 | 作者 ee 公司:XXX 备注:XXX 版本:XXX 安装时间:XXX
gdi.dll | 标准图形接口库 | 作者 ee 公司:XXX 备注:XXX 版本:XXX 安装时间:XXX
network.sys | 标准数据传输库 | 作者:Lee 公司:XXX 备注:XXX 版本:XXX 安装时间:XXX
bluetooth.dll| XXX蓝牙 | 作者:XXX 公司:XXX 备注:XXX 版本:XXX 安装时间:XXX
system.dll | 系统控制库 | 作者:Lee 公司:XXX 备注:XXX 版本:XXX 安装时间:XXX
xxxsys.dll | X机型系统控制库| 作者:XXX 公司:XXX 备注:for xx机型only 安装时间:XXX
jpeg.dll | jpeg解码器 | 作者:XXX 公司:XXX 备注:XXX 版本:XXX 安装时间:XXX
............略
在看某人些的某字典程序中的文件:
xdict.exe
lib.dll
dict.dll
word.dll
config.ini
dic\简明.dic
dic\牛津.dic
dic\计算机.dic
某文字处理软件目录下:
word.exe
config.cfg
reg.dat
script.exe
hotkey.exe
hotkey.dll
config\hotkey\default.cfg
config\hotkey\XXX.cfg
config\template\default.tmp
config\template\letter.tmp
config\template\note.tmp
lib\graph\male.gif
lib\graph\female.gif
lib\graph\mail.gif
richedit.dll
IME.dll
form.dll
word97.dll
gif.dll
jpeg.dll
某解压缩软件的目录:
wqxzip.exe
checkout.dll
7-zip.dll
zip.dll
cab.dll
jar.dll
tar.dll
rar.dll
register.exe
License.txt
------------------------------------------------------------------------
如此岂不是更好?
在使用各函数的时候添加一个include 应该并不难吧
不可能出现那种拿过来大家都不会用的事情~
一般来说 常用功能不需要使用动态链接库等
如果想用好他 具体学一学 也不费什么事
建议:提供标准的指针处理,我不想跟你争论指针安不安全的问题
但是PC上都这么用了n年了,也没有淘汰他,而且指针太好用了,希望能够支持他
inline函数:这对提高程序效率来说太重要了
动态内存分配:缺他可不行
输入法系统:建议内置他,作为伪指令或是汇编形式的系统库,如果安装其他输入法(五笔等),都要在这个输入法系统的基础上制作(这个库里有安装具体输入法发相关功能函数,如果要添加输入法 可以写一个安装程序,调用这个系统库,来将输入法安装到系统中的)
建议将LavaX作为系统内核 尽量少用解释器的形式
以上:真正的跨平台,一个程序编译了成了伪指令 只要有LavaX解释器 以及程序特殊要求的一些东西 就能完美运行
|
|