Wanting to build some programs :)

[TheHaiden]

Let me introduce myself first. I've been programming in C++ for over 2 years at a slow pace. I know a bit of Assembly, as well as PHP, Java, Delphi and C#. Right now I just started to learn IOCP as well as driver development. However, I feel I do not have enough knowledge to actually help with the OS's internal workings, and outer such as drivers, networking, etc. without asking for help left and right ha ha.

So let's get down to it. I've been creeping the forum and wiki for some time now, thinking if I have enough time and knowledge to actually help this fantastic piece of art you guys/gal's have been working on. I have a few questions I need to ask, though some may have been posted in the wiki already, but I can no longer find it.

1) I know C is more encouraged to use, but is it acceptable to use C++ for programs?

2) Do I need to follow any specific notation or spacing when developing programs for ReactOS? Seeing as I've used Hungarian Notation, to an extent, for over a year, it'll be quite difficult for me to switch.

3) Are there any programs/utilities that are needed, but yet to have been developed? (E.G; updater, browser, IDE, etc..)

Thank you in advanced. And I apologize if these questions has been stated and answered before.

[TheHaiden]

Sorry for posting again, I could not find the edit button. (Is there one? o.o)

For my 3rd question, I spotted this on the FAQ

Q11 Witch software/apps is do ReactOS needs on to be a completed OS like Windows XP?

E.g ReactOS web browser, email client, msn messenger client, ReactOS software updates, system restore, easy error report software tools to bugzilla.

I do not quite understand this, is it stating that these are the programs that would like to be built?

--
And to my 2nd question, the 6th FAQ section answered it. My bad ha ha.

[vicmarcal]

1) I know C is more encouraged to use, but is it acceptable to use C++ for programs?

2) Do I need to follow any specific notation or spacing when developing programs for ReactOS? Seeing as I've used Hungarian Notation, to an extent, for over a year, it'll be quite difficult for me to switch.

3) Are there any programs/utilities that are needed, but yet to have been developed? (E.G; updater, browser, IDE, etc..)

Thank you in advanced. And I apologize if these questions has been stated and answered before.

There are some FAQs hanging in a Forum thread . They can help you as they are updated
1)We use C++ too , but mainly in explorer.exe. We are developing a explorer-new.exe which needs a lot of love(well, really it needs some COM/OLE code,which it uses, implemented).If you think you can implement COM/OLE backend, tell us . Explorer-new is written in C, but feel free to rewrite or use C++ if needed. Also we have some apps that you may debug and fix.

3)We need to prepare ReactOS for future updates,but it is still tricky.

The best way to help us is fixing our APIs(functions). Here you can find our failed tests: Testman
Winetests tests ReactOS APIS in order to check if they behave as Microsoft ones.An API is just a function that recives params and returns results.So a Winetest is just a call to a function (sending a set of params) and checking that output is correct.If the output is not the expected, it fails.
In MSDN you can find references about how the APIs should work.
Look this one about FindFirstFile API: Document.
And here is our own implementation:Own implementation.
Here some Winetests testing our FindFirstFile API implementation: Eack OK compares the returned value with the expected one.

Windows/Reactos APIS are written in Win32Api (also called WinAPI and Win32) and it is easy to learn, it's C.
So if you are a developer it would be pretty easy for you to find why an API is failing(Is it not checking a NULL param case?maybe the API is not considering an edge case?, Are we forgetting something?, maybe the API calls a function that is returning a wrong result?,etc..)

If you find the issue but not the solution, report your findings it will help a lot.
If you find the solution send us a patch please , our devs will check it before commiing.

[TheHaiden]

1)We use C++ too , but mainly in explorer.exe. We are developing a explorer-new.exe which needs a lot of love(well, really it needs some COM/OLE code,which it uses, implemented).If you think you can implement COM/OLE backend, tell us . Explorer-new is written in C, but feel free to rewrite or use C++ if needed. Also we have some apps that you may debug and fix.

I can work with C, though I haven't touched C in a long time but that is not a problem as I can quickly pick up on the differences. And sadly, I've only worked with COM for a very short time, so I doubt I will be capable of adding COM support but it does seem quite interesting . I do not mind learning new things or learning more of what I do know now, in all honesty I would love to learn as much as I can. (The more you know, the more you can do!) And as odd as some might see it, I do love to debug things.

