What do you think about?'Regarding ReactOS I do not doubt that there are very expert people, but after many years there are aspects that
have not been polished giving a sensation of malfunction and instability that pull back. Another aspect that falls short is the impression.
Eye that is not eager to criticize, as it is said in the world of free software that is the same to program it.
I do not see bad to real criticism (the one that points out the problem). It is precisely this criticism of the user's criticism that
makes it difficult for free software to take off.
In the end it ends up being a product by and for programmers.
Criticism is a necessary and invaluable contribution to any project
But of course, when persistent things discourage to start other developments is a pity. Even so ReactOS if you are experiencing
improvements thanks to the development team. If people came out of here capable of improving it while learning, it would be great.
Perhaps it would be necessary that those who know more should make small and simple examples that will lead to more difficult things.
I know that for a developer it is annoying to even stop to document things so as to try to open the way for new potential developers but ...
But it's the basics. I would prefer that they stop a year of development even, if it were necessary so much (I think less) to document
everything and facilitate the incorporation of new developers, rethink direction, etc.
People go through the hoop for fear of changing to the unknown other simply because they have software adapted and purchased with
support, but the competition should encourage better prices and more variety of systems and for that the sources of the programs are important.
Although we already know that they will not do it but dedicated mice if they would be fine. For example, make sure that a compiler such as
FreePascal,Lazarus, ZinjaI works well, when it is installed properly but it is useless if the caption of the button or the glyph does not work ... is
to close initiatives to applications, because of applications Some programmer if he paves the way could be interested in the development of the system.
It also serves to establish collaborations between development communities that are willing to have incentives that encourage the whole. '
Important reflection
Moderator: Moderator Team
Important reflection
I share the following discussion (translated using Google Translate) to treflect on ReactOS development:
- binarymaster
- Posts: 482
- Joined: Sun Nov 16, 2014 7:05 pm
- Location: Russia, Moscow
- Contact:
Re: Important reflection
Lazarus and ZinjaI are not compilers.Rosh wrote:What do you think about?For example, make sure that a compiler such as
FreePascal,Lazarus, ZinjaI works well,
by Stas'M | https://github.com/binarymaster
- EmuandCo
- Developer
- Posts: 4734
- Joined: Sun Nov 28, 2004 7:52 pm
- Location: Germany, Bavaria, Steinfeld
- Contact:
Re: Important reflection
I wonder about the context. Where is that from? Maybe that way ppl could check out the untranslated original.
ReactOS is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.
If my post/reply offends or insults you, be sure that you know what sarcasm is...
If my post/reply offends or insults you, be sure that you know what sarcasm is...
Re: Important reflection
What exactly is your point... Sure it's an IDE but I'm pretty certain you got the gist of what was being said. Most Windows developers don't use a command line compiler only unless they are building a cross platform project with makefiles etc...binarymaster wrote:Lazarus and ZinjaI are not compilers.Rosh wrote:What do you think about?For example, make sure that a compiler such as
FreePascal,Lazarus, ZinjaI works well,
I'm sure there is a large number of developers that never even touch a command line compiler...
That said the recent changes that fixed some issues with downloading files larger than RAM are huge step toward making more real world applications usable.
Re: Important reflection
Stop development work on ReactOS for up to a year in order to document everything? This idea is not as good as it seems. Microsoft's Raymond Chen discusses a similar idea in his blog The Old New Thing. The problem with The Month Where Everyone Focuses on Improving Documentation is that most people are terrible technical writers. Verifying the correctness of the documentation also requires much repetitive, dull, time consuming work.But it's the basics. I would prefer that they stop a year of development even, if it were necessary so much (I think less) to document everything...
The ReactOS project has its own wiki. A link to the wiki is at the top of the ReactOS.org home page. Unfortunately, a wiki cannot write itself. The maintainers of the ReactOS web site allow everyone registered with the ReactOS site to edit the wiki. Unfortunately "most people are terrible technical writers" and most people lack the necessary knowledge about ReactOS to write useful documentation.
Last edited by middings on Wed May 23, 2018 9:54 pm, edited 1 time in total.
Re: Important reflection
It is from a Telegram discussion chat.EmuandCo wrote:I wonder about the context. Where is that from? Maybe that way ppl could check out the untranslated original.
I posted because I consider an important relection to share.
The original chat is in spanish. Copy of that is on viewtopic.php?f=7&t=17157
Re: Important reflection
middings wrote:Stop development work on ReactOS for up to a year in order to document everything? This idea is not as good as it seems. Microsoft's Raymond Chen discusses a similar idea in his blog The Old New Thing. The problem with The Month Where Everyone Focuses on Improving Documentation is that most people are terrible technical writers. Verifying the correctness of the documentation also requires much repetitive, dull, time consuming work.But it's the basics. I would prefer that they stop a year of development even, if it were necessary so much (I think less) to document everything...
The ReactOS project has its own wiki. A link to the wiki is at the top of the ReactOS.org home page. Unfortunately, a wiki cannot write itself. The maintainers of the ReactOS web site allow everyone registered with the ReactOS site to edit the wiki. Unfortunately "most people are terrible technical writers" and most people lack the necessary knowledge about ReactOS to write useful documentation.
There must be a solution to write good documentation and examples for newbie and inexperienced people.
![Question :?:](./images/smilies/icon_question.gif)
Re: Important reflection
The point to have an IDE full functional and working on ReactOS, to be able to develop or write some code in ReactOS itself. It could be more attractive to get new developers in some way...What exactly is your point... Sure it's an IDE but I'm pretty certain you got the gist of what was being said. Most Windows developers don't use a command line compiler only unless they are building a cross platform project with makefiles etc...
I'm sure there is a large number of developers that never even touch a command line compiler...
That said the recent changes that fixed some issues with downloading files larger than RAM are huge step toward making more real world applications usable.
The only that works better is 'ZinjaI' . https://jira.reactos.org/browse/CORE-14232
Re: Important reflection
There is no royal road to writing good documentation. Fortunately, poorly written yet technically accurate documentation can be evolved into usable documentation. I suppose those of us who have subject matter expertise or writing skill might use the ReactOS wiki more often. That is a wish. Like a New Year's resolution, it is a wish that rarely succeeds. I do a little editing in the ReactOS wiki. Perhaps I could do more. But that is a wish.
Rosh, when writing new comments in the ReactOS forums, there is no need to quote many lines then add one line of comment. When practical, write comments without quoting earlier comments. When replying to one comment in particular, quote only the relevant portion of that comment.
Finally, anyone can experiment with ReactOS and their favorite Microsoft Windows XP compatible IDE or compiler. Any bugs found that occur with ReactOS but not with Windows XP SP3 or Server 2003 can be reported in the ReactOS JIRA issue reporting system. One can make note of the overall functionality (or lack of functionality) and track the progress oneself in the ReactOS Wiki. See the "Testing Central" page in the ReactOS Wiki, especially the section "What makes an application important".
Edited on May 24, 5:00 PM 2018 PDT in order to revise and extend my earlier remarks.
Rosh, when writing new comments in the ReactOS forums, there is no need to quote many lines then add one line of comment. When practical, write comments without quoting earlier comments. When replying to one comment in particular, quote only the relevant portion of that comment.
Finally, anyone can experiment with ReactOS and their favorite Microsoft Windows XP compatible IDE or compiler. Any bugs found that occur with ReactOS but not with Windows XP SP3 or Server 2003 can be reported in the ReactOS JIRA issue reporting system. One can make note of the overall functionality (or lack of functionality) and track the progress oneself in the ReactOS Wiki. See the "Testing Central" page in the ReactOS Wiki, especially the section "What makes an application important".
Edited on May 24, 5:00 PM 2018 PDT in order to revise and extend my earlier remarks.
Last edited by middings on Fri May 25, 2018 2:05 am, edited 2 times in total.
-
- Developer
- Posts: 246
- Joined: Fri Dec 19, 2014 10:00 pm
Re: Important reflection
Noone is stopping this person to spend a year writing documentation.
Re: Important reflection
In my day OS development was in assembler language only, the only extensions were via assembler macros. C has demonstrated itself as a capable language for use in Linux development. My concern about any OS development is too many languages. It takes years to become really proficient in one, after a few years I thought myself to be a master of IBM assembly language, then encountered the 3705 operating system and learned it was very similar and there was an extensive macro language built into the assembler which made cross platform assembly possible.
Adding languages one on top of another will likely harm development. If anything a standardized base development virtual machine should be defined, and tools added to assist in development. Consider while in alpha ReactOS may not function well as a stand alone operating system. Create and maintain a suggested virtual machine environment with tools as possible to assist in development. Going virtual may allow for faster development beyond alpha. Consider beta once most problems in alpha are resolved. THEN target real machines.
IBM 360 / 370 computers had something called program event recording, this could cause an executed program to experience an exception based on many things (values of registers, branches, execution in specific address ranges or use of particular instruction types). Program event recording allowed an exception on each instruction execution, VM 370 and VM 67 permitted you to run a virtual machine operating system and track each instruction then evaluate registers and memory an instruction at a time. This allowed real operating system code to be stopped at a checkpoint for development or on an exception and evaluated. It permitted changing addresses and register content if desired.
Programming in assembler aside from macro language there is usually a 1 to 1 machine code relation and program even recording made it easy to track new pieces of code to assure they performed correctly. It made diagnosing errors easier (if we had a crash, we could go back in a dump, identify a point of failure then test it live in a virtual machine). In cases where operating system critical features are being developed (page fault processing, flag or buffer corruption, even bad or invalid branching) these could be evaluated as if running live and repaired.
Particularly useful for first level interrupt handlers this feature was important as it helped assure fastest processing of an exception possible. A development environment which works with assembler or C where code can be tracked as it is executed to the code which was assembled or compiled would be helpful to any OS developer. Adding compilers will only weaken OS development, core kernel functions should almost without exception be written in assembler if they will be executed often.
Development on a black box kernel feature may tested in a language other than assembler imo. Frequently used kernel functions must be efficient and must be coded in assembler or if not totally vital due to frequency of use in C. Adding other languages will not help in the long term. Outside the basic OS, it likely doesn't matter as much. Particularly for optional or not frequently used stuff.
A ReactOS development platform could be useful to developers and could help move to a beta faster. A common ReactOS VM and common development tools which are shared and documented will help make it easier to develop imo.
Adding languages one on top of another will likely harm development. If anything a standardized base development virtual machine should be defined, and tools added to assist in development. Consider while in alpha ReactOS may not function well as a stand alone operating system. Create and maintain a suggested virtual machine environment with tools as possible to assist in development. Going virtual may allow for faster development beyond alpha. Consider beta once most problems in alpha are resolved. THEN target real machines.
IBM 360 / 370 computers had something called program event recording, this could cause an executed program to experience an exception based on many things (values of registers, branches, execution in specific address ranges or use of particular instruction types). Program event recording allowed an exception on each instruction execution, VM 370 and VM 67 permitted you to run a virtual machine operating system and track each instruction then evaluate registers and memory an instruction at a time. This allowed real operating system code to be stopped at a checkpoint for development or on an exception and evaluated. It permitted changing addresses and register content if desired.
Programming in assembler aside from macro language there is usually a 1 to 1 machine code relation and program even recording made it easy to track new pieces of code to assure they performed correctly. It made diagnosing errors easier (if we had a crash, we could go back in a dump, identify a point of failure then test it live in a virtual machine). In cases where operating system critical features are being developed (page fault processing, flag or buffer corruption, even bad or invalid branching) these could be evaluated as if running live and repaired.
Particularly useful for first level interrupt handlers this feature was important as it helped assure fastest processing of an exception possible. A development environment which works with assembler or C where code can be tracked as it is executed to the code which was assembled or compiled would be helpful to any OS developer. Adding compilers will only weaken OS development, core kernel functions should almost without exception be written in assembler if they will be executed often.
Development on a black box kernel feature may tested in a language other than assembler imo. Frequently used kernel functions must be efficient and must be coded in assembler or if not totally vital due to frequency of use in C. Adding other languages will not help in the long term. Outside the basic OS, it likely doesn't matter as much. Particularly for optional or not frequently used stuff.
A ReactOS development platform could be useful to developers and could help move to a beta faster. A common ReactOS VM and common development tools which are shared and documented will help make it easier to develop imo.
Who is online
Users browsing this forum: Ahrefs [Bot], Semrush [Bot] and 79 guests