我写了个boot和loader，支持FAT12、FAT16、FAT32(还没对NTFS进行研究，手头没资料) 文件系统寻址加载 Kernel，目前刚刚搞好从实时模式到保护模式，并成功的测试了GDT、LDT、IDT程序，基于Ring0和Ring3都测试通过，至于目前的编译器，暂时采用 Linux 下的 GCC 作为编译器，花了很多功夫去了解并解析ELF，至于自己开发BASIC编译器，只是个初步想法，就是将 BASIC 的常用语法、函数以汇编语言写成模块，在编译时，将 BASIC 的语法功能汇编出来，然后借用 Linux 下的 NASM 来编译目标代码。 其实原来有过解析Windows的EXE程序的，虽然EXE文件中有PE代码，但多有的操作关联性太大，如果要能执行下来系统就会变得像Windows一样臃肿(一堆的DLL，而且还要特别去解析)，有些理念可能也很难对上（如驱动），想了想还是先用 Linux 的 GCC 方便点。不过这段时间下了个 FreeBASIC 来看，感觉编译器就是复杂，可能要花上好一段时间才会有眉目。不过希望有一天出来了雏形，大家能参与进来共同打造这个系统就太好了。因为即使系统即使有了 SHELL 和编译器，没有开发的 IDE 还是很麻烦的。
这样改出来的就不是vb了，而且即使做出来，也比不上现有的经过千锤百炼的c，c++之类
这样改出来的就不是vb了，而且即使做出来，也比不上现有的经过千锤百炼的c，c++之类
用过 MS 的 Quick Basic 4.5 吗？用 BASIC 弄过在 DOS 下的图形环境使用鼠标工作吗？ 如果用过，我想你不会觉得 BASIC 这种语言有多大问题。因为任何语言结构最终都是通过编译 器汇编成机器语言让 CPU 执行指令的，所以在以前的 DOS 下，TC 2 和 QB 4 编译出来的的 执行效率差异并不大，至于 C，不会比 BASIC 高到哪去，C 语言一样没有类、一样没有继承、 一样没有聚合等概念，C++ 才有，有些还是 VC 特有的概念。可以说， C 语言本身就有很多 变种出来的应用。而 Basic 变出来的不是 B++ ，而是 VB 而已，只是这种变异从架构本身做了 较大的改变，而且变得缺陷比较多而已，最主要的是效率也降低了。 其实看其本身，他们的目的都是编译出 CPU 保护模式的 PE 指令执行代码（32位）或实时模式 的（16位）代码，这个无论什么操作系统都必须遵守的规则，否则程序就不能被 CUP 执行。 既然是这样，这些所谓的语言其实就可以看作是一个个的文本文件，只是这些文本文件有着特定 的格式，如果按照这些文本的特定格式翻译成 CPU 指令代码，便完成了编译的过程。 而且在 QUICK BASIC 中，也有中断调用的方式，完全可以借鉴过来实现 BASIC 更强大的功能， 要不在 BASIC 中嵌入汇编，如： Function NewSum(A As Long, B As Long) As Long Dim retLong as long #ASM BENGIN push eax mov eax,$A add eax,$B mov $retLong,eax pop eax #End ASM NewSum = retLong End Function 这样在编译时甚至还可以省略掉部分代码的汇编过程，同时还可以实现了VB中嵌入汇编的需求。 在解释的时候加上类、继承、多态...等 C++ 的概念，我不觉得这样的 BASIC 会比 C++ 差到 哪去。说到执行效率，只要是不按VB的那种架构，走普通编译器的模式，根本和C/C++没区别。 说到稳定性，主要还是开发人员的代码和编译器的问题，和这种技术无关。
其实要把上面的代码解释成汇编可以这样写retLong equ 0 A equ 0 B equ 0 NewSum: push eax mov eax,[A] add eax,[B] mov [retLong],eax pop eax ret
java 对于VB熟手来说上手还是有很大难度的
http://topic.csdn.net/u/20111006/02/e54f40ca-5511-4e58-90bc-59d891bddf6b.html
其实原来有过解析Windows的EXE程序的，虽然EXE文件中有PE代码，但多有的操作关联性太大，如果要能执行下来系统就会变得像Windows一样臃肿(一堆的DLL，而且还要特别去解析)，有些理念可能也很难对上（如驱动），想了想还是先用 Linux 的 GCC 方便点。不过这段时间下了个 FreeBASIC 来看，感觉编译器就是复杂，可能要花上好一段时间才会有眉目。不过希望有一天出来了雏形，大家能参与进来共同打造这个系统就太好了。因为即使系统即使有了 SHELL 和编译器，没有开发的 IDE 还是很麻烦的。
这样改出来的就不是vb了，而且即使做出来，也比不上现有的经过千锤百炼的c，c++之类
这样改出来的就不是vb了，而且即使做出来，也比不上现有的经过千锤百炼的c，c++之类
如果用过，我想你不会觉得 BASIC 这种语言有多大问题。因为任何语言结构最终都是通过编译
器汇编成机器语言让 CPU 执行指令的，所以在以前的 DOS 下，TC 2 和 QB 4 编译出来的的
执行效率差异并不大，至于 C，不会比 BASIC 高到哪去，C 语言一样没有类、一样没有继承、
一样没有聚合等概念，C++ 才有，有些还是 VC 特有的概念。可以说， C 语言本身就有很多
变种出来的应用。而 Basic 变出来的不是 B++ ，而是 VB 而已，只是这种变异从架构本身做了
较大的改变，而且变得缺陷比较多而已，最主要的是效率也降低了。
其实看其本身，他们的目的都是编译出 CPU 保护模式的 PE 指令执行代码（32位）或实时模式
的（16位）代码，这个无论什么操作系统都必须遵守的规则，否则程序就不能被 CUP 执行。
既然是这样，这些所谓的语言其实就可以看作是一个个的文本文件，只是这些文本文件有着特定
的格式，如果按照这些文本的特定格式翻译成 CPU 指令代码，便完成了编译的过程。
而且在 QUICK BASIC 中，也有中断调用的方式，完全可以借鉴过来实现 BASIC 更强大的功能，
要不在 BASIC 中嵌入汇编，如：
Function NewSum(A As Long, B As Long) As Long
Dim retLong as long
#ASM BENGIN
push eax
mov eax,$A
add eax,$B
mov $retLong,eax
pop eax
#End ASM
NewSum = retLong
End Function
这样在编译时甚至还可以省略掉部分代码的汇编过程，同时还可以实现了VB中嵌入汇编的需求。
在解释的时候加上类、继承、多态...等 C++ 的概念，我不觉得这样的 BASIC 会比 C++ 差到
哪去。说到执行效率，只要是不按VB的那种架构，走普通编译器的模式，根本和C/C++没区别。
说到稳定性，主要还是开发人员的代码和编译器的问题，和这种技术无关。
A equ 0
B equ 0
NewSum:
push eax
mov eax,[A]
add eax,[B]
mov [retLong],eax
pop eax
ret
但是我依然喜欢，小项目还是用VB开发速度确实是快，虽然过时
1.背着一大堆的专用库，而且安装程序时，容易产生版本问题。
2.最严重的问题是，外围的环境不好，新系统和新控件对VB支持不好
3.还没听过VB能搞嵌入式编程。
4.VB数据处理不太友好，甚至实现不了。
5.缺乏类继承，很多代码重复写。VB最大的优势：
1.与VBS兼容性最好，EXCEL等的宏几乎可以直接拿来就用，操作EXCEL非常方便。
2.目前很多工程控制都带有VB输出端口，用VB可以很容易实现数据收集，如模数转换器等。
3.由于函数丰富，一般的数据操作都非常简单。
1.背着一大堆的专用库，而且安装程序时，容易产生版本问题。
是因为你还没有很多自己的库，全是用Microsoft的东西，当然要拖一堆的玩意，如果你玩VB玩久了，会发现很多Microsoft的东西其实效率和资源控制并不是很好的，当你自己用API写类或控件解决问题后，拥有一堆自己的类或自定义控件时，编译出来的程序即使不拖那么多DLL同样能在大部分的系统中直接执行。就比如你一个控件都不加，用VB写个程序，应该在大部分的Windows系统中都能够正常运行的道理是一样的。2.最严重的问题是，外围的环境不好，新系统和新控件对VB支持不好
在VB的初级阶段是依赖与控件、系统组件等现成的对象进行开发，但时间久了，会发现单纯依赖与系统提供的这些控件或组件并不能完全满足于各种开发需求，所以很多人开始对VB能够调用到的系统API函数感兴趣，用久了，甚至很多人也会直接用这些函数来打造自己的程序，放弃使用一些控件或组件，因为如果使用控件和组件，都是调用外部程序接口，即使VC这么用，同样会有版本问题，为什么VC没有这种问题呢？其实VC在开发上大致有两种模式，1就是MFC模式，这种方式和VB的体制没什么两样，编译出来的程序也是依存与固定的几个运行库，只是VC的这种东西要比VB的执行效率高一点。但同样会有VB的这种DLL和控件版本问题。还有一种是Win32 SDK 方式，这种方式在编译时主要分为两种模式，静态库形式和动态库形式编译，如果用动态库形式，基本上和VB调用API写程序没多大区别，而静态库就是把所谓的API部分代码跟随程序一起编译其中，无需外部调用支持，不过，实际情况，很多VC程序很少采用静态库编译模式，因为这样编译出来的EXE体积较大，并不是很多人这么做。所以，同样的问题在VC下也会出现的，只是因为搞VC的程序员大多都不依赖与控件和组件的使用，所以这种控件版本兼容性问题就不常出现，比如Sock编程，VB里有多少人用API来写？但VC中有多少人不会用API写？这就是根本所在。3.还没听过VB能搞嵌入式编程。
VB搞嵌入式早就有了，Microsoft有一个在WinCE 5中的开发工具，简称是 EVB，同时也有EVC，现在的WInCE 6 和WinCE7可以用.net来写，只要安装个WinCD SDK，就可以用.net编译出CE的目标程序，当然VB.net也可以写出程序并用WinCD SDK的交叉编译器编译出目标程序。4.VB数据处理不太友好，甚至实现不了。
不知道你的数据是指什么？如果说内存数据，可以用API控制，如果是文件数据，可以用字节数组，如果说数据库，可以用各种数据对象或API函数接口实现，我觉得没什么是实现不了的，只是实现的难度如何而已。5.缺乏类继承，很多代码重复写。
这点的确与C++不同，但是真正需要这种继承应用的处理有多少？我觉得如果有需要这种应用的地方，用点麻烦的方法同样可以实现类似的效果就可以了，也不用强求
class NewCclass:public AClass,BClass
{
}
这种写法的问题，能达到目的就好
VB最大的优势：
1.与VBS兼容性最好，EXCEL等的宏几乎可以直接拿来就用，操作EXCEL非常方便。
这只是Microsoft对于Basic的扩展的应用，毕竟Basic就Microsoft创出来的，所以看上去学会VB就可以在很多地方应用，但是从夸平台看，VB就根本不具备任何优势，只能在Windows下应用，而且将来的Windows系统也开始支持得不是很好了。所以我认为这并不是VB的优势。2.目前很多工程控制都带有VB输出端口，用VB可以很容易实现数据收集，如模数转换器等。
估计你没有涉及过硬件的开发，很多硬件接口只能说VB可以实现对接，并不是VB的优势，因为其他很多语言同样可以实现这样的对接，甚至效率和资源控制上更具备优势，相对来说VB只是能用，并不能做到很好的管理。至于模数转换，根本和VB没关系，完全是由硬件完成的事情，这种工作是硬件通过开通检测电容充电时间，每秒上10万次的速度不断检测转换而来，VB来进行模数转换根本就不靠谱。3.由于函数丰富，一般的数据操作都非常简单。
这点到是真的，VB的函数的确很不错，相对来说比其他大多数语言要简单很多，的确是个优点。不过，我个人认为，VB最大的优势是语法简单，语法和思路类似人类语言，所以很容易上手。对于初学者来说较为简单易懂。再者就是VB封装了大量的现成控件或类库，写一些简单的小程序，开发速度非常快，让人容易找到成就感（相对VC Win32 SDK 创建一个窗口的方法来说，VB就像在天堂写程序）。
不过也就是因为如此，很多人认为程序开发就该这么简单，甚至接受不了真正系统复杂的工作方式，很多VB程序员难转其他语言就是这种原因（接受不了），最终还有很多放弃的。
我个人而言，了解过很多开发语言，也做过很多底层或是硬件层程序开发，包括多种WEB脚本和各种应用程序语言或脚本，回头看看，觉得Basic的确是个很优秀的语言，因为它能在很大程度上解放程序员的思路，去考虑逻辑上、理论上的很多问题，这才是人该做的事情。只是因为目前我们用的编译器导致编译出来的程序有很多功能难以实现或效率偏低。这不是语言的问题，而是工具的问题。
说句真话，我有1两年没用过VB写程序了，通常都用C/C++，不过如果真要说语言，我最喜欢的还是basic，C/C++虽然也用得很习惯，也同样能做到解放思路，我也写了很多函数或类模仿VB的方式提供给C/C++来调用，可以说写C/C++程序有时候就像在玩basic一样简单，就是觉得basic开发思路很好，我到C++下也用同样的思路去写代码。所以，我认为BASIC的优势是、简单、易懂、容易上手、因为接近人类语言所以可以很大程度解放思路、开发速度快。
VB里面很多控件是基本控件，像打开对话框等，一般用comm dialog，复杂点的用API生成，但用comm dialog控件容易引起版本问题，用API就失去VB的易用性了。2.还没听过VB能搞嵌入式编程。
这里的VB就指VB6以下版本，VB.net已经不是以前的VB了，VB.net搞的嵌入式编程，不能算到是VB上去。3.VB数据处理不太友好，甚至实现不了。
最近用VB处理二进制数据，从文件里得到了一个4字节无符号整数，现在要进行一些位操作，如果最高位是1的话，VB里面的处理就不好处理了，总是出现超出LONG表示范围。
VB还有很多不好处理的数据，例如双向链表等。4.缺乏类继承，很多代码重复写。
在C#中，可以直接从已有控件中继承过来，增加自己的功能而不妨碍原有控件的功能（包括事件），非常方便。
在VB中，这就麻烦多了，自己定义一个用户控件，然后在控件里面把标准控件放到用户控件里，再把标准控件的属性、事件等一个个开放出来供用户调用。5.与VBS兼容性最好，EXCEL等的宏几乎可以直接拿来就用，操作EXCEL非常方便。
实际应用不要考虑跨平台，VB程序面对的是普通用户，而普通用户一般都是Windows，只要用户能正常使用就行了，跨平台会把你搞得很惨的。大不了重新用其他语言做一个。
VB用得最多而且实用价值比较高的是做ERP，ERP的商业逻辑基本是在数据库里面实现的，直接调用就行了，代码没多少。做报表的话，简单的就直接用VB导出到EXCEL里面，这时用VB是最方便的。6.目前很多工程控制都带有VB输出端口，用VB可以很容易实现数据收集，如模数转换器等。
这里的模数转换器是指硬件（模数转换器）已用C语言等编写好DLL，有VB接口可以调用。一般硬件提供的接口都是对VB，VC的，买硬件时带的例子都是VB或者VC
web程序中被鄙视的asp
以前数据库中被鄙视的是vfp哎，怎么都是basic家族的。