[分析环境reactos0.3.1&，i386体系]
ReactOS的中文本地化
(类似Windows操作系统源代码分析)
1 什么是ReactOS
1996年，一群开源软件开发者启动了一个名为 FreeWin95 的项目，旨在实现一个 Windows 95 的克隆操作系统。这个项目当时只停留在关于系统实现的讨论上。
到了1997年末，项目依旧没有进展。开发成员呼吁重新开始这个项目，而实现的目标也改为 Windows NT 系统，同时项目名称命名为 ReactOS（react 反抗）。1998年2月ReactOS项目正式启动，开始开发系统内核和基本的驱动程序。
ReactOS一直与WINE（另一个开源项目）紧密合作，让ReactOS随着WINE在Win32 API项目的发展而发展。Wine的DLL因其大多可以在ReactOS和Wine之间共同使用而被受关注。为此双方致力于兼容问题，务求令余下的少量 DLL 也能为 ReactOS 所用
ReactOS的目标是实现一个基于windows架构的免费并且开源的操作系统，提供对已存在的windows应用和驱动软件支持，简单的说就是在Microsoft Windows上开发的应用（二进制文件）或基于windows（目前是windows2000以下）开发的驱动不需要任何从新编译就可以运行在ReactOS上。以下是我对ReactOS的一些中文支持的截图
2什么是Wine
Wine (Wine Is Not an Emulator) 是一个Windows应用程序接口(API)库，作为一个Windows程序和Linux之间的桥梁可运行在X和UNIX 之上的一套Windows 3。x 和 WindowsAPIs的实现。它是一个Windows兼容层。
用通俗的话说，就是一个Windows模拟器，这个层即提供了两套方案来实现在Unix上模拟windows平台特性，第一种方法是将居于windows得源代码与Wine提供的居于UNIX的开发工具包(Winelib)从新编译产生一个新的可以在Unix下运行的二进制文件。第二种方法是利用Wine提供的程序加载器，该加载器允许不用任何修改Windows 3.1/95/NT的二进制文件运行在Intel Unix及其衍生版本下。Wine可以工作在绝大多数的UNIX版本下，包括Linux， FreeBSD， 和 Solaris。
3 两者的区别
不要将ReactOS想象成一个将类Unix系统与Wine的整合，作为Wine它主要是提供一些Windows APIs的上层模拟。而这些上层APIs的低层调用被Wine做了移花接木，转到了X windwo或者是Unix的调用。但是ReactOS则不同，由于两个项目都是开源的，所以ReactOS将部分Wine的代码作了移植，而为上层APIs服务的低层函数调用则完全由自己实现，并且这些调用规则也完全与Microsoft Windows低层调用兼容。ReactOS并非是居于Unix及其衍生版本的。
4 中文本地化需要解决的问题
中文需要解决的问题不仅仅是汉字的显示，更重要的是要解决字符的编码得问题，先从ASCII说起。ASCII是用来表示英文字符的一种编码规范，每个ASCII字符占用1个字节（8bits） 因此，ASCII编码可以表示的最大字符数是256，而中文的字符范围却大大的超过了这个范围。因此用一个字节来表示是远远不够的。
因此中国推出了自己的汉字编码。GB2312它是国家标准但不是国际标准，因为台湾有一个Big5编码标准，很多编码和GB是相同的，这样就会产生同一个文字在不同编码下被解释成不同的汉字。
4.1 什么是Unicode
上面的问题并仅仅是在汉字的编码上产生的问题，在不同的地区不同的文字下都会出现这个问题。
于是，Unicode诞生了，Unicode有两套标准，一套叫UCS-2(Unicode-16)，用2个字节为字符编码，另一套叫UCS-4(Unicode-32)，用4个字节为字符编码。 以目前常用的UCS-2为例，它可以表示的字符数为2^16=65535，基本上可以容纳所有的欧美字符和绝大部分的亚洲字符 。在Unicode里，所有的字符被一视同仁。汉字不再使用&两个扩展ASCII&，而是使用&1个Unicode&。而ReactOS的内部完全采用Unicode这种编码。因此给中文的实现打下了良好的基础。也就是说目前的主要任务就放在了汉字的显示上。
4.2 语言和区域设置
ReactOS为适应不同地区和语言的用户以及键盘布局在注册表中设立了一个键值，用于表示用户所在的地区。（主要还是和Microsoft Windows兼容）
在系统初始化过程中会查询注册表文件用于确定系统当前所在的区域和默认的输入语言，并且根据这个配置信息来确定创建线程时的区域信息，则这个线程中的区域信息又决定了如何查找应用程序中和语言相关的资源信息。
在注册表中有几个键值是用来确定系统所在的区域，当操作系统启动后，这些设置将保存在系统的一些全局变量中，利用这些变量的值系统可以确定当启动一个应用程序时如何加载系统地缺省语言的资源文件。比如如果区域被设置成了美国地区则某个gLocale全局变量的值就是0x ，如果区域是中国则该值为0x，不过就目前的ReactOS 0.3.1版来说还是不要修改安装注册表文件中的设置。因为会导致系统在引导时失败。直接修改代码可以让系统暂时实现比较安全的中文显示，不过这是非标准的做法，以后的版本可能直接修改注册表会更方便。
找到位于(ntoskrnl/ex)的Locale.c这个文件它包含了系统和区域语言相关的函数
这个文件中包含了reactos缺省的区域
/* System IDs: EN_US */
LCID PsDefaultSystemLocaleId = 0x; //chinese 0x
LANGID PsInstallUILanguageId = LANGIDFROMLCID(0x);
/* UI/Thread IDs: Same as system */
LANGID PsDefaultUILanguageId = 0x; //chinese 0x
LCID PsDefaultThreadLocaleId = LANGIDFROMLCID(0x);
修改了上面的信息后，你基本上就不用屏蔽掉非中文资源文件，这时的应用程序会更具具体的环境来显示不同的语言。（一个应用程序是可以包含很多不同语言的资源文件的）
4.3 中文显示
4.3.1 关于字体文件freetype(truetype)
在解决中文编码后，中文的显示相对来说就要简单多了，无非就是根据中文编码查找相应的字库文件，然后将字库文件中的文字信息显示出来。
在windows中，字体的显示使用了一种叫TrueType（轮廓字体的一种）的字体文件，这种字体是设备无关字体，按轮廓存储它们可以任意调整高度，而且打印出来的效果和屏幕上显示的完全相同。
不过TrueType是必须付费的，因此不可能用在一个免费的系统中，好在GNU的开放项目中有一个叫做FreeType的项目它提供了一套TrueType的完整支持。
在中文版的windows中，系统的缺省字体是一种字体名叫&宋体&新宋体&的字体文件，在windows 2000以后这个文件的文件名叫simsun.ttc,在windows98里叫simsun.ttf，需要解释的是ttc是一种包含了多种ttf字体的集合，在这里我们需要的是ttf格式的字体文件，还需要注意的是微软的ttf文件也是有版权的，并且授权协议也不是GPL的形式，因此是不能作为Reactos的一部分来发布的，去找一种类似simsun.ttf的免费中文字体来试验一下ReactOS的中文显示，找到以后把他放入到ReactOS_root/media/fonts文件夹中，如果你不想修改太多的配置文件，我建议以相同的名字替换掉这个文件夹中已经存在的一个字体文件比如courb.ttf。
4.3.2 缺省的系统字体(系统库存字体对象)
在Windows GDI中存在作一些库存GDI对象，这些库存GDI对象中有一部分是库存的字体对象，库存字体对象的作用有一部分是为了系统本身不会平凡的创建字体而占用过多的资源。对于库存字体对象，仅仅需要调用GetStockObject（）函数就可以取出库存字体，然后再调用SelectObject（）将字体对象选入指定的设备就可以，对于中文版的ReactOS应该建立的缺省的库存字体应该是一个中文的ttf字体，因此还必须修改缺省的库存字体，而且当用户调用GetDCEx是系统需要创建一个DC这个DC会初始化一些缺省的DC信息，如：
这个文件在[ReactOS_Root/subsystems/win32/win32k/objects]下的文件找到以下文件stockobj.c编辑缺省的SystemFont库存字体对象，这个代码将在系统初始化时建立系统的库存能字体：
static LOGFONTW SystemFont =
{ 12, 0, 0, 0, FW_NORMAL, FALSE, FALSE, FALSE, GB2312_CHARSET,
&OUT_STRING_PRECIS, CLIP_STROKE_PRECIS, PROOF_QUALITY, VARIABLE_PITCH | FF_SWISS, L&simsun& }; //中文字体名，该字体必须复制到ReactOS_Root/media/fonts文件夹下，具体的字体名称不一定是simsun，要看你复制的这个ttf文件包含的字体叫什么名字。
通过这样的修改后，系统建立的就是一个支持中文的缺省的库存GDI字体对象，所有的缺省操作都将是用这个字体输出。
4.3.3 系统中可替代的字体
当用户调用CreateFont()或CreateFontIndirect()函数指定一个字体名，系统会先查找注册表中的&可替代字体名列表&如果指定的字体名存在于这个&可替代字体名列表&中，则系统会自动将替代这个指定的指定的字体名，在ReactOS的注册表中这个&可替代字体名列表&位于：ReactOS_Root/Boot/bootdata/hivesft.inf中，
HKLM,&SOFTWARE/Microsoft/Windows NT/CurrentVersion/SysFontSubstitutes处，这里列出里用于替代的字体名。如用&MS Shell Dlg&来创建一个逻辑字体，则会被替代成这里指定的字体名。
4.3.4 标题、菜单、按钮中文显示
同样在注册表中可以管理如窗口标题、菜单、按钮等的中文显示，即采用何种字体，字体的大小，颜色等各式。在ReactOS的注册表中位于一下键值部分。
文件在ReactOS_Root/boot/bootdata/hivedef.inf，编辑这个文件的
HKCU, &Control Panel/Desktop/WindowMetrics部分可以修改相对的GUI元素的逻辑字体属性。不过这些数值修改起来有点麻烦，因为是采用二进制的形式表示一个LOGFONTW的结构中各个字段。
理论上讲只要把各个GUI元素如标题条的LOGFONTW结构的lfFaceName修改成中文TTF的字体名如：&simsun&就可以在标题中显示中文，不过这样修改后依然不能显示中文。
4.3.5 ReactOS v0.3.1中存在的问题
对于上面的那个问题我在目前的v0.3.1版中找到了答案。看下面的代码：
文件是Misc.c (位于ReactOS_Root/subsystems/win32/win32k/ntuser下) 编辑这个文件找到
IntGetFontMetricSetting函数，这个函数在系统绘制标题等GUI元素的文字时调用。该函数的目的是查找绘制这些GUI元素时需要的字体信息，不过目前好像有点问题就是它在调用RtlQueryRegistryValues（）查询注册表字体信息是返回的Status总是一个FALSE这样就导致了它总是调用之后的字体缺省操作，这就是为什么会在某些窗口的菜单或按钮上看见类似&□□□□&的显示。其实看见&□□□□&符号反而可以证明你已经在显示中文了，只是在这个字体文件中没有找到这个文字而用了&□&符号做缺省替代。
RtlCopyMemory(font, &DefaultFont, sizeof(LOGFONTW));
因此中文化还要将这里改称如下的中文字体名
static LOGFONTW DefaultFont = { 12， 0， 0， 0， FW_BOLD， FALSE， FALSE， FALSE， GB2312_CHARSET， OUT_STRING_PRECIS，CLIP_STROKE_PRECIS， PROOF_QUALITY， VARIABLE_PITCH | FF_SWISS， L&simsun& }; //具体的字体名称不一定是simsun，要看你复制的这个ttf文件包含的字体叫什么名字。
这样一来即使任何操作都将产生中文的逻辑字体。
4.4 输入法
最后是输入法，中文输入法决定了系统是否支持中文的关键，因为即使是所有的显示都可以是中文，但是如果不支持中文的输入，那么说是一个中文的系统也是大打折扣，目前的ReactOS还没有任何的中文输入法，不过在ReactOS的代码中已经可以看见和IME（Input Method Editor）相关的部分，ReactOS是一个开源的项目，还需要大家的支持，也许ReactOS的中文输入法将会由你来创造。
[如需转载请注明出处:(雄)blog.csdn.net/mickey139]
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：2688次
排名：千里之外
(1)(1)(1)(1)(1)ReactOS对BIG5编码的汉字也支持不是很好？_reactos吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：778贴子：
ReactOS对BIG5编码的汉字也支持不是很好？收藏
如图，刚刚用易语言搞了一个基础程序，一个是GBK编码的，一个是BIG5编码的，都支持的不好。BIG5编码直接乱码，GBK编码标题栏显示正常，不知道这是为什么？
3D双端东方魔幻网游「大青云」勾魂公测,穿越逆转,封神故事,全新演绎!
我测试那些软件的时候，也经常出现标题显示正常，窗体内的文字乱码的现象。但ReactOS的确是BIG5标准。你是用的0.3.11，还是测试版啊？
我用的是0.3.11，测试版还没有测试。这样的话，给ReactOS搞程序很麻烦啊另外我测试Safari浏览器，安装成功，运行失败，提示一个DLL文件错误，我把那个DLL放到system 32下面仍然提示这个错误，郁闷
你的中文输入法怎么实现的？
又被审核。是不是今天日子特别啊？那个中文输入法是用的firefox的一个插件——fireinput。但，无法对整个系统搞汉字输入。NT里的DLL未必与ReactOS兼容。
刚测试过，谷歌输入法能正常安装，但无法启动。QQ拼音能安装到80%。所以不能启动。但其中的一些程序功能可以运行。南极星能正常安装和正常启动。但无法输入汉字。
我是在0.48229里面做的测试。还有个万能拼音的软件。安装到一个地方就不动了。所以也不行。
那个中文输入法是用的firefox的一个插件——fireinput。但，无法对整个系统搞汉字输入。NT里的DLL未必与ReactOS兼容。刚测试过，谷歌输入法能正常安装，但无法启动。QQ拼音能安装到80%。所以不能启动。但其中的一些程序功能可以运行。南极星能正常安装和正常启动。但无法输入汉字。
你在一楼的那个试验，用别的语言试下。例如freebasic或python。
最新的谷歌输入法在ReactOS-0.48299里面启动的时候，就会出现这些信息，然后崩溃。------------------------------------------------------(lib/rtl/actctx.c:1485) unknown element asmv2:t(lib/rtl/actctx.c:874) Unsupported yet language attribute (*)(lib/rtl/actctx.c:2007) looking for name=mon-Controls version=6.0.0.0 arch=*fixme:(dll/win32/user32/windows/cursoricon.c:1002) Copying from resource isn't implemented yetfixme:(dll/win32/user32/windows/cursoricon.c:1002) Copying from resource isn't implemented yetfixme:(dll/win32/user32/windows/cursoricon.c:1002) Copying from resource isn't implemented yetfixme:(dll/win32/user32/windows/cursoricon.c:1002) Copying from resource isn't implemented yet(lib/rtl/actctx.c:1485) unknown element asmv2:t(lib/rtl/actctx.c:874) Unsupported yet language attribute (*)(lib/rtl/actctx.c:2007) looking for name=mon-Controls version=6.0.0.0 arch=*(lib/rtl/actctx.c:1485) unknown element asmv2:t(lib/rtl/actctx.c:874) Unsupported yet language attribute (*)(lib/rtl/actctx.c:2007) looking for name=mon-Controls version=6.0.0.0 arch=*(lib/rtl/actctx.c:1485) unknown element asmv2:t(lib/rtl/actctx.c:874) Unsupported yet language attribute (*)(lib/rtl/actctx.c:2007) looking for name=mon-Controls version=6.0.0.0 arch=*fixme:(dll/win32/user32/windows/cursoricon.c:1002) Copying from resource isn't implemented yetfixme:(dll/win32/user32/windows/cursoricon.c:1002) Copying from resource isn't implemented yetfixme:(dll/win32/user32/windows/cursoricon.c:1002) Copying from resource isn't implemented yetfixme:(dll/win32/user32/windows/cursoricon.c:1002) Copying from resource isn't implemented yetfixme:(dll/win32/user32/windows/cursoricon.c:1002) Copying from resource isn't implemented yetfixme:(dll/win32/user32/windows/cursoricon.c:1002) Copying from resource isn't implemented yetfixme:(dll/win32/user32/windows/cursoricon.c:1002) Copying from resource isn't implemented yetfixme:(dll/win32/user32/windows/cursoricon.c:1002) Copying from resource isn't implemented yet------------------------------------------------------
登录百度帐号推荐应用
为兴趣而生，贴吧更懂你。或Longene与ReactOS谁跑得更远？ - 查看主题 & Ubuntu中文论坛
&[ 6 篇帖子 ]&
&文章标题 : Longene与ReactOS谁跑得更远？发表于 :
21:54帖子: 217
送出感谢: 0 次
一、Longene 是一个源自中国、自由、开源的操作系统项目，目的是要把Linux的内核扩充成一个既支持Linux应用、也支持Windows应用，既支持Linux设备驱动、也支持Windows设备驱动的兼容内核；使用户可以直接在Linux操作系统上高效运行Windows应用。Longene与 WineLongene和Wine的目标相同，手段有差异，简而言之，Wine的策略是“核内差异核外补”，Longene的策略是“核内差异核内补”（具体参见项目白皮书）。相比Wine，Longene的重点是提高软件运行的性能和效率，包括解决内核驱动兼容的问题。Wine在应用层实现的 Dll将一直是Longene项目的基石，同为开源软件，两者将是“携手发展，共同促进”的关系。Longene-0.3.0是一个具有里程碑意义的版本，Longene彻底摆脱了wineserver进程的依赖，在内核实现了wine的调用申请，现在对wine的依赖只是dll和部分 program，因此我们不再提供针对Wine的补丁，而是提供一份Wine For Longene的代码。Longene-0.3.0包括3部分代码：Linux内核补丁（Linux-2.6.30）、Longene模块代码、Wine For Longene(wine-1.0-longene)。Longene-0.3.0的运行效率与Wine相比有很大地提高（这正是Longene存在的意义之一），具体效率测试请见官方网站。Longene-0.3.0已在Ret Hat Enterprise 5.1, Ubuntu 9.04, Ubuntu10.04, Fedora 12, Redflag 6, Magic Linux 2.5-1测试通过，如你的发行版不再上述列表中，请将Longene的运行情况告诉我们，我们将十分感谢！Longene-0.3.0 的发布，可以从数据上验证了“核内差异核内补”思想的正确性，也是对项目开发初期某些对项目有质疑的爱好者最好的解释，也是对这些年来坚持参与开发的人员，最欣慰的成果。虽然Longene-0.3.0在性能上表现优异，但是我们还是要看到在安装、稳定性、兼容度等方面存在的问题，这些还需要我们持之以恒地加以优化和改进。我们欢迎广大的操作系统爱好者关注、参与到项目开发中来，真正把这个chinese base的开源项目发展壮大，成为国际性的项目，为Linux的发展添砖加瓦。二、React Operating SystemReactOS(R) 是一个基于Windows(R) XP/2003设计的自由的，现代的 操作系统。重新写了所有的代码，它的目标是从硬件到应用程序遵循微软Windows(R)架构。这不是一个基于 Linux 的系统，而且不含任何 unix 架构。ReactOS 项目的主要目标是提供一个与 Windows 执行环境兼容的操作系统。它能让你的 Windows 应用程序和驱动程序如同在 Windows 上一般运行。而且还是使用了 Windows 操作系统的外观，所以熟悉 Windows(R) 的人们使用 ReactOS 将驾轻就熟。ReactOS 的终极目标是能使你安装 ReactOS 来替代 Windows(R) 而感觉不到最终端用户体验的变化。Longene 感觉还是访ReactOS
_________________
&文章标题 : Re: Longene与ReactOS谁跑得更远？发表于 :
21:13帖子: 2089地址: Pacific Western University
送出感谢: 0 次
支持一下 没觉得wine慢，
wine存在的问题是能在wine上运行的程序太少。
&文章标题 : Re: Longene与ReactOS谁跑得更远？发表于 :
16:17帖子: 189
送出感谢: 0 次
一直幻想把wine作为linux的一部分融合到系统中去，让linux系统能够完美运行windows程序，这样从windows到linux的迁移就没有什么阻力了以前就知道ReactOS，不过一直怀疑其支持了windows软件的同时是否还支持linux软件，如果不，那就没有太多意义了觉得Longene的思路很好，从内核的角度来支持windows程序，既能提高效率，又能减少用户的操作烦恼，值得期待！
_________________东西大街南北走出门碰到人咬狗搬起狗来砸砖头却被砖头咬了手
&文章标题 : Re: Longene与ReactOS谁跑得更远？发表于 :
13:02帖子: 2339地址: 星城长沙
送出感谢: 0 次
谁现在就在用这些东东？有使用经验的来分享下。
期待任何windows的替代，把MS甩一边去
_________________安装了不吃亏^_^
&文章标题 : Re: Longene与ReactOS谁跑得更远？发表于 :
17:10帖子: 1077
送出感谢: 0 次
接收感谢: 0 次
ReactOS，不知道他们想干什么，写一个开源的windows系统？
_________________ nada is nothing我是Lavande的马甲，但是有时候，我觉得，我们不是同一个人。
&文章标题 : Re: Longene与ReactOS谁跑得更远？发表于 :
20:40帖子: 1950地址: 浙江·杭州
系统: Arch Linux
ルルティア 写道:ReactOS，不知道他们想干什么，写一个开源的windows系统？说对了！虚拟机里成功使用，但是装到真机上，屏幕显示“超频”……
_________________我是 Giumo Clanjor（哆啦比猫/兰威举） |
(C & perl5) |
显示帖子 : 全部帖子1天7天2周1个月3个月6个月1年&排序 作者发表时间文章标题 升序降序&
&[ 6 篇帖子 ]&
正在浏览此版面的用户：没有注册用户 和 0 位游客
您 不能 在这个版面发表主题您 不能 在这个版面回复主题您 不能 在这个版面编辑帖子您 不能 在这个版面删除帖子您 不能 在这个版面提交附件
选择一个版面
------------------
公告/注意事项
& &新闻和通知
& &校园社团支持
& && &华东校区
& && &华南校区
& && &华北校区
& && &华中校区
& && &东北校区
& && &西北校区
& && &港澳台校区
& && &国外校区
& &软件推荐
& &非常任务
系统安装区
& &教学和常见问答
& && &课堂教学和培训
& &初学者园地 - 16.10 - Yakkety Yak
& &系统安装和升级
& && &新立得和软件源
& && &Wubi安装讨论
& &启动和引导
& &网卡问题以及网络和拨号
& && &校园网拨号
& &笔记本、UMPC支持
& &手机和平板
& && &Ubuntu移动应用开发
& &常用硬件支持
& &系统架构支持
配置美化区
& &字体美化和中文支持
& && &个人配置文件存放点
& &桌面特效
& &窗口管理器
& &屏幕抓图
& &办公、图像、机械电子设计等
& && &Vim和Emacs
& &因特网相关软件
& &影音多媒体
& &Wine及其分支
& &游戏和游戏模拟器
& &虚拟机和虚拟化
& &其它类软件
& &开源模板库
服务器管理
& &服务器基础应用
& &数据库管理
& &服务器维护和硬件相关
& &Ubuntu VPS
参与Ubuntu开发
& &软件和文档翻译
& &编译或打包
& &Ubuntu错误报告
程序设计区
& &Shell脚本
& &GTK+和QT
& &软件/网站开发
& && &Python/Php/Perl
& && &C/C++/Java
& &内核及嵌入式开发
& &开源小工具
& &Ubuntu 17.04
& &Ubuntu 16.04 LTS
& &Ubuntu 14.04 LTS
& &Ubuntu 12.04 LTS
& &Ubuntu 10.04 LTS
& &老旧版本支持
& && &Ubuntu 15.10
& && &Ubuntu 15.04
& && &Ubuntu 14.10
衍生发行版
& &Ubuntu GNOME
& &Kubuntu
& &Xubuntu & Lubuntu
& &Ubuntu中文衍生版
& && &UbuntuKylin
& &Ubuntu国外衍生版
& && &Mint
& &Ubuntu衍生版制作
& &其它类Unix OS发行版
& && &Arch发行版
& && &Debian发行版
& && &OpenSUSE发行版
& && &Deepin
& &深度PK版
& &Ubuntu故事和感慨
& &Full Circle开源杂志
分享交流区
& &同城交流
& &线下活动专版
& &Ubuntu宣传推广
& &论坛管理
& && && &Ubuntu中文网上商店那个岛国已经有人开始做针对ReactOS的岛国文字输入法了。2010年。_reactos吧_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：778贴子：
那个岛国已经有人开始做针对ReactOS的岛国文字输入法了。2010年。收藏
3D双端东方魔幻网游「大青云」勾魂公测,穿越逆转,封神故事,全新演绎!
那个岛国已经有人开始做针对ReactOS的岛国文字输入法了。2010年。链接在此：
要是做成ibus for reactos或者scim for reactos就好了最好顺便再来个for windows
ibus和scim都是用python做的？ReactOS目前已经能运行python了。不知道移植过来的概率有多大。
搜狗无法被兼容。我测试了一大堆输入法。就谷歌和南极星，这两个的兼容性最好。但，就是无法输入汉字。ReactOS里的中文字体，是谷歌的DroidSansFallback。官方的这位大牛EmuandCo比较同意现在就加强东方语言的支持力度。但苦于没有来自东方的程序员协助。（因为他是德国人，不懂这边的情况和文字。而且他手头的工作也很多。）
我们中国就没有输入法能兼容么？实在不行可以用易语言写一个调用搜狗、QQ云输入法的软件啊
刚刚试着编了一下调用QQ云输入法，程序在Reactos下面无法启动
哎我的REACTOS还在蓝屏呢
QQ拼音输入法，我在安装的时候，到80%左右就卡住了。我个人感觉，（当然是以非计算机专业者的感觉），是不是ReactOS的钩子函数与windows不一样造成的？谷歌拼音和紫光拼音4都是IME启动就崩溃。南极星正常运行，却打不出字来。也用不了它的内码转换功能。
东方魔幻《大青云》无尽世界,谁能封神!上手简单,挂机升级,PK爽快!
刚刚又测试了个“轻舞飞扬输入法 3.1”。
界面基本无乱码。正常启动。
但无法切换到汉字输入状态。
那个是不用安装的。是某个人的私人作品。
可见，目前最关键的问题是，如何切换到汉字输入状态。
（我不是计算机专业的。有错误，还请多多包涵。）
现在看起来没有一款真正的输入法能在ReactOS下面运行。建议acat1433多试试。
看看有谁能在ReactOS下编译个FreePY输入法吧,搞得定就有希望了,不过感觉应该是系统内核的不完善导致的输入法不能用,估计没那么容易解决的……
主要是hook体制的不够完善。
可惜,感觉自己对于Windows的底层了解还不如Linux多.完全帮不了忙…………
其实官方开发成员中，有好几个都是同时在unix类和NT类环境下工作的。所以Rosbe也有unix环境下的版本。
不懂Win32的API调用机制,有编译环境给我也没有用.先看看蔡大的文章再说吧,国内可参考的ROS比较少.
可以去官网论坛。那里面经常碰的到ReactOS开发者。
登录百度帐号推荐应用
为兴趣而生，贴吧更懂你。或}