https://reactos.org/wiki/api.php?action=feedcontributions&user=68.39.174.205&feedformat=atomReactOS Wiki - User contributions [en]2024-03-19T05:36:05ZUser contributionsMediaWiki 1.31.7https://reactos.org/wiki/index.php?title=User:Ged&diff=3098User:Ged2005-03-26T00:28:50Z<p>68.39.174.205: Redirect</p>
<hr />
<div>#REDIRECT [[User:Ged]]</div>68.39.174.205https://reactos.org/wiki/index.php?title=User_talk:Mf&diff=932User talk:Mf2005-03-24T00:31:19Z<p>68.39.174.205: Question</p>
<hr />
<div>Whouldn't the Command Prompt one make more sense, since it is "C:/>" ? [[User:68.39.174.205|68.39.174.205]] 01:31, 24 Mar 2005 (CET)</div>68.39.174.205https://reactos.org/wiki/index.php?title=ReactOS_Terminal_Services&diff=938ReactOS Terminal Services2005-03-24T00:22:10Z<p>68.39.174.205: More typographicals</p>
<hr />
<div>ReactOS a featured fully multi user operating system with possibilities to log in several users at the same time. <br />
<br />
== Features ==<br />
<br />
* Multi user environment.<br />
* Possibility to log on remotely or locally via any interface.<br />
* Possibility to log in several times from the same terminal.<br />
* Possibility to use two or more sets of keyboard, mouse and screen (Human Interface Device/HID) and associate a login to a certain set of HIDs.<br />
* Possibility to use RDP, Citrix, XWindows-client, Telnet or VNC as protocol/client.<br />
* Easy managemnet with possibility to take over, see and redirect a session directly from login screen.</div>68.39.174.205https://reactos.org/wiki/index.php?title=ReactOS_Terminal_Services&diff=924ReactOS Terminal Services2005-03-24T00:21:53Z<p>68.39.174.205: Typographical + formatting</p>
<hr />
<div>ReactOS a featured fully multi user operating system with possibilities to log in several users at the same time. <br />
<br />
== Features ==<br />
<br />
* Multi user environment.<br />
* Possibility to log on remotely or locally via any interface.<br />
* Possibility to log in several times from the same terminal.<br />
* Possibility to use two or more sets of keyboard, mouse and screen (Human Interface Device/HID) and associate a login to a certain set of HIDs.<br />
* Possibility to use RDP, Citrix, XWindows-client, Telnet or VNC as protocoll/ client.<br />
* Easy managemnet with possibility to take over, see and redirect a session directly from login screen.</div>68.39.174.205https://reactos.org/wiki/index.php?title=Talk:I8042prt.sys&diff=931Talk:I8042prt.sys2005-03-23T03:16:05Z<p>68.39.174.205: Reply</p>
<hr />
<div>Shouldn't the title be "i8042port" or something? I'm curious where exactly you got the title... [[User:68.39.174.205|68.39.174.205]] 00:15, 22 Mar 2005 (CET)<br />
<br />
The driver is called i8042prt.sys<br />
[[User:Tinus|Tinus]] 17:49, 22 Mar 2005 (CET)<br />
<br />
::Think it whould be better @ that page ([[i8042PRT.SYS]]) (Like [[TCPIP.SYS]] and [[AFD.SYS]])? [[User:68.39.174.205|68.39.174.205]] 04:16, 23 Mar 2005 (CET)</div>68.39.174.205https://reactos.org/wiki/index.php?title=Talk:I8042prt.sys&diff=880Talk:I8042prt.sys2005-03-21T23:15:56Z<p>68.39.174.205: Question about the title</p>
<hr />
<div>Shouldn't the title be "i8042port" or something? I'm curious where exactly you got the title... [[User:68.39.174.205|68.39.174.205]] 00:15, 22 Mar 2005 (CET)</div>68.39.174.205https://reactos.org/wiki/index.php?title=I8042prt.sys&diff=929I8042prt.sys2005-03-21T23:14:36Z<p>68.39.174.205: Link something.</p>
<hr />
<div>i8042prt.sys is a driver for the ps/2 ports commonly found on pc's.<br />
<br />
The ps/2 ports are controlled by a chip that was made by [http://www.intel.com/ Intel], the Intel 8042. It is some kind of a bus, that uses one port to talk to the controller and another one to talk to the devices. The devices have separate interrupts so they can notify the system when they have something to say. When that interrupt is received though, communication happens through the same port for both devices.<br />
<br />
This means that there has to be a driver that coordinates access to these devices, or there will be problems when for example you move your mouse while you press a key that turns on one of the keyboard leds.<br />
<br />
The Windows i8042prt driver is pretty much documented on [http://msdn.microsoft.com/ MSDN]. Most of the documented stuff should work in the [[ReactOS]] driver too, so hopefully third-party drivers, like for touchpads and other weird mice, can be made to work.</div>68.39.174.205https://reactos.org/wiki/index.php?title=Voting/Miscelanea_branches&diff=854Voting/Miscelanea branches2005-03-19T15:14:10Z<p>68.39.174.205: Linked names</p>
<hr />
<div>[http://reactos.com:8080/archives/public/ros-dev/2005-March/002119.html Mailing list thread]<br />
<br />
Should we allow branches (other than trunk) with mixed new development and bugfixes unrelated to the new development that is on the branch (miscelanea branches) ?<br />
<br />
----<br />
<br />
''Yes, do allow miscelanea branches''<br />
* [[arty]]<br />
* [[royce3]]<br />
* [[ion]]<br />
<br />
3 votes<br />
<br />
Points:<br />
<br />
* You can have a version control enabled private space where you can work and not disturb other developers.<br />
<br />
----<br />
<br />
''No, don't allow miscelanea branches''<br />
* [[navaraf]]<br />
* [[gvg]]<br />
* [[hbirr]]<br />
* [[w3seek]]<br />
* [[gdalnes]]<br />
* [[ea]]<br />
* [[chorns]]<br />
* mf (Martin)<br />
<br />
7 votes<br />
<br />
Points:<br />
<br />
* It's nearly impossible to keep track of all changes happening on miscelanea branches. When one commits 15 files in EX/, 17 files in IO/ and bunch of other stuff with changelog message "My kernel fixes, new apis, reformatting, commenting, documenting, reorganizing, bug fixing, optimizing patch." it's just impossible to review. Especially mixing reformating patches with other changes makes reviewing much harder...<br />
<br />
* When one tries to boot ReactOS of a miscelanea branch and it doesn't work for him there's (almost) no way to track it down. One has to use conventional debugging methods. For feature branches[1] one at least knows where to start looking at and it's often possible to pinpoint the problems by just looking at the .diffs.<br />
<br />
* Merging miscelanea branches at one time to trunk causes only chaos. If a miscelanea branch has modification to all components ranging from win32k, kernel, TCP/IP to UM kernel32 changes. Would you really want to merge the 800Kb diff at once?<br />
<br />
* Bugs that that could have been fixed on trunk are annoying to trunk developers. The bugfixes that go only to the branch are not in trunk (until merged there from the branch) where most developers work and is thus annoying to these developers.<br />
<br />
* There is an added risk of duplicating work. We'll have more branches to track bugfixes on so it's harder to know which bugs has been fixed and which hasn't.<br />
<br />
* One can usually avoid using miscelanea branches by using more feature branches which can be merged to trunk earlier (which is especially important for bugfixes).<br />
<br />
* To get what is demanded by "You can have a version control enabled private space where you can work and not disturb other developers" you can install and use SVK to version control your local changes. Later on you can merge back your bug fixes and ready new features to the main repository. Using SVK it's even possible to sync the latest trunk changes into the local SVK repository.<br />
<br />
[1]<br />
* Release branch. Usually created some time before a release to have a more stable product at the time of a release. Only bugfixes go to this branch.<br />
<br />
* Feature branch. Usually created to achieve a well-defined purpose (e.g. the implementation of a new feature). Only changes required to achieve the well-defined purpose are committed to this branch.<br />
<br />
* Miscelanea branch. A combination of release and feature branches.</div>68.39.174.205https://reactos.org/wiki/index.php?title=Miscelanea_branches&diff=5955Miscelanea branches2005-03-19T15:10:38Z<p>68.39.174.205: Redirect</p>
<hr />
<div>#REDIRECT [[Voting/Miscelanea branches]]</div>68.39.174.205https://reactos.org/wiki/index.php?title=Voting/Miscelanea_branches&diff=829Voting/Miscelanea branches2005-03-19T15:10:14Z<p>68.39.174.205: Moved from the old page</p>
<hr />
<div>[http://reactos.com:8080/archives/public/ros-dev/2005-March/002119.html Mailing list thread]<br />
<br />
Should we allow branches (other than trunk) with mixed new development and bugfixes unrelated to the new development that is on the branch (miscelanea branches) ?<br />
<br />
----<br />
<br />
''Yes, do allow miscelanea branches''<br />
* arty<br />
* royce3<br />
* ion<br />
<br />
3 votes<br />
<br />
Points:<br />
<br />
* You can have a version control enabled private space where you can work and not disturb other developers.<br />
<br />
----<br />
<br />
''No, don't allow miscelanea branches''<br />
* navaraf<br />
* gvg<br />
* hbirr<br />
* w3seek<br />
* gdalnes<br />
* ea<br />
* chorns<br />
* mf (Martin)<br />
<br />
7 votes<br />
<br />
Points:<br />
<br />
* It's nearly impossible to keep track of all changes happening on miscelanea branches. When one commits 15 files in EX/, 17 files in IO/ and bunch of other stuff with changelog message "My kernel fixes, new apis, reformatting, commenting, documenting, reorganizing, bug fixing, optimizing patch." it's just impossible to review. Especially mixing reformating patches with other changes makes reviewing much harder...<br />
<br />
* When one tries to boot ReactOS of a miscelanea branch and it doesn't work for him there's (almost) no way to track it down. One has to use conventional debugging methods. For feature branches[1] one at least knows where to start looking at and it's often possible to pinpoint the problems by just looking at the .diffs.<br />
<br />
* Merging miscelanea branches at one time to trunk causes only chaos. If a miscelanea branch has modification to all components ranging from win32k, kernel, TCP/IP to UM kernel32 changes. Would you really want to merge the 800Kb diff at once?<br />
<br />
* Bugs that that could have been fixed on trunk are annoying to trunk developers. The bugfixes that go only to the branch are not in trunk (until merged there from the branch) where most developers work and is thus annoying to these developers.<br />
<br />
* There is an added risk of duplicating work. We'll have more branches to track bugfixes on so it's harder to know which bugs has been fixed and which hasn't.<br />
<br />
* One can usually avoid using miscelanea branches by using more feature branches which can be merged to trunk earlier (which is especially important for bugfixes).<br />
<br />
* To get what is demanded by "You can have a version control enabled private space where you can work and not disturb other developers" you can install and use SVK to version control your local changes. Later on you can merge back your bug fixes and ready new features to the main repository. Using SVK it's even possible to sync the latest trunk changes into the local SVK repository.<br />
<br />
[1]<br />
* Release branch. Usually created some time before a release to have a more stable product at the time of a release. Only bugfixes go to this branch.<br />
<br />
* Feature branch. Usually created to achieve a well-defined purpose (e.g. the implementation of a new feature). Only changes required to achieve the well-defined purpose are committed to this branch.<br />
<br />
* Miscelanea branch. A combination of release and feature branches.</div>68.39.174.205https://reactos.org/wiki/index.php?title=Talk:Programming_Guidelines&diff=5940Talk:Programming Guidelines2005-03-18T03:59:03Z<p>68.39.174.205: Reply</p>
<hr />
<div>AAAAAAArrrrrrrrrggggggggggggg that's ugly.<br />
<br />
:Then FFFFFiiiiiiiiiiixxxxx it! It's a Wiki! (I note you've done something though, good work). [[User:68.39.174.205|68.39.174.205]] 01:01, 13 Mar 2005 (CET)<br />
<br />
::I don't know what to do. Is there any command to tell the wiki no to create an index ?<br />
<br />
:::If you mean the table of contents stick <nowiki>__NOTOC__</nowiki> it somewhere (Beginning or end preferred) [[User:68.39.174.205|68.39.174.205]] 08:32, 14 Mar 2005 (CET)<br />
<br />
:::Done. I've also moved the goto think here.<br />
----<br />
* Don't use "goto" in C-Code (if you feel you need this in C, then you should use ASM instead)<br />
This is debatable. There are situations where goto avoids code duplication or other uglinesses. Make sure the flow of execution is clear and logical, do not use weird tricks. Other people reading your code should be able to see what's going on.<br />
<br />
Typically the opinion is based on Dijkstra's [http://doi.acm.org/10.1145/362929.362947 Go to statement considered harmful] letter. [http://doi.acm.org/10.1145/356635.356640 Structured Programming with go to Statements] is an interesting rebuttal of this letter by Donald Knuth.<br />
<br />
== 3d level headlines ==<br />
<br />
I don't agree with these changes. What's the point of only using 3d level headlines? If you don't like the way they look, change the stylesheet/templates, not the pages.<br />
<br />
Also I don't see the problem with having a TOC. It's useful for reading longer documents like this one.<br />
[[User:Tinus|Tinus]]<br />
<br />
:: 2nds seem to be better for this, except for the things that have nothing under the headings. However I can see why the TOC in this page whould be undesirable.</div>68.39.174.205https://reactos.org/wiki/index.php?title=Programming_Guidelines&diff=806Programming Guidelines2005-03-18T03:56:34Z<p>68.39.174.205: Formatting</p>
<hr />
<div>__NOTOC__<br />
See http://www.microsoft.com/resources/practices/ for Microsoft's take on best coding practices.<br />
<br />
Here are some hints to write good code,<br />
originally collected in the context of the ReactOS project.<br />
<br />
'''Always remember these guidelines:'''<br />
<br />
== It's more important to be correct than to be fat ==<br />
Premature optimization is the root of all evil.<br />
<br />
With respect to writing time and memory efficient programs, I would put forward that one should not concern themselves with execution speed while building code. Such concerns will be mostly a waste of time. Build the program to be robust and easily maintainable, then if it exhibits performance that is not acceptable profile it and improve only those sections that most need to be optimzed. -RexJolliff<br />
<br />
== Write thread safe code ==<br />
Especially be aware of this if you write a library. Your library may be used by an MT-application. This applies anyway to the kernel, since the kernel is a library which has to be thread-save per se.<br />
<br />
What differentiates thread safe code from thread unsafe code is the use of global variables. Thread safe code avoids nearly all global variables. This includes also local static variables and class variables. One has to decide carefully wether a variable or data structure is local, thread-global or process-global. Try to eliminate global variables. If this isn't possible and you need a thread-global varable then thread local storage (TLS) is the right thing. If you need a process global variable, then the right thing is a classic global variable. However don't forget to declare it with the volatile modifier. If you don't declare it as volatile, it may happen that two threads hold a copy of the variable in their contexts. So data consistency may not be guaranteed. <br />
<br />
Global data structures are little more difficult. A thread-global structure like a list is no problem, since only the owning thread knows about it. However a process-global structure which gets accessed by multiple threads needs more care. You have to synchonize the accesses of the threads with so called synchronization objects the kernel provides. These help your threads to guarantee a mutual exclusive access to common used data structures. The Mutex is commonly used for this purpose. One Mutex per list is mostly ok. However if such a structure gets accessed very hard, one should consider to use more than one Mutex. One per element is a waste of resources. So using Mutexes for several ranges would be a good compromise.<br />
<br />
The same applies to kernel-mode. It's just harder to do and one uses spinlocks to even synchonize threads over multiple processors.<br />
<br />
volatile int really_global_i;<br />
DWORD tlsi = TlsAlloc();<br />
TlsSetValue( tlsi, 95 );<br />
<br />
Short:<br />
* Avoid global variables.<br />
* Use TLS for thread-global variables.<br />
* Find the right synchronisation granularity for global structures.<br />
* Write multiprocessor-aware code<br />
<br />
== Use multithreading where possible and useful but judicious ==<br />
Multithreading is not the holy grail. However there exist multiple examples out in the world where MT would have been appropriate. Win32-GUI apps usually have one GUI-thread and a bunch of workingthreads. It's also possible to have many GUI-threads but this gets complex very fast; if you don't take precautions it is not allowed to touch the GUI from more than one thread.<br />
<br />
It's not that simple to write MT-GUI-apps. However some things are just intuitively threadable, so have a try. <br />
<br />
Another thing are server applications. It's just a have to for server apps to be multi-threaded. Fortunately it is no big problem to make a server use multiple threads. However using too many threads is not good, either, a better strategy is to have a pool of sleeping server threads. If a request arrives, it is queued and dispatched to one of the threads. Win32 provides for this purpose the so called I/O-Completion ports. Using this mechanism, all this dispatch and queue work is a minor matter for you.<br />
<br />
Using multiple threads wich execute the same code in parallel lead us to another problem. If such a program is run on an SMP or an SMT capable system, a so called cache-aliassing happens. Processor caches are organized in so called cache lines, each of which consists of 32, 64 or more bytes. These lines are circular mapped to memory addresses. Result is that addresses that, map to the same cache line, repeat all 8MB or so. <br />
<br />
On SMT systems this means that two threads with the same memory access pattern hinder each other. Same memory access pattern happens if the same code was started nearly at the same time and the memory places are 8MB off.<br />
<br />
On SMT systems this means that if a thread reads a byte, the processor loads the whole cache line. The same happens on the other virtual processor but some MB off (which maps to the same cache-line). Next time the first processor acceses its address again.<br />
Now these two processors have to sync their caches with each other. This happens again and again. Result is that such a program runs faster on an uniprocessor system :-( This gets even worse on SMT-systems, because the two virtual processors share the same cache.<br />
This means also SMT and Cache-aliassing.<br />
<br />
== Try to open files shared (esp. SHAREMODE_DELETE) ==<br />
== Make programs support multiple instances ==<br />
== Avoid data corruption on crashes ==<br />
== Write preemptible code ==<br />
== Use spinlocks rarely but where needed ==<br />
== Raise IRQL as short as possible - think of writing an DPC ==<br />
== Write time and memory efficient programs ==<br />
This conflicts with the earlier statement about optimizations. Keep in mind that that statement does not mean you should waste memory or cycles though.<br />
<br />
== Remember [[Unicode]]/non-Unicode ==<br />
== Don't hardcode English phrases into source code - if you must, collect them in one place (easier to localise) ==<br />
== Don't create a thread per connected user, use I/O Completion Ports instead ==<br />
<br />
Having one thread to serve all users is a bad idea. It forces users to wait an undefined time rather than being served slower. A solution is to create one thread for every user. However this is a bad idea, too. It's OK if you serve a determinable maximum of queries. But if you can't determine how many queries will arive, you better use the comfortable I/O Completion Ports. The thing with creating one and another server thread is: Mostly your thread does I/O operations (HD access). Invoking too many threads doesn't hurt the OS but your I/O subsystem. You get something like thrashing. The single thread's I/Os hinder each other to be finished and the whole thing gets slower and capacity melts.<br />
<br />
So restricting to a number of server threads is the best idea. One could program such a behaviour by hand or use the I/O completion ports.<br />
Example:<br />
<br />
== Think of changing writing directions ==<br />
Left to right reading order is not the only direction to read and write text on the globe. There exist also right to left reading order as in Hebrew and top to down reading order as in Japanese. Whereas one legal reading order in Japanese is also left to right. So you can restrict yourself to these two orders. This means that <help me><br />
<br />
== Create a GUI with layoutmanager rather than pixel positioning of controls ==<br />
If you use pixel positioning of controls, your GUI will no longer look right if the texts change due to localisation, if the user selects a font you didn't expect (like large fonts for the visually impaired) and if the writing direction changes. Also probably your dialogs will not be resizable.<br />
<br />
== Write time and memory efficient programs ==<br />
Memory sizes get always bigger and processors get always faster. But programs get always less efficient. OK, enough. This seems to be just an advice, because everyone has to decide and design ones application by ones own. At least these hints: Keep in mind that you can use memory mapped files. This gives you easier access to your file data and you do not have to rebuild the whole data world in memory. This is a thing you should always avoid: like some bad games, occupy one gig on HD and if started, the same amount in swapspace. If you work object oriented, use references for object parameters. This avoids a copy constructor to be called twice. One time for the temporal object, one time for the higher level variable. Avoid copying of redundant data through an object hierarchy. This means, do not pass a set of variables to the next deeper object and so on but use an intelligent design with pointers.<br />
<br />
== Avoid memory leaks ==<br />
Easier said than done. Memory leaks are always an offense. There's nothing one can really do to never have a memory leak. However take these hints. You can use a language which has a garbage collector, like Eiffel. In C, your only option is to be more careful and always write pairs of malloc and free or use reference counting. If you use C++ there exist the techniques of auto pointers and smart pointers. For how to use them, see the corresponding literature.<br />
<br />
-- There are [http://www.hpl.hp.com/personal/Hans_Boehm/gc/ garbage collectors for C and C++] - Jakov<br />
<br />
== Put plenty of comments into your code ==<br />
* think of block comments which explain a whole module and the play tog.<br />
<br />
== Find the right balance between abstraction and straight forward ==<br />
Abstraction is a useful programming concept. It's easy to overdo it though.<br />
<br />
== Don't make redundant copies of program data ==<br />
If you copy a piece of code you will have to maintain the code twice. Typically people working on your code will only work on one of the copies, so you have to make sure they keep in sync.<br />
<br />
* to be continued....... <br />
<br />
== If using assembler, always implement an alternative way in C or what you use ==<br />
ReactOS is or will be a multi platform OS. Having nice fast assembler pieces for time critical operations is good. However there has to be an alternative written in C, always. Only this guarantee enables ROS to compile on every of it's target platforms. At last one hint: The first goal is always to make a piece of code running. If we find this piece to be a bottleneck, we'll optimize it and possibly write it in assembler.<br />
<br />
== Preserve the meta information of files you use ==<br />
On ReactOS-filesystems files may have lots of additional information. This includes timestamps, attributes, access control lists, multiple filestreams and extended attributes. Not every filesystem provides every feature. But if it does, it is annoying for a user who works with these pieces of information, if a program destroys the meta information. At most this happens when copying or packing files or when saving a file. These programs just create a new file and store the content from the old one to the new. Afterwards they delete the old and rename the new one. Generally the optimal way would be to memory map the original and use its mapped data to directly for r/o access. If changes are required, because the user works with the program, a self made copy-on-write mechanism goes on and makes a working copy. If the user wants to save his changes, the changed structures are written back through the memorymapping.<br />
<br />
If this is not an alternative for you, remember to use the parameter hTemplateFile of the CreateFile call.<br />
<br />
== Do not use absolute paths; don't imply path names ==<br />
Ever used one of these programs that can only be installed on the C drive? Obvious but quite annoying, isn't it?<br />
<br />
As you know, drive letters (what a pain) vary from system to system. So including drive letters in paths is bad. Rather use relative paths or local paths. Also paths are no axioms on windows systems. The „Program files“-directory for example changes it's spelling from localization to localization. On Win32 there do exist the functions GetWindowsDirectory, GetSystemDirectory, SHGetPathFromIDList, SHGetSpecialFolderPath and SHGetFolderPath. With these functions you can resolve the differences between the single installations and localizations.</div>68.39.174.205https://reactos.org/wiki/index.php?title=Build_Environment&diff=807Build Environment2005-03-17T21:29:58Z<p>68.39.174.205: Fix bad, as yet unused, link</p>
<hr />
<div>*How to [http://vmlinux.org/jakov/ros/cross_mingw.html Cross Compile to MinGW] on Linux/BSD<br />
<br />
<br />
== Required files ==<br />
<br />
For latest releases go to http://www.mingw.org/download.shtml and download the following files:<br />
* [http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download MinGW-3.1.0-1.exe]<br />
* [http://prdownloads.sf.net/mingw/gcc-core-3.3.3-20040217-1.tar.gz?download gcc-core-3.3.3-20040217-1.tar.gz]<br />
* [http://prdownloads.sf.net/mingw/gcc-g++-3.3.3-20040217-1.tar.gz?download gcc-g++-3.3.3-20040217-1.tar.gz]<br />
* [http://prdownloads.sf.net/mingw/w32api-2.5.tar.gz?download w32api-2.5.tar.gz]<br />
* [http://prdownloads.sourceforge.net/mingw/binutils-2.15.94-20050118-1.tar.gz?download binutils-2.15.94-20050118-1.tar.gz]<br />
* [http://www.kernel.org/pub/software/devel/nasm/ NASM]<br />
<br />
If you wish to use GCC 3.4.1, instead, please see the [[GCC 3.4.1 Issues]] page. Please note that newer binutils packages namely 2.15.9x have problems with forward linking export functions and therefore will not build ReactOS properly.<br />
<br />
You can also try the ReactOS Build Environment Setup - it includes everything (compiler, linker, ...) which is needed to build ReactOS:<br />
* [http://blight.reactos.at/reactos-be/ReactOS%20Build%20Environment%200.1-3.4.2.exe ReactOS Build Environment 0.1-3.4.2.exe]<br />
<br />
== Building ReactOS ==<br />
<br />
Run the make file from the root directory of ReactOS. In order to build a bootable ISO image, you must first build freeldr then run "make install" ; next you must run "make bootcd" from the root ReactOS directory. The ISO image will be located in the root ReactOS directory when it is finsihed.<br />
<br />
== Installation ==<br />
<br />
First run MinGW-3.1.0-1.exe then unpack the other tarballs into the directory which you had installed MinGW.<br />
<br />
== Optional stuff ==<br />
<br />
'''Subversion Client'''<br />
<br />
Get yourself a Subversion client and download the sources from the Subversion repository.<br />
<br />
'''Patching'''<br />
<br />
You can use WinMerge to see changes in source code visually. This is particularly useful for submitting and reviewing patches.<br />
<br />
* [http://prdownloads.sourceforge.net/winmerge/WinMergeSetup.2.1.5.14.exe?download WinMergeSetup.2.1.5.14.exe]<br />
<br />
# Create a new directory. For example ''C:\mingw''.<br />
# Extract the files mentioned above in the directory you just created. It is important that you extract ''gcc-update.zip'' last because it overwrites the buggy ''gcc.exe'' from ''gcc-2.95.3-fastcall.zip''.<br />
# In your install directory (''C:\mingw'' in this example), you fill find the file ''mingw32.bat''. Change the line that updates the ''PATH'' variable according to your install directory (add ''C:\mingw\bin'' in this example).<br />
# Run ''mingw32.bat'' before you want to use mingw. You can call it from ''autoexec.bat'' or you can call it whenever you open a shell window.<br />
<br />
== See also ==<br />
*[[Build Troubleshooting]]<br />
*[[HOWTO/setup a build environment for Windows]]<br />
*[[HOWTO/setup a build environment for Linux]]</div>68.39.174.205https://reactos.org/wiki/index.php?title=ChangeLog-0.2.6&diff=816ChangeLog-0.2.62005-03-17T21:28:49Z<p>68.39.174.205: Removed unneeded _s</p>
<hr />
<div>The changelog for 0.2.6 in terms meaningful to technical end-users.<br />
<br />
== Generic ==<br />
* NVIDIA OpenGL hardware acceleration works ([[Gregor Anich]])<br />
<br />
== FREELDR ==<br />
== HAL ==<br />
== NTOSKRNL ==<br />
* Rewritten Kernel Debugger ([[Gregor Anich]])<br />
<br />
== ATAPI ==<br />
* Works now with HDDs larger than 128 GB<br />
<br />
== ADVAPI32 ==<br />
== KERNEL32 ==<br />
== PSAPI ==<br />
== CRTDLL ==<br />
* Most old stuff deleted. Now share source with msvcrt via crt.lib<br />
<br />
== MSVCRT ==<br />
* Everything moved into crt.lib<br />
<br />
== VFAT ==<br />
== WIN32K ==<br />
implement NtGdiDdGetDriverInfo and NtGdiDdWaitForVerticalBlank<br />
untested yet, (for directx) Magnus Olsen<br />
<br />
== Networking ==<br />
* FTP Client ported from BSD ([[Steven Edwards]])<br />
* Tracert Client ported from BSD ([[Steven Edwards]])<br />
<br />
== NDIS ==<br />
== PCNET ==<br />
== EXPLORER/WINEFILE ==<br />
<br />
* support for owner drawn context menus<br />
* changed icon symbols<br />
<br />
== IBROWSER ==<br />
<br />
* added simple web browser application derived from ROS Explorer<br />
* simple file -> open menu (sedwards)<br />
<br />
== DirectX ==<br />
* fix some bugs in GetDeviceData, the mouse is working in Unreal Tourment, and many more directx apps that are working under reactos. (Magnus Olsen)<br />
<br />
== Libraries shared with Wine ==<br />
More merging<br />
* Better OLE/DCOM Support<br />
* MSI/Windows Installer support<br />
* Richedit Support<br />
* Tons of Unicode conversion<br />
<br />
== SMSS ==<br />
<br />
* Session manager actually beginning manage environment subsystems.<br />
* Progress in booting kernel mode and user mode environment subsystem from the registry.<br />
<br />
== CSRSS ==<br />
<br />
Initial code to register itself in the SM as the environment subsystem server for Win32 console programs.<br />
<br />
== USER32 ==<br />
<br />
== SHELL32 ==<br />
<br />
* launching of display properties dialog by using the desktop context menu<br />
<br />
== FMIFS ==<br />
== VGA ==<br />
== RTL ==<br />
== USB ==<br />
* Drivers from Linux (Cromwell actually) are ported to ReactOS, and OHCI host controller driver is now working fine. However no class drivers has been developed yet, so no usb devices work right now. Next release (0.3.0) will have support for USB keyboards and mice, and also quite more popular UHCI controller. ([[Aleksey Bragin]])<br />
<br />
== VIDEOPRT ==<br />
<br />
* NVIDIA Windows 2000 driver works</div>68.39.174.205https://reactos.org/wiki/index.php?title=User:Sedwards&diff=5903User:Sedwards2005-03-17T21:27:56Z<p>68.39.174.205: Fix annoying date runtogether</p>
<hr />
<div>== Life before ReactOS ==<br />
<br />
I was born (1982-02-07) and had a life before ReactOS. Ask me about it sometime.<br />
<br />
== My work with the ReactOS Project ==<br />
Wine related work:<br />
My day job on the support team at CodeWeavers allows me freedom to work with both the Wine and ReactOS community to find modules the two projects can share.<br />
<br />
== About my personal life ==<br />
<br />
Steven Edwards can be reached at sedwards@reactos.org. His blog is at: http://blogs.reactos.com/sedwards/</div>68.39.174.205https://reactos.org/wiki/index.php?title=Talk:Programming_Guidelines&diff=767Talk:Programming Guidelines2005-03-14T07:32:47Z<p>68.39.174.205: Fix reply</p>
<hr />
<div>AAAAAAArrrrrrrrrggggggggggggg that's ugly.<br />
<br />
:Then FFFFFiiiiiiiiiiixxxxx it! It's a Wiki! (I note you've done something though, good work). [[User:68.39.174.205|68.39.174.205]] 01:01, 13 Mar 2005 (CET)<br />
<br />
::I don't know what to do. Is there any command to tell the wiki no to create an index ?<br />
<br />
:::If you mean the table of contents stick <nowiki>__NOTOC__</nowiki> it somewhere (Beginning or end preferred) [[User:68.39.174.205|68.39.174.205]] 08:32, 14 Mar 2005 (CET)</div>68.39.174.205https://reactos.org/wiki/index.php?title=Talk:Programming_Guidelines&diff=761Talk:Programming Guidelines2005-03-14T07:32:28Z<p>68.39.174.205: Reply</p>
<hr />
<div>AAAAAAArrrrrrrrrggggggggggggg that's ugly.<br />
<br />
:Then FFFFFiiiiiiiiiiixxxxx it! It's a Wiki! (I note you've done something though, good work). [[User:68.39.174.205|68.39.174.205]] 01:01, 13 Mar 2005 (CET)<br />
<br />
::I don't know what to do. Is there any command to tell the wiki no to create an index ?<br />
<br />
:::If you mean the table of contents stick __NOTOC__ it it somewhere (Beginning or end preferred) [[User:68.39.174.205|68.39.174.205]] 08:32, 14 Mar 2005 (CET)</div>68.39.174.205https://reactos.org/wiki/index.php?title=File_Systems/ReiserFS&diff=1750File Systems/ReiserFS2005-03-13T00:05:12Z<p>68.39.174.205: Minor formatting</p>
<hr />
<div>'''Reiser FS''' is a popualar [[file system]] developed by Namesys. The term "Reiser" and "ReiserFS" can refer to both versions 3 and 4. This page deals with both.<br />
<br />
== Version 3 (Known as "ReiserFS") ==<br />
Take a look at [http://freehost19.websamba.com/slacker2k2/rfstoolgui/ this].<br />
<br />
== Version 4 (Known as "Reiser4") ==<br />
ReiserFS is a new "from scratch" version of the '''ReiserFS''' file system,<br />
<br />
It has the following advanced features: <br />
* efficient support of small files, in terms of disk space and speed<br />
* fast handling of large and very large directories with hundreds of millions of files, <br />
* flexible plugin infrastructure, <br />
* [[wikipedia:Atomic transaction|atomic]] file system modification, <br />
* efficient journaling through wandering logs, <br />
* dynamically optimized disk-layout (through allocate-on-flush, and online repacker)<br />
* Integration of metadata into the file system name-space.<br />
<br />
Additionally, Reiser4 introduces [[wikipedia:Dancing trees|dancing trees]], a version of [[wikipedia:B*-tree|B*-trees]] with the key difference being that underpopulated nodes won't get merged until a flush to disk is forced by low memory or a completed transaction. Such a system also allows Reiser4 to create files and directories without having to waste time and space through fixed blocks. Compare this to [[Microsoft]]'s [[File Systems/FAT32|FAT]] filesystem.<br />
<br />
Benchmarks performed by Namesys show that Reiser4 is 10 to 15 times faster than [[File Systems/ext3|ext3]] working on files smaller than 1Kb. As of 2004, it is not supported on many Linux distributions, although its predecessor is.<br />
<br />
=== Reiser4 source code ===<br />
<br />
* [ftp://ftp.namesys.com/pub/reiser4progs File system utilities]<br />
<br />
* [ftp://ftp.namesys.com/pub/reiser4progs/grub/ grub patches (may be usable for freeloader support)]<br />
<br />
* [ftp://ftp.namesys.com/pub/reiser4-for-2.6/ fs driver source for linux 2.6]</div>68.39.174.205https://reactos.org/wiki/index.php?title=Talk:Programming_Guidelines&diff=745Talk:Programming Guidelines2005-03-13T00:01:58Z<p>68.39.174.205: Reply</p>
<hr />
<div>AAAAAAArrrrrrrrrggggggggggggg that's ugly.<br />
<br />
:Then FFFFFiiiiiiiiiiixxxxx it! It's a Wiki! (I note you've done something though, good work). [[User:68.39.174.205|68.39.174.205]] 01:01, 13 Mar 2005 (CET)</div>68.39.174.205https://reactos.org/wiki/index.php?title=File_Systems/ReiserFS&diff=722File Systems/ReiserFS2005-03-10T22:46:00Z<p>68.39.174.205: Reply</p>
<hr />
<div>Start porting (:<br />
<br />
[Semyon "tapak" Novikov]<br />
----<br />
:do you mean v.3 or v.4 reiser?<br />
:i just moved this page to reiserfs 3 now as i wanted a clear difference between both file systems. --[[User:Pythagoras1|Pythagoras1]] 10:53, 10 Mar 2005 (CET)<br />
::Why? You can use == sections == to have both 3 and 4 on the same page, and isn't ReiserFS itself version 3, and Reiser4 version 4? [[User:68.39.174.205|68.39.174.205]] 23:46, 10 Mar 2005 (CET)</div>68.39.174.205https://reactos.org/wiki/index.php?title=List_of_Translators&diff=820List of Translators2005-03-03T22:48:58Z<p>68.39.174.205: Munged addr</p>
<hr />
<div>This page's intent is to collect information about translation of the website, apps and the people capable to do that.<br />
<br />
== Translation tables for languages ==<br />
According to recent decision in mailing lists, this glossary/dictionary won't exist in the Wiki, but in some other form, preferably XML document<br />
<br />
== Status of translation ==<br />
we use babelfish now, therefore the translations are ready in approximately one week<br />
:<i>Aleksey is creating logins in ezPublish for LCs to allow them to get and translate content by themselves.</i><br />
- well, ROS-explorer's already translated and multilingual now. - M-T<br />
<br />
== Things to be translated ==<br />
*Websites<br />
**User Website<br />
**Developer Website<br />
**Library<br />
<br />
*ReactOS itself<br />
<br />
== People available for certain languages ==<br />
<br />
=== Czech And Slovak ===<br />
**Filip Navara (xnavara_replace_this_by_at_volny.cz)<br />
**Fero Vlkolinsky (f.vlkolinsky_replace_this_by_at_zoznam.sk)<br />
=== Chinese ===<br />
**CaoCao (ccao_replace_this_by_at_myrealbox.com)<br />
**Larry Li (larry_replace_this_by_at_mimios.com)<br />
=== Danish ===<br />
**Tobias Ussing (tobiasthecommie_replace_this_by_at_hotmail.com_im_using_another_address_on_mail_list)<br />
=== Dutch ===<br />
**Mark IJbema (LC) ( mark@mostly-harmless.nl / vandread )<br />
**Timothy Schepens (tischepe_replace_this_by_at_fastmail.fm)<br />
**Emil (ROS_replace_this_by_at_Q-Collective.org)<br />
**Jasper van de Gronde (th.v.d.gronde_replace_this_by_at_hccnet.nl)<br />
=== Frisian ===<br />
**Jorn Nolles (jorn_replace_this_by_at_hotmail.com)<br />
=== Finnish ===<br />
**Mikael Nousiainen ( turja_replace_this_by_at_mbnet.fi / Turja )<br />
=== French ===<br />
**Rick Langschultz (absleadcoder_replace_this_by_at_cox.net)<br />
**Momo (mailtomomo_replace_this_by_at_free.fr)<br />
**Samuel (samuel.vanneste_replace_this_by_at_tiscali.fr)<br />
**Benoît (benoit.ansieau_replace_this_by_at_wanadoo.fr)<br />
=== German (de-DE) ===<br />
**Ashran (ashran_replace_this_by_at_hackersquest.org)<br />
**Theodor Reppe (theodor #AT# reppes.de)<br />
**Jorg Abderhalden (jda_replace_this_by_at_abderhalden.cx)<br />
**Bjorn Fischer (thebear80_replace_this_by_at_gmx.net)<br />
**Michael Fritscher (michael_replace_this_by_at_fritscher.net)<br />
**Thomas Weidenmueller (w3seek)<br />
**David Flechl (webmaster_replace_this_by_at_wishmaster.at)<br />
**Max (max.hohenegger_replace_this_by_at_fh-rosenheim.de)<br />
**RobertK<br />
**Fabian Kupferschmid (ich-m_replace_this_by_at_g-kein-spam.com)<br />
**Sascha Gehrke (mail_replace_this_by_at_redviper.net)<br />
**Stefan Pflueger (stefan_replace_this_by_at_homepage4us.de)<br />
**Martin Rottensteiner (martin2004_replace_this_by_at_speed-tiscali.at)<br />
**Michael Wirth (TP)<br />
**Patrick Mächler (valio_replace_this_by_at_gmx.ch / Valio)<br />
**Klemens Friedl (frik85_replace_this_by_at_hotmail dot com)<br />
**e7 (e7online %at_home_at% webºde)<br />
**Stephan Verbücheln (Erlenmayr_replace_this_by_at_gmail_dot_com)<br />
<br />
=== Greek (Hellenic) ===<br />
**Stellios Plainiotis (stelpl_anotherhotmailaccount)<br />
**jifix (jifix@mail.gr)<br />
=== Icelandic ===<br />
**Björgvin Ragnarsson (nifgraup_replace_this_by_at_hotmail.com)<br />
=== Irish Gaelic ===<br />
**Rick Langschultz (absleadcoder_replace_this_by_at_cox.net)<br />
=== Italian ===<br />
**Vincenzo Petrucci (vincenzo.petrucci_replace_this_by_at_gmail.com)<br />
**Lorenzo (garbage_replace_this_by_at_loz.it)<br />
**Federico (larsss_replace_this_by_at_jumpy.it)<br />
**Daniele (dforsi_replace_this_by_at_despammed.com)<br />
=== Japanese ===<br />
**Masahiro Taguchi (mtg_replace_this_by_at_ce.wakwak.com)<br />
=== Lithuanian ===<br />
**[[Andrius Prekevicius]] (andre_dot_g_at_delfi_dot_lt - reactos_at_projektas_dot_lt)<br />
**Kestutis Snieska (sniekest_at_saule_dot_pit_dot_ktu_dot_lt)<br />
**Mindaugas Juzenas (mynde_at_agurkas_dot_com)<br />
**Audrius Rensonas (audriuz_at_fremail_dot_lt)<br />
=== Persian ===<br />
**Hossein Noorikhah (hossein_noorikhah@yahoo.com)<br />
=== Polish ===<br />
**Jakub 'darkjames' Zawadzki (darkjames(at)darkjames(dot)ath(dot)cx)<br />
**Karol 'viod' Stelmaczonek (viod(at)op(dot)pl)<br />
<br />
=== Portuguese ===<br />
**PauloSilva (correasilvaattugamaildotpt)<br />
**João Jerónimo Barata de Oliveira (j_j_b_o AT sapo DOT pt)<br />
=== Portuguese Brasilian ===<br />
**Nabucodonosor Coutinho (aspidebr@hotmail.com)<br />
**Vitor Hugo Mattos Pereira (vhmp.web[at]gmail.com)<br />
**Bruno Souza Cabral (buscavida@terra.com.br<br />
=== Romanian ===<br />
**Alexander Ciobanu (alex_replace_this_by_at_prodidactica.md)<br />
**Sebi Onofrei<br />
=== Russian ===<br />
**Mikhail Y. Zvyozdochkin (LC) (mzvyozd_replace_this_by_at_narod.ru)<br />
**Alexander Ciobanu (alex_replace_this_by_at_prodidactica.md)<br />
**Aleksey Bragin (TC) (aleksey_replace_this_by_at_studiocerebral.com)<br />
**Semyon Novikov (tappak_replace_this_by_at_freemail.ru)<br />
=== Spanish ===<br />
**Rick Langschultz (absleadcoder_replace_this_by_at_cox.net)<br />
**Waldo Alvarez (wac_replace_this_by_at_ghost.matcom.uh.cu)<br />
**Jorge Pérez Burgos (jorge.perez_replace_this_by_at_adaptia.net)<br />
**Jacob Martin (suelyn_replace_this_by_at_email.it)<br />
**Francisco José Cañizares Santofimia (telefrancisco_replace_this_by_at_zwallet.com) [ Mother language ]<br />
**Lucio Diaz-Flores Varela (reactos_translate_replace_this_by_at_yahoo.es) [ Mother language ]<br />
**Jose Pedro Fernández Pascual (huma2000_at_terra_dot_com) [Mother language] -> Translating main site and making a spanish keyboard layout.<br />
=== Swedish ===<br />
**Jens Collin (jens.collin_replace_this_by_at_lakhei.com)<br />
**Andreas Bjerkeholt (harteex[at]gmail.com)<br />
<br />
== Examples ==<br />
It's good some of you already made examples of how the translated ReactOS would look, but it's mostly useless as it as now for us.<br />
<br />
Here is a list of how people want 'localized' ReactOS Website to look like:<br />
* http://www.mimios.com/reactos_cn.htm - asmcos/Larry Li, Chinese language, outdated<br />
<br />
I thought it was a good idea. Edit as you like. - RobertK</div>68.39.174.205https://reactos.org/wiki/index.php?title=File_Systems/ReiserFS&diff=713File Systems/ReiserFS2005-03-03T22:45:40Z<p>68.39.174.205: Mig</p>
<hr />
<div>Start porting (:<br />
<br />
[Semyon "tapak" Novikov]</div>68.39.174.205https://reactos.org/wiki/index.php?title=ChangeLog-0.2.6&diff=695ChangeLog-0.2.62005-03-03T00:39:44Z<p>68.39.174.205: Capitalization</p>
<hr />
<div>The changelog for 0.2.6 in terms meaningful to technical end-users.<br />
<br />
== Generic ==<br />
== FREELDR ==<br />
== HAL ==<br />
== NTOSKRNL ==<br />
== ADVAPI32 ==<br />
== KERNEL32 ==<br />
== PSAPI ==<br />
== CRTDLL ==<br />
Most old stuff deleted. Now share source with msvcrt via crt.lib<br />
<br />
== MSVCRT ==<br />
Everything moved into crt.lib<br />
<br />
== VFAT ==<br />
== WIN32K ==<br />
== Networking ==<br />
== NDIS ==<br />
== PCNET ==<br />
== EXPLORER/WINEFILE ==<br />
== DirectX ==<br />
== Libraries shared with Wine ==<br />
== SMSS ==<br />
Session manager actually beginning manage environment subsystems.<br />
Progress in booting kernel mode and user mode environment subsystem from the registry.<br />
== CSRSS ==<br />
== USER32 ==<br />
== FMIFS ==<br />
== VGA ==<br />
== RTL ==<br />
== USB ==<br />
Drivers from Linux (Cromwell actually) are ported to ReactOS, and OHCI host controller driver is now working fine. However no class drivers has been developed yet, so no usb devices work right now. Next release (0.3.0) will have support for USB keyboards and mice, and also quite more popular UHCI controller. ([[Aleksey Bragin]])</div>68.39.174.205https://reactos.org/wiki/index.php?title=User:Headstrong&diff=1580User:Headstrong2005-03-02T02:55:14Z<p>68.39.174.205: sp and grammar</p>
<hr />
<div>'''Headstrongs page'''<br />
<br />
I am interested in ReactOS for using on recylced computers, I cant code in C, so I just test ReactOS on real hardware, and also try to keep this Wiki in order and try to keep the forum sane.</div>68.39.174.205https://reactos.org/wiki/index.php?title=ChangeLog-0.2.6&diff=657ChangeLog-0.2.62005-03-02T02:54:14Z<p>68.39.174.205: Sp and link AB/FB</p>
<hr />
<div>The changelog for 0.2.6 in terms meaningful to technical end-users.<br />
<br />
== GENERIC ==<br />
== FREELDR ==<br />
== HAL ==<br />
== NTOSKRNL ==<br />
== ADVAPI32 ==<br />
== KERNEL32 ==<br />
== PSAPI ==<br />
== CRTDLL ==<br />
Most old stuff deleted. Now share source with msvcrt via crt.lib<br />
<br />
== MSCVRT ==<br />
Everything moved into crt.lib<br />
<br />
== VFAT ==<br />
== WIN32K ==<br />
== NETWORKING ==<br />
== NDIS ==<br />
== PCNET ==<br />
== EXPLORER/WINEFILE ==<br />
== DirectX ==<br />
== Libraries shared with Wine ==<br />
== Csrss ==<br />
== USER32 ==<br />
== FMIFS ==<br />
== VGA ==<br />
== RTL ==<br />
== USB ==<br />
Drivers from Linux (Cromwell actually) are ported to ReactOS, and OHCI host controller driver is now working fine. However no class drivers has been developed yet, so no usb devices work right now. Next release (0.3.0) will have support for USB keyboards and mouses, and also quite more popular UHCI controller. ([[Aleksey Bragin]])</div>68.39.174.205https://reactos.org/wiki/index.php?title=Build_Environment&diff=495Build Environment2005-02-24T19:36:20Z<p>68.39.174.205: Removed redundant link after making redirect</p>
<hr />
<div>*How to [http://vmlinux.org/jakov/ros/cross_mingw.html Cross Compile to MinGW] on Linux/BSD<br />
<br />
<br />
== Required files ==<br />
<br />
For latest releases go to http://www.mingw.org/download.shtml and download the following files:<br />
* [http://prdownloads.sf.net/mingw/MinGW-3.1.0-1.exe?download MinGW-3.1.0-1.exe]<br />
* [http://prdownloads.sf.net/mingw/gcc-core-3.3.3-20040217-1.tar.gz?download gcc-core-3.3.3-20040217-1.tar.gz]<br />
* [http://prdownloads.sf.net/mingw/gcc-g++-3.3.3-20040217-1.tar.gz?download gcc-g++-3.3.3-20040217-1.tar.gz]<br />
* [http://prdownloads.sf.net/mingw/w32api-2.5.tar.gz?download w32api-2.5.tar.gz]<br />
* [http://www.kernel.org/pub/software/devel/nasm/ NASM]<br />
Then go to http://sourceforge.net/projects/reactos and download binutils 2.15.90, because other versions have the INACCESIBLE_BOOT_DEVICE bug:<br />
* [http://prdownloads.sourceforge.net/reactos/binutils-2.15.90-20040222-1.tar.gz?download binutils-2.15.90-20040222-1.tar.gz]<br />
Some people are having problems with binutils 2.15.90 also (errors in shlwapi), and in those cases, upggrading to binutils 2.15.94 has fixed it:<br />
* [http://prdownloads.sourceforge.net/mingw/binutils-2.15.94-20050118-1.tar.gz?download<br />
binutils-2.15.94-20050118-1.tar.gz]<br />
<br />
If you wish to use GCC 3.4.1, instead, please see the [[Gcc 341 Issues]] page. Please note that newer binutils packages namely 2.15.9x have problems with forward linking export functions and therefore will not build ReactOS properly.<br />
<br />
== Building ReactOS ==<br />
<br />
Run the make file from the root directory of ReactOS. In order to build a bootable ISO image, you must first build freeldr then run "make install" ; next you must run "make bootcd" from the root ReactOS directory. The ISO image will be located in the root ReactOS directory when it is finsihed.<br />
<br />
== Installation ==<br />
<br />
First run MinGW-3.1.0-1.exe then unpack the other tarballs into the directory which you had installed MinGW.<br />
<br />
== Optional stuff ==<br />
<br />
'''Subversion Client'''<br />
<br />
Get yourself a Subversion client and download the sources from the Subversion repository.<br />
<br />
'''Patching'''<br />
<br />
You can use WinMerge to see changes in source code visually. This is particularly useful for submitting and reviewing patches.<br />
<br />
* [http://prdownloads.sourceforge.net/winmerge/WinMergeSetup.2.1.5.14.exe?download WinMergeSetup.2.1.5.14.exe]<br />
<br />
# Create a new directory. For example ''C:\mingw''.<br />
# Extract the files mentioned above in the directory you just created. It is important that you extract ''gcc-update.zip'' last because it overwrites the buggy ''gcc.exe'' from ''gcc-2.95.3-fastcall.zip''.<br />
# In your install directory (''C:\mingw'' in this example), you fill find the file ''mingw32.bat''. Change the line that updates the ''PATH'' variable according to your install directory (add ''C:\mingw\bin'' in this example).<br />
# Run ''mingw32.bat'' before you want to use mingw. You can call it from ''autoexec.bat'' or you can call it whenever you open a shell window.<br />
<br />
== See also ==<br />
*[[Build Troubleshooting]]<br />
*[[HOWTO/setup a build environment for Windows]]<br />
*[[HOWTO/setup a build environment for Linux]]</div>68.39.174.205https://reactos.org/wiki/index.php?title=0.2.6&diff=4640.2.62005-02-24T19:34:24Z<p>68.39.174.205: Formatting</p>
<hr />
<div>== Changes to be made for/before this release ==<br />
<br />
=== Bugs to be fixed ===<br />
<br />
* Fix Jims ATA Zip drive regressions.<br />
* Track down the location of steves kernel lockup on Dell Latitude C610.<br />
* Check PeakMessage crash when double clicking on top left-hand corner of taskmgr.<br />
* Fix ctrl+c/crtl+z in console.<br />
<br />
=== Things to be added ===<br />
<br />
* Add some wallpaper for the new desktop control panel icon.<br />
* Add support for explorer to load the desk.cpl when right clicking on background.</div>68.39.174.205https://reactos.org/wiki/index.php?title=VMware&diff=740VMware2005-02-21T21:59:30Z<p>68.39.174.205: Fix spacing</p>
<hr />
<div>VMware is a virtual machine program. It's commercial (So you have to pay for it), but at the moment it's the fastest (at least under Windows). [[QEMU]] is a free a alternative.<br />
<br />
== Versions ==<br />
<br />
Current version: 4.5.2. Should be free to update from 4.5.x.<br />
<br />
Next planned version: 5<br />
<br />
== Pages of this Wiki relating to VMware ==<br />
<br />
* [[VMware named pipe]]<br />
* [[HOWTO/install the VMware display driver]]<br />
<br />
== External sites ==<br />
<br />
* [http://www.vmware.com/ VMware home]</div>68.39.174.205https://reactos.org/wiki/index.php?title=QEMU&diff=741QEMU2005-02-21T21:56:40Z<p>68.39.174.205: Minor rearraingement</p>
<hr />
<div>Qemu is a free x86 Emulator/Virtual Machine for Linux and Windows. If you are looking for something faster try the Linux Kernel Module (currently just working with CVS-Version) or [[VMware]].<br />
<br />
== Grabbing debug messages ==<br />
<br />
By default debug messages from ReactOS are sent to the serial port (COM1).<br />
For grabbing that output, you need at least qemu version 0.6.1 where you can specify the -serial option.<br />
<br />
Like this:<br />
<pre>$ qemu -serial stdio -cdrom roslive.iso -boot d</pre><br />
<br />
If you are testing the setup cd, note that you can change the kernel arguments by editing the txtsetup.sif file (so things actually get written to the serial port).<br />
<br />
== External sites ==<br />
<br />
* [http://fabrice.bellard.free.fr/qemu/ QEMU homesite]</div>68.39.174.205https://reactos.org/wiki/index.php?title=VMware&diff=420VMware2005-02-21T21:55:46Z<p>68.39.174.205: Added versions</p>
<hr />
<div>VMware is a virtual machine program. It's commercial (So you have to pay for it), but at the moment it's the fastest (at least under Windows). [[QEMU]] is a free a alternative.<br />
<br />
== Versions ==<br />
<br />
Current version: 4.5.2. Should be free to update from 4.5.x.<br />
Next planned version: 5<br />
<br />
== Pages of this Wiki relating to VMware ==<br />
<br />
* [[VMware named pipe]]<br />
* [[HOWTO/install the VMware display driver]]<br />
<br />
== External sites ==<br />
<br />
* [http://www.vmware.com/ VMware home]</div>68.39.174.205https://reactos.org/wiki/index.php?title=VMware&diff=418VMware2005-02-21T21:54:53Z<p>68.39.174.205: Expanded, may need some more</p>
<hr />
<div>VMware is a virtual machine program. It's commercial (So you have to pay for it), but at the moment it's the fastest (at least under Windows). [[QEMU]] is a free a alternative.<br />
<br />
== Pages of this Wiki relating to VMware ==<br />
<br />
* [[VMware named pipe]]<br />
* [[HOWTO/install the VMware display driver]]<br />
<br />
== External sites ==<br />
<br />
* [http://www.vmware.com/ VMware home]</div>68.39.174.205https://reactos.org/wiki/index.php?title=VMware&diff=410VMware2005-02-21T03:47:18Z<p>68.39.174.205: This is a stub</p>
<hr />
<div>http://www.vmware.com/<br />
<br />
{{stub}}</div>68.39.174.205https://reactos.org/wiki/index.php?title=Vmware&diff=5925Vmware2005-02-21T03:47:05Z<p>68.39.174.205: Created redirect</p>
<hr />
<div>#REDIRECT [[VMware]]</div>68.39.174.205https://reactos.org/wiki/index.php?title=Template:Stub&diff=840Template:Stub2005-02-21T03:35:52Z<p>68.39.174.205: Created</p>
<hr />
<div><p style="margin: 1em 0.5em; padding: 0.5em; border-top: 3px double #aaa; border-bottom: 3px double #aaa;">This page is a short article on something that should have ALOT more information written on it. If you know anything else about it, you are STRONGLY encouraged to add the information in. If you are unsure of proper formatting or style, add it to the talk page or ths page itself as you think best and other will help.</p></div>68.39.174.205https://reactos.org/wiki/index.php?title=FreeWin95&diff=1202FreeWin952005-02-21T03:29:14Z<p>68.39.174.205: Created page, it was wanted</p>
<hr />
<div>'''FreeWin95''' was the predecessor to [[ReactOS]] which was focused on making an open source [[Windows 95]]. It never amounted to anything other then being the eventual genesis of ReactOS.<br />
<br />
{{stub}}</div>68.39.174.205https://reactos.org/wiki/index.php?title=User:Royce3&diff=693User:Royce32005-02-20T22:53:34Z<p>68.39.174.205: Fixed bad link</p>
<hr />
<div>Royce Mitchell III's TODO List:<br />
<br />
rbuild<br />
add tests for failure-cases<br />
output error if a cyclic reference is detected<br />
mingw backend should auto-detect -pipe support and add it to PROJECT_CFLAGS if detected<br />
mingw backend should auto-detect PCH support and use it if detected<br />
mingw backend should output <module>_clean target<br />
<br />
freetype caching<br />
<br />
vga driver broken when built as optimized:<br />
http://reactos.com/bugzilla/show_bug.cgi?id=490<br />
<br />
inf parsing<br />
ability to right-click inf file and click "Install" to get it installed<br />
filip2307: well, the setup inf can be installed. we just don't have the registry entries for the context menu entry.<br />
w3seek: apps\utils\infinst<br />
<br />
copy files via gui<br />
<br />
desktop context menu<br />
new shortcut<br />
display properties<br />
<br />
[[Irksome sth]]<br />
grep all GDI_AllocObj ( check the macros that point to it ) and make sure we handle failure gracefully<br />
grep all GDI_LockObj ( again macros... ) and make sure we handle those failures gracefully too<br />
ASSERT_KM_POINTER(x) for every x received by an internal kernel function<br />
bad examples:<br />
NtWriteFile in ntoskrnl/io/rw.c<br />
VfatWrite<br />
soso examples:<br />
MpfsWrite at least null-checks the mdl<br />
<br />
eradicate TAG_NONE<br />
<br />
msvc6<br />
<br />
ms office 2000<br />
<br />
figure out why the following can crash reactos cmd:<br />
cmd: [CLEAN] *.o precomp.h.gch cmd.sym cmd.a ./cmd.coff cmd.exe cmd.nostrip.exe cmd.o attrib.o alias.o batch.o beep.o call.o chcp.o choice.o cls.o cmdinput.o cmdtable.o color.o console.o copy.o date.o del.o delay.o dir.o dirstack.o echo.o error.o filecomp.o for.o free.o goto.o history.o if.o internal.o label.o locale.o memory.o misc.o move.o msgbox.o path.o pause.o prmopt.o redir.o ren.o screen.o set.o shift.o start.o strtoclr.o time.o timer.o title.o type.o ver.o<br />
<br />
ANSWER: Its because windows cmd insert a newline if the echo'ed string is longer than xxx chars thus the echo'ed text is recognized as a typed command, and since the command starts with cmd it executes cmd. Cmd.exe doesnt like all the unknown parameters very much and crash. -Gunnar<br />
http://files.reactsoft.com/bsysbug.png<br />
<br />
driver installation<br />
filip2307: Class Installers, UM PnP manager, PnP events, some setupapi SetupDi* APIs, CFGMGR32 + RPC runtime + working WIDL<br />
<br />
*** DONE IN ReactOS 0.3.0-SVN ***<br />
<br />
rbuild<br />
error if module referenced by <library> doesn't exist<br />
<include base="kjs">include</include><br />
output error if module referenced by base doesn't exist<br />
rename junk.tmp, base.tmp and temp.exp to %module%.jnk, %module%.tmp, %module%.exp<br />
put .exe, .o, etc files in $(ROS_INTERMEDIATE)<br />
use map instead of vector for factories<br />
use map created through ctors for module handlers ( kinda like the backend factories )<br />
implement <xi:fallback>:<br />
Exception: how about an <xi:include href="config" failonerror="false" /> ?<br />
Exception: <xi:include href="config.template" /><br />
Exception: <xi:include href="config" failonerror="false" /><br />
Exception: then properties in config will override properties in config.template<br />
add support for <property>, as opposed to <define><br />
let make do some of the work to reduce makefile size<br />
put junk and .a files in $(ROS_TEMPORARY)<br />
Exception: ROS_TEMPORARY, ROS_INTERMEDIATE, ROS_INSTALL?<br />
create some variables to reduce makefile size, like %modulename%_INCLUDES, and %modulename%_OBJS<br />
move module code to a base class where possible ( like the include macro creation )</div>68.39.174.205https://reactos.org/wiki/index.php?title=FreeLoader&diff=5920FreeLoader2005-02-19T22:27:44Z<p>68.39.174.205: Created page, it was wanted</p>
<hr />
<div>'''FreeLoader''' (Sometimes '''FreeLdr''') is the ReactOS bootloader. It can also function as a bootmanager for multiple OSes.<br />
<br />
FreeLoader is composed of two files, an executable (FREELDR.SYS) and a configuration file in Windows INI format (FREELDR.INI), and a bootsector to load the files. The two files are copied to the root directory (:\ or / depending on the OSes path notation) of the active partition.<br />
<br />
== Method of installation by ReactOS ==<br />
<br />
The FreeLoader boot code can be installed in many ways, depending on the pre-existing operating system. The setup logic tries the following steps in order:<br />
<br />
=== Windows NT OS ===<br />
If the Windows NT/2000/XP/2003 boot loader (NTLDR) is found on the active partition, the existing boot manager is configured to boot ReactOS. The FreeLoader boot code is written to a file named BOOTSECT.ROS in the root of the active partition, and an entry named "ReactOS" is added to BOOT.INI pointing to BOOTSECT.ROS.<br />
==== Detection ====<br />
The NT boot manager is detected by the presence of the files NTLDR and BOOT.INI in the root directory of the active partition. If Windows is set to hide system files, you may not be able to see these files.<br />
==== Uninstalling FreeLoader ====<br />
To uninstall FreeLoader, delete the file BOOTSECT.ROS and remove the "ReactOS" entry from the hidden BOOT.INI file. <br />
<br />
=== DOS / 9x ===<br />
If MS-DOS or Windows 95/98/ME is found on the active partition, the original boot sector is saved to a file named BOOTSECT.DOS in the root directory of the active partition. The FreeLoader boot code is then written to the boot sector of the active partition. FreeLoader thus becomes your primary boot manager, and from its boot menu you will be able to boot both ReactOS and Windows or DOS.<br />
==== Detection ====<br />
MS-DOS and Windows 95/98/ME are detected by the presence of the files MSDOS.SYS and IO.SYS in the root directory of the active partition<br />
==== Uninstalling FreeLoader ====<br />
To uninstall FreeLoader, boot from a MS-DOS or Windows Restore floppy disk, and run the command "SYS C:". After this, the BOOTSECT.DOS file can be safely deleted <br />
<br />
=== Non-Windows ===<br />
If none of the known operating systems is found on the active partition, the original boot sector is saved to the file BOOTSECT.OLD in the root directory of the active partition. The FreeLoader boot code is then written to the boot sector of the active partition. FreeLoader thus becomes the primary boot manager. Note that you will have to edit the FREELDR.INI configuration file by yourself to boot the pre-existing operating system, because FreeLoader has no knowledge of how to do it.<br />
==== Uninstalling FreeLoader ====<br />
To uninstall FreeLoader, restore the boot sector of the active partition from the BOOTSECT.OLD file. The details on how to do so are dependent on the operating system you are running <br />
<br />
Note: If the active partition uses a FAT32 filesystem, the boot code does not fit into a single sector. Microsoft uses sectors number 0 and 12, while FreeLoader uses sectors number 0 and 14, so there should not be any conflicts with existing boot loaders. <br />
<br />
== Links ==<br />
<br />
* [[HOWTO/boot FreeLoader from GRUB]] - For people loading FreeLoader and hence ReactOS from a bootmanager</div>68.39.174.205https://reactos.org/wiki/index.php?title=Boot_FreeLoader_from_GRUB&diff=746Boot FreeLoader from GRUB2005-02-19T22:13:21Z<p>68.39.174.205: Spelling</p>
<hr />
<div>== Background ==<br />
<br />
GRUB is a popular boot manager for people with many different operating systems installed on one machine or hard disk. [[FreeLoader]] is [[ReactOS]]s bootloader and also a possible boot manager. If you have GRUB already installed and then install ReactOS, FreeLoaders multiboot abilites become redundant and annoying. This document shows how to keep FreeLoader from doing much but acting as a bootloader for ReactOS.<br />
<br />
== Method ==<br />
<br />
FreeLoader can be loaded as a "multiboot kernel" by multiboot compliant bootstrap loaders like GRUB. To load FreeLoader from GRUB use something like this:<br />
<br />
<pre>title ReactOS<br />
root (hd0,0)<br />
kernel /freeldr.sys</pre><br />
<br />
You can also override settings in the [FREELOADER] section of freeldr.ini by passing them on the command like, like this:<br />
<br />
<pre>title ReactOS<br />
root (hd0,0)<br />
kernel /freeldr.sys DefaultOS=ReactOS TimeOut=0<br />
<br />
title ReactOS (Debug)<br />
root (hd0,0)<br />
kernel /freeldr.sys DefaultOS=ReactOS_Debug TimeOut=0</pre><br />
<br />
After selecting "ReactOS" from the GRUB menu you won't have to make another selection on the freeloader menu because of the "TimeOut=0"</div>68.39.174.205https://reactos.org/wiki/index.php?title=0.3.0&diff=8090.3.02005-02-19T22:01:30Z<p>68.39.174.205: Clarified blocking bugs</p>
<hr />
<div>This roadmap is for the 0.3.0 release only, for the goals of the entire 0.3.x series, see [[0.3.x]].<br />
<br />
== Currently requested fixes/additions ==<br />
<br />
=== Show Stoppers ===<br />
* Experimental TCP/IP over 802.3 Ethernet Support (Lots of info is in [[TCPIP.SYS]] and [[AFD.SYS]])<br />
** Network client applications<br />
*** Status: See Networking Status below<br />
* Ensure all bugs of severity "Blocker" are fixed [http://www.reactos.com/bugzilla/buglist.cgi?query_format=&bug_severity=blocker]<br />
** Status: In progess, 4 or 5 left<br />
<br />
=== Networking Status ===<br />
If you get something working, please update this with details on which program you got working, what version, and what build of ROS you got it working on<br />
<br />
* at least one working graphical browser<br />
** Done Mozilla COM object or Dillo <br />
*** Filip and Steven<br />
* at least one working mail client<br />
** Done [http://www.pc-tools.net/win32/jbmail/ jbmail]<br />
* at least one working IRC client<br />
** Done mIRC<br />
* at least one working FTP client<br />
** Imported BSD ftp (Needs accept)<br />
*** Reported by Steven<br />
* at least one working IM client<br />
** (TODO)<br />
* at least one working SVN client<br />
** (TODO -- check svn.exe)<br />
* lynx -source, curl, or wget works<br />
** Done lynx <br />
*** ROS build 2004-12-19<br />
* at least one working SSH client<br />
** Done putty.exe<br />
* other things that have been verified to work<br />
** finger <br />
*** ROS build 2004-09-23<br />
*** Reported by arty<br />
** telnet<br />
*** ROS build 2004-11-30<br />
*** Reported by arty<br />
** The Ritlabs Tiny Webserver (Delphi) [http://www.ritlabs.com/tinyweb/ www.ritlabs.com]<br />
** The Ultra VNC client (Not the server) [http://ultravnc.sourceforge.net/ ultravnc.sf.net]<br />
*** Reported by Jaix, ROS build 2005-02-14</div>68.39.174.205https://reactos.org/wiki/index.php?title=Create_a_keyboard_layout&diff=2098Create a keyboard layout2005-02-19T21:50:30Z<p>68.39.174.205: Minor formatting and a note.</p>
<hr />
<div>The keyboard layouts are dlls loaded in kernel space. The keyboard layouts are a bit strange since the constants used in them have no standard definitions, so the keyboard files have some preprocessor cruft.<br />
You can find this stuff in the existing keyboard layouts.<br />
<br />
They have a data payload and a single entry point that returns a pointer to the keyboard tables.<br />
<br />
The structure has these members:<br />
<br />
modifiers -> modifier_keys -> zero terminated mapping from vk to mod bit<br />
<br />
ROSDATA VK_TO_BIT modifier_keys[] = {<br />
{ VK_SHIFT, KSHIFT },<br />
{ VK_CONTROL, KCTRL },<br />
{ VK_MENU, KALT },<br />
{ 0, 0 }<br />
};<br />
<br />
-> number of bit combinations listed in modifier bits<br />
6<br />
<br />
-> modifier_bits <br />
<br />
{ 0, 1, 3, 4, SHFT_INVALID, SHFT_INVALID, 2 } /* Modifier bit order, NONE, SHIFT, CTRL, ALT, MENU, SHIFT + MENU, CTRL + MENU */<br />
<br />
Each entry in this list is indexed by a shift state (some combination of bits from the modifier keys table), and tells what column in the VK_TO_WCHARS tables that shift state applies to.<br />
<br />
vk_to_wchar_master -> null terminated list of vk_to_wchar tables of varying widths. the numberpad<br />
is a special table and is listed last.<br />
<br />
Each vk_to_wchar table is identified by a width, telling how many of the columns indexed by the modifier list are present.<br />
<br />
Put the new key-to-char entry in the key_to_chars_Xmod, where X is the number of functions the key has in the particular language. The values of the columns other than column 2 are from the ISO10646 unicode standard. See the tables at http://www.unicode.org/charts/.<br />
<br />
ROSDATA VK_TO_WCHARS3 key_to_chars_3mod[] = {<br />
/* Normal, Shifted, Ctrl */<br />
/* Legacy (telnet-style) ascii escapes */<br />
{ '3', CAPS, '3', 0xa7, 0xb3 },<br />
{ '7', CAPS, '7', '/', '{' },<br />
...<br />
<br />
The vitrual key '3' responds to capitalization in this language, produces:<br />
'3' unshifted (column 2)<br />
0xa7 Section sign Shifted (1) in the modifier bits<br />
0xb3 Superscript 3 Ctrl+Shift (3) in the modifier bits (Alt+Gr)<br />
<br />
dead_key -> most languages have keys on the keyboard which have more than one meaning depending on <br />
which key is pressed next. The dead key table tells which keys these are and what the<br />
outcomes will be.<br />
<br />
ROSDATA DEADKEY dead_key[] = {<br />
{ DEADTRANS(L'a', L'^', 0xe2, 0x00) },<br />
<br />
In this language, '^' followed by 'a' yields 0xe2, "Latin small letter a with circumflex"<br />
<br />
Dead keys are marked in the vk_to_wchar table by a WCH_DEAD and then are searched by first and second keypress in the dead chars table.<br />
<br />
Followed in the main table by three key name tables (zero terminated)<br />
1. normal key names<br />
2. extended key names<br />
3. dead key names<br />
<br />
The tables following these are the meat of the system, scancode to virtual key translation tables.<br />
Since there are more keys in the unenhanced key table (the 'beige keys') these are listed as 0x80<br />
entries, indexed by scan code. Empty entries are marked VK_EMPTY.<br />
<br />
The e0 and e1 scan code to vk tables are zero-terminated lists of scan codes that follow the special e0 and e1 extended keyboard codes. The first column is the scan code and the second column is an 8-bit virtual key code along with any required modifier bits in the upper byte (normally KEXT). The ext-bit is used by various parts of the keyboard system (for example to distinguish left and right shift and control, and to distinguish the windows keys from the alt keys).<br />
<br />
Following these are:<br />
<br />
Layout version (1.1 here)<br />
<br />
And ligature tables, which we don't currently support. These tables are used in languages that use scripts such a devangari, which have special opening character sequences for the beginning of a sentence. As far as I'm aware, languages based on cyrillic or roman alphabets don't use this. It would be great if somebody could help me describe this more fully.<br />
<br />
There is a list of virtual key codes available at: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/UserInput/VirtualKeyCodes.asp<br />
<br />
== Example ==<br />
<br />
Here's a short example of what is needed to be done to add a new keyboard layout:<br />
<br />
First make sure you have got a working build environment: http://reactos.com/wiki/index.php/Build_Environment<br />
<br />
You will need to know the correct descriptions and abbreviations for your keyboard (EG. American English, en-US, etc).<br />
<br />
The easiest way of creating a new keyboard layout is to copy and then modify an existing layout. The existing layouts can be found in the sources under /lib/kbd*. <br />
For the rest of this HOWTO let’s imagine we want to create a Swiss German keyboard layout (kbdsg.dll) based on the German kayboard layout.<br />
<br />
Copy /lib/kbdgr (the layout you're modifying (In this example the German layout)) to /lib/kbdsg.<br />
<br />
In '''/lib/kbdsg''' rename the following files:<br />
kbdgr.c to kbdsg.c<br />
kbdgr.def to kbdsg.def<br />
kbdgr.map to kbdsg.map<br />
kbdgr.rc to kbdsg.rc.<br />
<br />
Change '''kbdsg.rc''' so that it looks like this:<br />
#define REACTOS_VERSION_DLL<br />
#define REACTOS_STR_FILE_DESCRIPTION "ReactOS Swiss German Keyboard Layout\0"<br />
#define REACTOS_STR_INTERNAL_NAME "kbdsg\0"<br />
#define REACTOS_STR_ORIGINAL_FILENAME "kbdsg.dll\0"<br />
#include <reactos/version.rc><br />
<br />
in '''kbdsg.map, kbdsg.def, makefile''' and '''Jamfile'''<br />
Search for kbgr and change it to kbdsg<br />
<br />
Change '''kbdsg.c''' according to the keyboard specifications (yes, this is the main part of the work)<br />
<br />
Now we want to make sure that the keyboard layout dll gets compiled (and set as the default layout so we can test it). We therefore need to change the following files:<br />
<br />
'''bootdata/hivesys.inf'''<br />
Search for "Keyboard Layouts" and add an entry for your new layout. <br />
As for the number you need there (like "0x409" for US), I think <br />
it's 0x807 (LANG_GERMAN with SUBLANG_GERMAN_SWISS). You probably need <br />
to add an entry below "NLS Language settings" too, no idea what that <br />
does, I'd just copy an existing entry and adjust. Then change "Default" <br />
and "InstallLanguage" to 0807. <br />
<br />
'''bootdata/hivedef.sys'''<br />
near the top, "Control Panel\International", "Locale" change "0409" to "0807". <br />
<br />
'''Makefile''' (the one in the source root directory)<br />
Add your layout to the following line:<br />
DLLS_KBD = kbdda kbddv kbdes kbdfr kbdgr kbdse kbduk kbdus kbdsg<br />
<br />
'''bootdata/packages/reactos.dff'''<br />
Just follow the example of the other lib/kbd* stuff in there. <br />
<br />
if you now build a livecd your keyboard layout should be the default layout.</div>68.39.174.205https://reactos.org/wiki/index.php?title=User:GvG&diff=4059User:GvG2005-02-19T02:47:12Z<p>68.39.174.205: Created page, it was wanted</p>
<hr />
<div>Dude from NL who seems to be all over the place.</div>68.39.174.205https://reactos.org/wiki/index.php?title=Gregor_Anich&diff=387Gregor Anich2005-02-19T02:46:38Z<p>68.39.174.205: Link FNs name</p>
<hr />
<div>Location: AustriA<br />
<br />
I am working on the following stuff at the moment:<br />
* KDB rewrite<br />
* Hardware OpenGL support for NVIDIA graphics cards<br />
<br />
What I have done so far...<br />
* Floating point state saving for ntoskrnl (to allow multiple tasks to use the FPU simultaneously)<br />
* Got the NVIDIA Windows 2000 display driver working (thanks to [[Filip Navara]]'s help)</div>68.39.174.205https://reactos.org/wiki/index.php?title=Gregor_Anich&diff=376Gregor Anich2005-02-19T02:46:20Z<p>68.39.174.205: </p>
<hr />
<div>Location: AustriA<br />
<br />
I am working on the following stuff at the moment:<br />
* KDB rewrite<br />
* Hardware OpenGL support for NVIDIA graphics cards<br />
<br />
What I have done so far...<br />
* Floating point state saving for ntoskrnl (to allow multiple tasks to use the FPU simultaneously)<br />
* Got the NVIDIA Windows 2000 display driver working (thanks to Filip Navara's help)</div>68.39.174.205https://reactos.org/wiki/index.php?title=Ideas&diff=752Ideas2005-02-18T00:54:13Z<p>68.39.174.205: Added variations</p>
<hr />
<div>For all not yet begun ''serious'' and ''non trivial'' ideas for additions, enhancements, and other goodness to ReactOS or some immediatly associated thing.<br />
<br />
* [[ReactOS Package Manager]]<br />
* [[ReactOS bootsetup diskette]]<br />
* [[ReactOS Variations]]<br />
<br />
Not sure if some of these subsystems fit the above criteria<br />
<br />
* [[ReactOS subsystems]]</div>68.39.174.205https://reactos.org/wiki/index.php?title=User:Navaraf&diff=368User:Navaraf2005-02-18T00:52:10Z<p>68.39.174.205: Added comment about bug queue list</p>
<hr />
<div><table><br />
<tr><br />
<td><br />
http://www.volny.cz/xnavara/me_small.jpg<br />
</td><br />
<td valign="top"><br />
IRC nickname: filip0402 / filip2307<br /><br />
Country: Czech Republic<br /><br />
City: Prague<br /><br />
Interests: Programming, Music, Girls ;)<br /><br />
<br />
[http://www.reactos.com/bugzilla/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=xnavara%40volny.cz&emailtype1=exact&emailassigned_to1=1&emailreporter1=1 Bug queue] (Which contains one that belongs to [[Vizzini]] for some reason)<br />
</td><br />
</table></div>68.39.174.205https://reactos.org/wiki/index.php?title=Subversion&diff=519Subversion2005-02-18T00:46:24Z<p>68.39.174.205: Formatting links</p>
<hr />
<div>== What is Subversion? ==<br />
<br />
ReactOS source code was in a CVS repository up to December 30th 2004. Since January 1st 2005, the source code is in a Subversion (SVN) repository. SVN, just like CVS, is the most recent evolution of source code control and versioning systems. SVN is open-source.<br />
<br />
== Get a Subversion client ==<br />
<br />
=== Windows ===<br />
<br />
* [http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91 Command line client]<br />
* [http://tortoisesvn.tigris.org/download.html Windows Shell Integrated Client (TortoiseSVN)]<br />
* [http://rapidsvn.tigris.org/ RapidSVN (Like WinCVS)]<br />
<br />
* [http://subversion.tigris.org/project_packages.html Sources for many platforms]<br />
<br />
== Browse the sources ==<br />
<br />
The sources in the repository can be viewed with a browser by visiting http://svn.reactos.com/viewcvs/.<br />
<br />
== Checking out the sources ==<br />
<br />
Retrieve the sources from the repository by executing the following command:<br />
<br />
''svn co svn://svn.reactos.com/trunk/<MODULE NAME>''<br />
<br />
Replace <MODULE NAME> with the module you want to check out. The following command will check out the main module:<br />
<br />
''svn co svn://svn.reactos.com/trunk/reactos''<br />
<br />
To check out using a specific user account, use the following syntax:<br />
<br />
''svn co svn://<USER>@svn.reactos.com/trunk/reactos''<br />
<br />
The sources will be put in a directory on your local volume. This directory is called a working copy. Branches are handled in a different way than by CVS. To Check out a branch use the following command:<br />
<br />
''svn co svn://svn.reactos.com/branches/<BRANCH>''<br />
<br />
== Updating the sources ==<br />
<br />
You can update your working copy using the following command:<br />
<br />
''svn up''<br />
<br />
This will retrieve changes made to the sources in the repository after your last checkout or update and put them into your working copy.<br />
<br />
== Committing your changes ==<br />
<br />
If you have commit (write) access, you can make changes to the repository. You can commit the local changes in your working copy using the following command:<br />
<br />
''svn ci -m "Commit message" <directory to commit>''<br />
<br />
<directory to commit> is the directory where your local changes are located. This will transfer changes made to your working copy to the repository.<br />
<br />
The first time write access is needed, Subversion will ask for a username and password and will use that as default for all future working copies made from the same domain. It is also possible to pass "--username" and "--password" arguments to the Subversion client in order to specify the user account and password.<br />
<br />
== Commit mails ==<br />
<br />
Mails with changes in each commit are sent to two mailing lists. There is ros-svn which will receive plaintext mails with descriptions of the changes. You can subscribe to this mailing list by sending a mail to ''mailto:ros-svn-subscribe@reactos.com''. If you are already subscribed, but don't want to be anymore, you can send a mail to ''mailto:ros-svn-unsubscribe@reactos.com''. Mailing list archives are available at http://reactos.com:8080/archives/public/ros-svn/.<br />
<br />
There is also ros-svn-diffs which will receive mails containing the changes in highlighted html mails for easy reviewing. You can subscribe to this mailing list by sending a mail to ''mailto:ros-svn-diffs-subscribe@reactos.com''. If you are already subscribed, but don't want to be anymore, you can send a mail to ''mailto:ros-svn-diffs-unsubscribe@reactos.com''. Mailing list archives are available at http://reactos.com:8080/archives/public/ros-svn-diffs/.<br />
<br />
== More information ==<br />
<br />
A complete book about Subversion is available online at http://svnbook.red-bean.com.<br />
<br />
== Request commit (write) access ==<br />
<br />
=== Applying for write access ===<br />
<br />
Once you have started submitting patches and new code to the project you can be considered for application. We would prefer not to give access to someone who makes two or three updates and then never again. Also, if you are only going to submit patches now and again, rather just send them to someone who has write access. If, however, you become a contributing developer on a continuing basis, you should definitely consider applying for write access. <br />
<br />
=== Who to ask ===<br />
<br />
Submit your request to Casper Hornstrup at chorns at reactos dot com (compress this into a normal email address) and include your preferred username in the mail. If your request is granted, Casper will create a user for you with the details you specified. You must then use the new account instead of the anonymous account to write to the repository.<br />
<br />
== Setting a default commit log editor for the Subversion command line client ==<br />
<br />
On Windows, open the text file ''C:\Documents and Settings\<username>\Application Data\Subversion\config''. Put the following two lines in there to set notepad as your default editor:<br />
<br />
''[helpers]''<br />
''editor-cmd = notepad''<br />
<br />
== Known issues ==<br />
<br />
=== Svn update says: object with the same name already exists ===<br />
<br />
When you update your working copy with svn update, you may get the following error message:<br />
<br />
''svn up: "object with the same name already exists"''<br />
<br />
Subversion displays the error message because the directory is replaced in the repository and your working copy contains data which is unknown to Subversion (you working copy is locally modified). Since Subversion does everything it can to not cause harm to your data, you must remove or move the data which is not in the repository out of the working copy.<br />
<br />
This scenario won't happen very often though. You have two options to correct resolve the problem:<br />
<br />
* Remove the affected directory and run svn update again<br />
* Remove all files and directories in the working copy that are unknown to Subversion and then run svn update again. These are the files and directories that are marked with ? in the output from svn status</div>68.39.174.205https://reactos.org/wiki/index.php?title=0.3.0&diff=3930.3.02005-02-18T00:44:07Z<p>68.39.174.205: Fixed hierarchy</p>
<hr />
<div>This roadmap is for the 0.3.0 release only, for the goals of the entire 0.3.x series, see [[0.3.x]].<br />
<br />
== Currently requested fixes/additions ==<br />
<br />
=== Show Stoppers ===<br />
* Experimental TCP/IP over 802.3 Ethernet Support (Lots of info is in [[TCPIP.SYS]] and [[AFD.SYS]])<br />
** Network client applications<br />
*** Status: See Networking Status below<br />
* Ensure all bugs of severity "Blocker" are fixed [http://www.reactos.com/bugzilla/buglist.cgi?query_format=&bug_severity=blocker]<br />
** Status: In progess, 6 left<br />
<br />
=== Networking Status ===<br />
If you get something working, please update this with details on which program you got working, what version, and what build of ROS you got it working on<br />
<br />
* at least one working graphical browser<br />
** Done Mozilla COM object or Dillo <br />
*** Filip and Steven<br />
* at least one working mail client<br />
** Done [http://www.pc-tools.net/win32/jbmail/ jbmail]<br />
* at least one working IRC client<br />
** Done mIRC<br />
* at least one working FTP client<br />
** Imported BSD ftp (Needs accept)<br />
*** Reported by Steven<br />
* at least one working IM client<br />
** (TODO)<br />
* at least one working SVN client<br />
** (TODO -- check svn.exe)<br />
* lynx -source, curl, or wget works<br />
** Done lynx <br />
*** ROS build 2004-12-19<br />
* at least one working SSH client<br />
** Done putty.exe<br />
* other things that have been verified to work<br />
** finger <br />
*** ROS build 2004-09-23<br />
*** Reported by arty<br />
** telnet<br />
*** ROS build 2004-11-30<br />
*** Reported by arty<br />
** The Ritlabs Tiny Webserver (Delphi) [http://www.ritlabs.com/tinyweb/ www.ritlabs.com]<br />
** The Ultra VNC client (Not the server) [http://ultravnc.sourceforge.net/ ultravnc.sf.net]<br />
*** Reported by Jaix, ROS build 2005-02-14</div>68.39.174.205https://reactos.org/wiki/index.php?title=Subversion&diff=355Subversion2005-02-16T02:07:45Z<p>68.39.174.205: Removed spurious ----s and reformatted some to hierarchy.</p>
<hr />
<div>== What is Subversion? ==<br />
<br />
ReactOS source code was in a CVS repository up to December 30th 2004. Since January 1st 2005, the source code is in a Subversion (SVN) repository. SVN, just like CVS, is the most recent evolution of source code control and versioning systems. SVN is open-source.<br />
<br />
== Get a Subversion client ==<br />
<br />
=== Windows ===<br />
<br />
* Command Line Client (http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91)<br />
* Windows Shell Integrated Client (http://tortoisesvn.tigris.org/download.html)<br />
* RapidSVN is a svn client similar to WinCVS (http://rapidsvn.tigris.org)<br />
<br />
Sources for Linux, FreeBSD, NetBSD, OpenBSD, Solaris, MacOS X, Win32<br />
<br />
* http://subversion.tigris.org/project_packages.html<br />
<br />
== Browse the sources ==<br />
<br />
The sources in the repository can be viewed with a browser by visiting http://svn.reactos.com/viewcvs/.<br />
<br />
== Checking out the sources ==<br />
<br />
Retrieve the sources from the repository by executing the following command:<br />
<br />
''svn co svn://svn.reactos.com/trunk/<MODULE NAME>''<br />
<br />
Replace <MODULE NAME> with the module you want to check out. The following command will check out the main module:<br />
<br />
''svn co svn://svn.reactos.com/trunk/reactos''<br />
<br />
To check out using a specific user account, use the following syntax:<br />
<br />
''svn co svn://<USER>@svn.reactos.com/trunk/reactos''<br />
<br />
The sources will be put in a directory on your local volume. This directory is called a working copy. Branches are handled in a different way than by CVS. To Check out a branch use the following command:<br />
<br />
''svn co svn://svn.reactos.com/branches/<BRANCH>''<br />
<br />
== Updating the sources ==<br />
<br />
You can update your working copy using the following command:<br />
<br />
''svn up''<br />
<br />
This will retrieve changes made to the sources in the repository after your last checkout or update and put them into your working copy.<br />
<br />
== Committing your changes ==<br />
<br />
If you have commit (write) access, you can make changes to the repository. You can commit the local changes in your working copy using the following command:<br />
<br />
''svn ci -m "Commit message" <directory to commit>''<br />
<br />
<directory to commit> is the directory where your local changes are located. This will transfer changes made to your working copy to the repository.<br />
<br />
The first time write access is needed, Subversion will ask for a username and password and will use that as default for all future working copies made from the same domain. It is also possible to pass "--username" and "--password" arguments to the Subversion client in order to specify the user account and password.<br />
<br />
== Commit mails ==<br />
<br />
Mails with changes in each commit are sent to two mailing lists. There is ros-svn which will receive plaintext mails with descriptions of the changes. You can subscribe to this mailing list by sending a mail to ''mailto:ros-svn-subscribe@reactos.com''. If you are already subscribed, but don't want to be anymore, you can send a mail to ''mailto:ros-svn-unsubscribe@reactos.com''. Mailing list archives are available at http://reactos.com:8080/archives/public/ros-svn/.<br />
<br />
There is also ros-svn-diffs which will receive mails containing the changes in highlighted html mails for easy reviewing. You can subscribe to this mailing list by sending a mail to ''mailto:ros-svn-diffs-subscribe@reactos.com''. If you are already subscribed, but don't want to be anymore, you can send a mail to ''mailto:ros-svn-diffs-unsubscribe@reactos.com''. Mailing list archives are available at http://reactos.com:8080/archives/public/ros-svn-diffs/.<br />
<br />
== More information ==<br />
<br />
A complete book about Subversion is available online at http://svnbook.red-bean.com.<br />
<br />
== Request commit (write) access ==<br />
<br />
=== Applying for write access ===<br />
<br />
Once you have started submitting patches and new code to the project you can be considered for application. We would prefer not to give access to someone who makes two or three updates and then never again. Also, if you are only going to submit patches now and again, rather just send them to someone who has write access. If, however, you become a contributing developer on a continuing basis, you should definitely consider applying for write access. <br />
<br />
=== Who to ask ===<br />
<br />
Submit your request to Casper Hornstrup at chorns at reactos dot com (compress this into a normal email address) and include your preferred username in the mail. If your request is granted, Casper will create a user for you with the details you specified. You must then use the new account instead of the anonymous account to write to the repository.<br />
<br />
== Setting a default commit log editor for the Subversion command line client ==<br />
<br />
On Windows, open the text file ''C:\Documents and Settings\<username>\Application Data\Subversion\config''. Put the following two lines in there to set notepad as your default editor:<br />
<br />
''[helpers]''<br />
''editor-cmd = notepad''<br />
<br />
== Known issues ==<br />
<br />
=== Svn update says: object with the same name already exists ===<br />
<br />
When you update your working copy with svn update, you may get the following error message:<br />
<br />
''svn up: "object with the same name already exists"''<br />
<br />
Subversion displays the error message because the directory is replaced in the repository and your working copy contains data which is unknown to Subversion (you working copy is locally modified). Since Subversion does everything it can to not cause harm to your data, you must remove or move the data which is not in the repository out of the working copy.<br />
<br />
This scenario won't happen very often though. You have two options to correct resolve the problem:<br />
<br />
* Remove the affected directory and run svn update again<br />
* Remove all files and directories in the working copy that are unknown to Subversion and then run svn update again. These are the files and directories that are marked with ? in the output from svn status</div>68.39.174.205https://reactos.org/wiki/index.php?title=ReactOS_Update&diff=332ReactOS Update2005-02-13T22:33:45Z<p>68.39.174.205: Import from old Wiki</p>
<hr />
<div>As ReactOS grows further in usability and functionality, it would be prudent to have a utility, ReactOSUpdate, to download and install updates without in an easy and fast way for end users, with a nice "ReactOS Update" button to make it look like Windows. :-)<br />
<br />
----<br />
What about [http://rsync.samba.org/ rsync] for retrieving updates in system directories?<br />
<br />
== rsync-update concept #1 ==<br />
we would probably need a second directory where the reactos core system files get stored too. this might be something like "[[dllcache]]" from windows (the installation routine only needs to install these system files twice). rsync updates the files in dllCache. a reimplementation of [[SFC]] would then copy the new files to their usual destination after reboot.<br />
<br />
=== what do we need? ===<br />
* networking and TcpIpDotSys (network is NOT required for syncing! you can also rsync from a local source - e.g. for testing or updating from cdrom)<br />
* [http://rsync.samba.org/nt.html rsync for our platform] (already available)<br />
* A version of [[SFC]]<br />
* a (secure!) rsync server providing us with files<br />
<br />
----<br />
<br />
== ReactOS Update (ReactUpdate) concept #2 ==<br />
<br />
Have a local app called rosupate.exe (or similar) that lives in the \ReactOS or \ReactOS\system32 directory and, when launched would follow this process:<br />
<br />
* Checks itself to ensure it hasn't been tampered with (Digital Signature/checksum).<br />
* Checks against it's ACL if the UserID invoking it has the right to do so.<br />
** If not, it can prompt with a RunAs box to enter valid credentails (Like MacOS X does with it's control panel).<br />
*** If RunAs is unavailible or unimplemented, gives an error along the lines of "Your user account has not been granted permission to run ReactOS Update".<br />
** If the UserID is allowed, it silently continues to the next step<br />
* Check if there's a previous update/restart pending.<br />
** If so, state that for some other reason the system should be restarted before any updating is attempted (Maybe give an option to go ahead anyway, with with sufficent warning (EG. "It is strongly recommended you restart your system before attempting to update ReactOS")).<br />
** If not keep going.<br />
* Ask the user how they want to update: Over the Internet (Recommended) (Suboption of a local update server), or via a local update source.<br />
** If over the Internet normally, continue.<br />
*** If a local update server, ask for the name/IP (If not preselected by the Administrator), and if required credentials (Using a standard connect dailog box)<br />
** If a local source, ask for the path to the "INFO.UPD" (Or whatever the update data file (Think sortof like .inf file paths thatare always requested for always requested on driver installs) is called in the end). If this is the case, in the following steps, read "The local media" instead of a remote server where network transactions are being discussed.<br />
* I'm not sure about this step: How for it to determine the ReactOS update sites DNS and/or IP and not be liable to spoofing. The best thing I can come up with is if the DNS is going to change, have the old one only offer an update to ReactOSUpdate that will redirect it to the correct one.<br />
** If using a locally specified update server, goto the one supplied by the user.<br />
* Open an HTTPS connection to the update site (Probably something like rosupdate.reactos.org, update.reactos.org, os.update.reactos.org, etc. which incedentally, could function as web-based update sites for ROS).<br />
* Report the ReactOSUpdate application version number and if the server reports it ourdated, download the information to download and install the most up-do-date version.<br />
** If there are update, present them as the only update and state that they need to install that to recive other updates.<br />
** If not, continue on.<br />
* Download from the server the list of all the files that have updates, the new versions, sizes, and other metadata (Full list later down the page)<br />
* Format and present this to the user in the application.<br />
** If any updates are of immediately serious import (EG. There's a very easily exploited TCP/IP buffer overflow giving SYSTEM access and there's a rapidly spreading worm (Blaster-like) that exploits this) ReactOSUpdate may take immediate action (Block the affected ports, stop the affected services, or completely kill certain parts of the system untill updated (There should be a user preference to disable this or to ask 1st).<br />
** Seperate the updates into different sections based on their importance, but also by size, time to download, etc.<br />
** Also have tabs (Or a different means) to seperate the updates which need to be installed in their own session, independent of others<br />
** Have an option, selected by default, to delete the updates after installation.<br />
*** A further option, download the updates but don't install them automatically.<br />
* The user then selects the updates to install and indicates to continue <br />
** Check that no updates which need to be installed seperately are selected with others<br />
*** If so, give an error listing the 2 options and allowing to continue with one or the other (Default to the one with the higher criticality), go back and review the selections, or cancel the update.<br />
** If the download size is significant compared to the speed of their connection to the update server, warn against significant delays and possible toll charged.<br />
** If neither of these apply, the keep going.<br />
* Warn the user that once the updates are downloaded, the system will need to be restart and that all unsaved work will be lost, etc, etc. Give them fair warning and the ability to gracefully back out (If there are updates of vital import this could be blocked/bypassed, or "strongly recommended" to continue).<br />
* Over secured connection (HTTPS or SFTP for example) download the selected updates to a directory on the hard disk (\ReactOS\Downloaded Updates, for example) and verify them.<br />
** If any fail verification, delete and redownload<br />
* When all the updates are downloaded install them using one of the following methods (Note, I have no idea which is best or even possible, I'll leave that for someone else to determine)<br />
<br />
Method 1:<br />
* Overwrite the files as they stand.<br />
* Verify the new ones.<br />
* Request a reboot.<br />
<br />
Method 2:<br />
* Move the files to a seperate directory.<br />
* Have the kernel load a program (Probably under the BootExecute key in the Registry) that will load on early startup<br />
* Request a reboot.<br />
* Once the program loads it kills the old copies, moves the new ones over, and makes a log somewhere.<br />
<br />
Method 2.1 (Slighly different version of 2):<br />
* Install (In \ROSBootUpdate, for instance) a minimal kernel and the files to be copied and put it in the FreeLoader bootmenu (As "ReactOS 1 SP1 Installer", say) and make it default with a very short timedelay.<br />
* When loaded, check itself and the files to be sure they're correct.<br />
** If they are invalid, state as much with possible reasons why, and jump to the 4th from last step (In this revision).<br />
** If all are valid, contine.<br />
* Locate the directories and files to be replaced.<br />
* Erase the old files and copy the new ones over.<br />
* Remove the update entry from FreeLdr.ini<br />
* Add to the BootExecute key of the Registry a command to remove the \ROSBootUpdate directory and itself.<br />
* Restart.<br />
<br />
=== Update Metadata ===<br />
<br />
* English (Or whatever language is specified ;)) description of the componment(s) affected.<br />
* New and currently installed versions<br />
* Sizes of update downloads<br />
** Compute the approximate download time locally (Maybe using the time it took to download the updates list as a factor?).<br />
* Severity (Examples/definitions in subpoints)<br />
** New feature<br />
*** Support for IPX/SPX<br />
** Trivial bug <br />
*** Misspelled "ReactOS" in something<br />
** Minor bug <br />
*** Pressing "OK" somewhere doesn't save chnages<br />
** Moderate bug <br />
*** Pressing "OK" somewhere freezes the Desktop/Shell<br />
** Severe bug <br />
*** ReactOS can be crashed by pressing "OK" somewhere, by sending a malformed TCP packet the system gives a BSOD<br />
** Critical bug <br />
*** A very easily exploitable hole or other bug which can lead to compromise of sensetive/confidential information, compromise of the system at elevated privledges (Administrator or SYSTEM), or corruption of vital files/directories.<br />
** Extremely Critical bug<br />
*** Same as Critical, but with evidence of "In the wild" use (Virus with Blaster-like proportions)<br />
**** Will default to stopping the affected part (If possible) during/before update.<br />
* Reboot required?<br />
* Individual installation required?<br />
<br />
=== What's needed ===<br />
* Networking / [[TCPIP.SYS]] (Ofcourse!)<br />
* A local DLL with crypto functions (checksum, digital signatures, etc) <br />
** WINE is working on one<br />
* An HTTPS/SFTP client in the OS<br />
** PuTTY and [http://filezilla.sf.net/ FileZilla] look like good options<br />
* An HTTPS/SFTP server<br />
** Probably [http://www.apache.org/ Apache] and something else for SFTP<br />
* A valid SSL certificate<br />
** Possibly selfsigned, or from VeriSign, Thawte, or similar.<br />
* Probably as ROS grows more popular a dedicated line for this server (Which should also become a dedicated and formidable server), or regional update servers.<br />
** Appropriate, probably a seperate DNS (os.update.reactos.org). Later as popularity, complexity and hence updates and downloads grow, local mirrors (os.update.reactos.org.nl, .ru, .us, .mx, .au, etc), if you can update from version to version via ROSUpdate (EG. 0.6.0 > 0.7.0) then probably sub-servers for those updates alone (070.os.update.reactos.org), and possibly multiple servers in the same area (philadelphia.os.update.reactos.us, eastfalls.philadelphia.pa.update.reactos.us). I know these scenarios are FAR into the future if they will ever occur, but it's good to have a plan.</div>68.39.174.205https://reactos.org/wiki/index.php?title=0.3.0&diff=3530.3.02005-02-12T04:00:24Z<p>68.39.174.205: Up to 6 now</p>
<hr />
<div>This roadmap is for the 0.3.0 release only, for the goals of the entire 0.3.x series, see [[0.3.x]].<br />
<br />
== Currently requested fixes/additions ==<br />
<br />
=== Show Stoppers ===<br />
* Experimental TCP/IP over 802.3 Ethernet Support (Lots of info is in [[TCPIP.SYS]] and [[AFD.SYS]])<br />
** Network client applications<br />
*** Status: See Networking Status below<br />
* Ensure all bugs of severity "Blocker" are fixed [http://www.reactos.com/bugzilla/buglist.cgi?query_format=&bug_severity=blocker]<br />
** Status: In progess, 6 left<br />
<br />
=== Networking Status ===<br />
If you get something working, please update this with details on which program you got working, what version, and what build of ROS you got it working on<br />
<br />
* at least one working graphical browser<br />
** Done Mozilla COM object or Dillo <br />
*** Filip and Steven<br />
* at least one working mail client<br />
** Done [http://www.pc-tools.net/win32/jbmail/ jbmail]<br />
* at least one working IRC client<br />
** Done mIRC<br />
* at least one working FTP client<br />
** Imported BSD ftp (Needs accept)<br />
*** Reported by Steven<br />
* at least one working IM client<br />
** (TODO)<br />
* at least one working SVN client<br />
** (TODO -- check svn.exe)<br />
* lynx -source, curl, or wget works<br />
** Done lynx <br />
*** ROS build 2004-12-19<br />
* at least one working SSH client<br />
** Done putty.exe<br />
* other things that have been verified to work<br />
** finger <br />
*** ROS build 2004-09-23<br />
*** Reported by arty<br />
** telnet<br />
*** ROS build 2004-11-30<br />
*** Reported by arty</div>68.39.174.205