3)We need to prepare ReactOS for future updates,but it is still tricky.

No doubt it would be a difficult task to create that, but I wasn't talking about just an updater; but everyday programs others could use that has yet to be made specially for ReactOS. Z98 said adding new programs isn't really necessary now, as there are more important things to be done. However, he posted that almost 2 years ago, so I am not sure if this is still the case.

The best way to help us is fixing our APIs(functions). Here you can find our failed tests: Testman
Winetests tests ReactOS APIS in order to check if they behave as Microsoft ones.An API is just a function that recives params and returns results.So a Winetest is just a call to a function (sending a set of params) and checking that output is correct.If the output is not the expected, it fails.
In MSDN you can find references about how the APIs should work.
Look this one about FindFirstFile API: Document.
And here is our own implementation:Own implementation.
Here some Winetests testing our FindFirstFile API implementation: Eack OK compares the returned value with the expected one.

Windows/Reactos APIS are written in Win32Api (also called WinAPI and Win32) and it is easy to learn, it's C.
So if you are a developer it would be pretty easy for you to find why an API is failing(Is it not checking a NULL param case?maybe the API is not considering an edge case?, Are we forgetting something?, maybe the API calls a function that is returning a wrong result?,etc..)

Thank you for them links, they will come in handy! I have spotted a few I could possibly look into and actually might end up with results, most being related to Shell32, User32, maybe Shlwapi and maybe Winmm, though the most I have used out of Winmm is timGetTime().
I will look further into the source (ReactOS's source of course, I have never looked into Windows source code) and documentation on MSDN and see if there is something that is on, or at least hopefully near my level.

Thank you for your time, Vicmarcal, if there is anything else that could help me, whether it be a guideline or a good kick in the right direction, please tell me. I will try my best to help this project as much as I possibly can.

[vicmarcal]

Thank you for your time, Vicmarcal, if there is anything else that could help me, whether it be a guideline or a good kick in the right direction, please tell me. I will try my best to help this project as much as I possibly can.

After giving you the link to our Testman "Findfirstfile" tests, i checked the failures and i found a nice/easy to catch bug.I am sure you will be able to discover why it is failing. Are you man enough?(jkjk)

This is the FindFirstFile test:
http://svn.reactos.org/svn/reactos/trun ... kup#l_2145

2140 SetLastError( 0xdeadbeaf );
2141 strcpy(buffer2, buffer);
2142 strcat(buffer2, "foo\\bar\\nul");
2143 handle = FindFirstFileA(buffer2, &data);
2144 err = GetLastError();
2145 ok ( handle == INVALID_HANDLE_VALUE, "FindFirstFile on %s should Fail\n", buffer2 );
2146 ok ( err == ERROR_PATH_NOT_FOUND, "Bad Error number %d\n", err );

I will explain this one as it is easy:
First,it sets lasts error to 0xdeadbeaf. If you want to know what SetLastError is for, just look MSDN
"buffer" contains C:\
strcpy is another "API" and strcat is another one. Search them in MSDN. (But if you have managed C then i am sure you know what they do)

Ok.Now line 2143.This is the real API test.All before was the "preparation":
So in line 2143: FindFirstFileA is being called as: handle=FindFirstFileA("C:\\foo\\bar\\nul", &data);
Of course c:\foo\bar\nul is a Path that doesnt exist.

How SHOULD "FindFirstFile" behave when a false Path is given to it?MSDN has the answer. (ReactOS APIs have to mimic even the failures!).Google "MSDN FindFirstFile" or use my previous link.

MSDN says that when the Path is not reachable(doesn't exist) SHOULD return INVALID_HANDLE_VALUE and SHOULD set an specific error ERROR_PATH_NOT_FOUND.
So in 2145 it checks if the handle is INVALID_HANDLE_VALUE.If so,ReactOS "FindFirstFile" API behaves the same way than Windows "FindFirstFile" API, and the test is passed.
In 2146 the value of the Error is checked, as the Path is non reachable it should be ERROR_PATH_NOT_FOUND.

But, ey: Looking at the Winetest results, seems both are FAILING: Our API is not returning INVALID_HANDLE_VALUE neither setting the error to ERROR_PATH_NOT_FOUND. Why?

One of the best tools,that ReactOS has, is called DOXYGEN: http://doxygen.reactos.org/

With it, you can view our source code in an easy way: Just write the function in the search box (left column) and hit enter.
Here you have the FindFirstFile: Doxygened FindFirstFile
It is quite handy as ANY function there is really a link to where it is defined.So moving through functions is really FAST!!Also it tells you in which "file.c" is defined, so you can easily find it in your ReactOS sources. Play with it!

In this case FindFirstFileA stores the recived Path in a variable called lpFileName and then calls to FindFirstFileEx, just click on its name and you will be redirected to the place where FindFirstFileEx is coded.
My suggestion is opening this new link in another Tab, so you can have both opened at the same time.
How does FindFirstFileEx behaves? Check MSDN.
FindFirstFileEx will call another API and so on. Keep always an eye in lpFileName, where is it checked?where is it modified?.

Your mission is to follow the lpFileName as somewhere (we don't know where yet) should be checked to know if it is a real path or a false path.

So 3 questions:

EASY: Which API in the chaincall((FindFirstFile->FindFirstFileEx->OtherAPI->OtherAPI....)is checking if the PATH exists?
MEDIUM: When is actually our ReactOS FindFirstFile API returning INVALID_HANDLE_VALUE and ERROR_PATH_VALUE?
MEDIUM: After watching the chaincall where do you suggest to add the PATH check?


This example is perfect to train your skills, you will learn a lot with this example, if you have any doubts...paste them here...but ey: MSDN and GOOGLE and DOXYGEN has all the answers!!

If any other guy or tester wants to send me the solution,do it via PM!!

[TheHaiden]

EASY: Which API in the chaincall((FindFirstFile->FindFirstFileEx->OtherAPI->OtherAPI....)is checking if the PATH exists?

That would be RtlDosPathNameToNtPathName_U, which is used in InternalFindFirstFile

Code: Select all

     bResult = RtlDosPathNameToNtPathName_U (lpFileName,
                                             &NtPathU,
                                             (PCWSTR *)((ULONG_PTR)&PathFileName.Buffer),
                                             &DirInfo);
     if (FALSE == bResult)
     {
         SetLastError(ERROR_PATH_NOT_FOUND);
         return INVALID_HANDLE_VALUE;
     }

RtlDosPathNameToNtPathName_U returns a boolean, true if the path does exist, false if it doesn't (hence the conditional statement underneath )
[/code]

--

When is actually our ReactOS FindFirstFile API returning INVALID_HANDLE_VALUE and ERROR_PATH_VALUE?

ERROR_PATH_VALUE is not a valid system error code? So, it never returns INVALID_HANDLE_VALUE and ERROR_PATH_VALUE? And it can't return both, INVALID_HANDLE_VALUE and ERROR_PATH_VALUE Not too sure about this one.

--

After watching the chaincall where do you suggest to add the PATH check?

I'm kinda confused on what you mean by this. InternalFindFirstFile already checks if the path submitted is valid, setting the last error code to ERROR_PATH_NOT_FOUND and returning INVALID_FILE_HANDLE, thus giving FindFirstFileEx and FindFirstFile's return value INVALID_FILE_HANDLE - why add another patch check?

[vicmarcal]

RtlDosPathNameToNtPathName_U returns a boolean, true if the path does exist, false if it doesn't (hence the conditional statement underneath )
[/code]

Are you sure RtlDosPathNameToNtPathName_U is REALLY returning a boolean: true if the path does exist, false if it doesn't ?
Look at the RtlDosPathNameToNtPathName code and tell me when RtlDosPathNameToNtPathName_U is REALLY returning FALSE

Other hint, look the name of the function: RtlDosPathNameToNtPathName
The function seems to be something like a" translator which translates a DosPathName to a NT PathName". Why is it supposed to check if a Path exists?

ERROR_PATH_VALUE is not a valid system error code? So, it never returns INVALID_HANDLE_VALUE and ERROR_PATH_VALUE? And it can't return both, INVALID_HANDLE_VALUE and ERROR_PATH_VALUE Not too sure about this one.

Nah..this is not the reason .Forget about this for now
--

I'm kinda confused on what you mean by this. InternalFindFirstFile already checks if the path submitted is valid, setting the last error code to ERROR_PATH_NOT_FOUND and returning INVALID_FILE_HANDLE, thus giving FindFirstFileEx and FindFirstFile's return value INVALID_FILE_HANDLE - why add another patch check?

Can you write me the lines of the code which checks if the Path is valid or not?

These lines of code:

Code: Select all

 if (FALSE == bResult)
     {
         SetLastError(ERROR_PATH_NOT_FOUND);
         return INVALID_HANDLE_VALUE;
     }

are not checking if the Path is valid, they are checking if the bResult is FALSE.
So where is the PATH check???

[TheHaiden]

Sorry for the late response, had some troubles with my router.

At first I suspected that the function "RtlDosPathNameToNtPathName_U" checks if the path is valid, I didn't take a deep look into that function, but the conditional statement is what triggered my suspicion. However, this time I took a deeper looked and went with Google and MSDN.

The "NtOpenFile" [ http://msdn.microsoft.com/en-us/library ... s.85).aspx ] is what checks if the path is valid.
NtOpenFile is just a "layer" over "IoCreateFile" [ http://msdn.microsoft.com/en-us/library/ff548418.aspx ].
The return from "NtOpenFile" can be found by using the IO_STATUS_BLOCK structure(not entirely sure if it is a structure).

The part:

Code: Select all

if (Status == STATUS_NOT_A_DIRECTORY && RemovedLastChar)
{

Checks if the path is valid.

This is where I dug into with Doxygen: http://doxygen.reactos.org/d4/d47/dll_2 ... tml#l00247
Around line 343.

[vicmarcal]

Okay!!
Now you can say that you know how the API works , and you can point where the Bug is (more or less)
The next step is "easy":
-Download ReactOS code
-Add debugging code in the function(s) that you think is/are buggy. You can debug a file in several ways, one is using TRACE(),DPRINT() and DPRINT1() functions. These functions work as a "printf" in the DebugLog, i mean, you can use them in ReactOS code to print useful information in the DebugLog.
Imagine you are not really sure if you are going into an IF or if you are going through some code, then you can add a DPRINT1("Ey, I am IN the IF") or much better DPRINT1("lpFileName: \"%ws\"\n", lpFileName); so in the debuglog will appear something like: lpfileName: foo.txt.
Depending on the file,you have to use:
-TRACE("blablaba");
or
-DPRINT/DPRINT1: The difference between DPRINT and DPRINT1 is that DPRINT1 ALWAYS prints the info in the Debuglog, meanwhile DPRINT just prints when you set that file to print debugging output. If ReactOS devs would use always DPRINT1 then our Debuglog would be quite spammed that is the reason that explains the DPRINT existance.
For a fast/easy testing I particulary use the DPRINT1.

Read in our wiki about why some files use Trace and others use DPRINT/DPRINT1 to have a full overview.Also you will find interesting info about how to use them

-After adding these Debugging lines, compile ReactOS.
-Create in Windows a small .exe which tests the FindFirstFile Bug, this is called a testcase.You can easily create the testcase based in the failed Winetest.
-Run the testcase in Windows to check it behaves correctly.
-Install ReactOS in a Virtual Machine, run it, and run the testcase in it.
-Look at the DebugLog ( you can learn how to obtain a DebugLog in our Wiki too), you will see your "NEW-special" dprints/traces appearing there. Cool!
-Find why the testcase is failing thanks to your knowledge and new Debuglog skills.
-If you need to add new DPRINTs, just recompile ReactOS (after the first compilation it will take just a couple of minutes to compile the differences) and reinstall.

After that, feel free to fix the bug or move to a particular ReactOS section you like.All this knowledge can be applied
Hope you liked this small tutorial about reactos code, and how to use ReactOS Tools.
Did you ejoy it?