Version info

[Ge van Geldorp]

After reading a question on the forum, I decided to find out exactly what is
keeping Visual Basic programs from running and see if it's easy to fix. It
turns out that about the first thing that the VB runtime (msvbvm60.dll) does
is check the version number of the OS. At the moment we return:

dwMajorVersion = 4
dwMinorVersion = 0
dwBuildNumber = 0
dwPlatformId = 2
szCSDVersion = "ReactOS 0.2.5-CVS (Build 20041216)"
wServicePackMajor = 6
wServicePackMinor = 0
wSuiteMask = 0
wProductType = 0

The VB runtime wants at least NT4/SP3. The checks that currently fail are
dwBuildNumber (needs at least 1381) and the check for the service pack. It
expects the szCSDVersion field to be "Service Pack x" and extracts the
service pack number from that. (Good thing btw that there are not more than
10 service packs for NT4...).
Anyway, dwBuildNumber will have to be increased to 1381, that's no problem.
But the szCSDVersion is currently the only way for usermode programs to get
the ReactOS version. I know it's used by e.g. cmd.exe to display the version
number.
So, I don't think we have much choice, szCSDVersion will have to be set to
"Service Pack 6". Question is how to make the ReactOS version string
available. I've been thinking about adding it after the "Service Pack 6"
string (so the sp6 string is terminated with a nul byte, following the nul
byte is the ReactOS version string). Another option would be to store it in
the registry, but that would mean that it could get out of sync with the
version info in the kernel.
So, I'd like to store it as second string in szCSDVersion. Any objections to
that?

Gé van Geldorp.

[Gunnar Dalsnes]

>   So, I'd like to store it as second string in
> szCSDVersion. Any objections to
>  that? 
What will happend it i run apps that rely on this behaviour (cmd.exe) on 
Windows? The stuff past the nullterm on windows will likely contain 
garbage. Checking for magic chars past the windows nullchar ("ros" etc.) 
might solve this tho.

You must also be sure to not read more that 128 chars, since its 
possible that the string past the windows string does not contain any 
nullchars (on Windows), and we might read out of bounds. The magic chars 
will solve this problem also tho.

Functions/macros that check for the magic chars etc. and return a char* 
if valid/null ptr. if not would be nice;-)

Regards
Gunnar

>   
>  Gé van Geldorp.
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>  
>  
>  
>

[Ge van Geldorp]

>   From: Gunnar Dalsnes
>  
> >   So, I'd like to store it as second string in
> > szCSDVersion. Any 
> >  objections to that? 
>  
>  What will happend it i run apps that rely on this behaviour 
>  (cmd.exe) on Windows? The stuff past the nullterm on windows
>  will likely contain garbage. Checking for magic chars past
>  the windows nullchar ("ros" etc.) might solve this tho. 
As an extra line of defense, my idea was that apps which are going to depend
on this behaviour (ReactOS aware apps) set szCSDVersion to all nulls before
calling GetVersion. If the first few nulls after the windows nullchar are
magically changed to "ReactOS" it's a pretty good indication you're
actually
running on ReactOS. Ofcourse, the apps should still have the safeguards you
described (max string length etc.)

Gé van Geldorp.

[art yerkes]

On Thu, 16 Dec 2004 20:05:49 +0100
"Ge van Geldorp" <gvg(a)reactos.com> wrote:

>   > From: Gunnar Dalsnes
>  > 
>  > > So, I'd like to store it as second string in szCSDVersion. Any 
>  > > objections to that?
>  > 
>  > What will happend it i run apps that rely on this behaviour 
>  > (cmd.exe) on Windows? The stuff past the nullterm on windows
>  > will likely contain garbage. Checking for magic chars past
>  > the windows nullchar ("ros" etc.) might solve this tho. 
I wonder if there's any way to make this configurable so that it could
be tailored a bit.  Is there a way to take action based on what exe or
dll we were called from?  Maybe we shouldn't do it now, but it sounds
like it might be convenient later.  
-- 
Here's a simple experiment. Stand on a train track between two locomotives
which are pushing on you with equal force in opposite directions. You will
exhibit no net motion. None the less, you may soon begin to notice that
something important is happening.
-- Robert Stirniman

[Ge van Geldorp]

>   From: art yerkes
>  
>  I wonder if there's any way to make this configurable so that 
>  it could be tailored a bit.  Is there a way to take action 
>  based on what exe or dll we were called from?  Maybe we 
>  shouldn't do it now, but it sounds like it might be 
>  convenient later.   
There's code in ntdll (ntdll/ldr/startup.c LoadCompatibilitySettings) which
does this. It uses the exe name to look up a registry entry in
HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers and
sets the PEB fields accordingly. The PEB fields are then later used in
GetVersionEx(). Doesn't solve the problem for VB though, since it keys on
exe name and not dll name.

Ge van Geldorp.

[Royce Mitchell III]

I have spent the past 2 days writing a brand-new PagedPool algorithm. 
Here is the culmination of my work.

This new pagedpool has some test code embedded in the file.

Those tests take 703 ticks on my laptop with the old paged pool, but 
executed in 78 ticks with the new paged pool code.

This new paged pool is also capable of supporting multiple pools ( as 
has been requested ).

I am declaring this code bug-free, but I would like some testers to 
verify they can also boot reactos before I commit such a major change.

Please test this and let me know if you have any problems ( just extract 
both files into ntoskrnl/mm directory and rebuild ntoskrnl )

[Robert Köpferl]

What about extra handling for diverse Programs or module names?
I don't really like that idea, either. However it's nothing else than 
what setver.sys does ever since. All modules do have to run on ROS. If 
they intend to check the CSD-Version info, the module seems to have a 
reason for it. If it turns out that the module is badly written and wil 
choose a false conclusion and we want it to run, though, then we have to 
lye in some way to that module. This cases however must be stored somewhere.

Ge van Geldorp wrote:
>   After reading a question on the forum, I decided to
> find out exactly what is
>  keeping Visual Basic programs from running and see if it's easy to fix. It
>  turns out that about the first thing that the VB runtime (msvbvm60.dll) does
>  is check the version number of the OS. At the moment we return:
>  
>  dwMajorVersion = 4
>  dwMinorVersion = 0
>  dwBuildNumber = 0
>  dwPlatformId = 2
>  szCSDVersion = "ReactOS 0.2.5-CVS (Build 20041216)"
>  wServicePackMajor = 6
>  wServicePackMinor = 0
>  wSuiteMask = 0
>  wProductType = 0
>  
>  The VB runtime wants at least NT4/SP3. The checks that currently fail are
>  dwBuildNumber (needs at least 1381) and the check for the service pack. It
>  expects the szCSDVersion field to be "Service Pack x" and extracts the
>  service pack number from that. (Good thing btw that there are not more than
>  10 service packs for NT4...).
>  Anyway, dwBuildNumber will have to be increased to 1381, that's no problem.
>  But the szCSDVersion is currently the only way for usermode programs to get
>  the ReactOS version. I know it's used by e.g. cmd.exe to display the version
>  number.
>  So, I don't think we have much choice, szCSDVersion will have to be set to
>  "Service Pack 6". Question is how to make the ReactOS version string
>  available. I've been thinking about adding it after the "Service Pack 6"
>  string (so the sp6 string is terminated with a nul byte, following the nul
>  byte is the ReactOS version string). Another option would be to store it in
>  the registry, but that would mean that it could get out of sync with the
>  version info in the kernel.
>  So, I'd like to store it as second string in szCSDVersion. Any objections to
>  that?
>  
>  Gé van Geldorp.
>  
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>

[Maarten Bosma]

Can't programms like cmd.exe not just preset some of the variables in the
structure
 before sending it to reactos ?

Ge van Geldorp wrote:
>   After reading a question on the forum, I decided to
> find out exactly what 
is
>   keeping Visual Basic programs from running and see if
> it's easy to fix. It
>  turns out that about the first thing that the VB runtime (msvbvm60.dll) 
does
>   is check the version number of the OS. At the moment
> we return:
>
>  dwMajorVersion = 4
>  dwMinorVersion = 0
>  dwBuildNumber = 0
>  dwPlatformId = 2
>  szCSDVersion = "ReactOS 0.2.5-CVS (Build 20041216)"
>  wServicePackMajor = 6
>  wServicePackMinor = 0
>  wSuiteMask = 0
>  wProductType = 0
>
>  The VB runtime wants at least NT4/SP3. The checks that currently fail are
>  dwBuildNumber (needs at least 1381) and the check for the service pack. It
>  expects the szCSDVersion field to be "Service Pack x" and extracts the
>  service pack number from that. (Good thing btw that there are not more 
than
>   10 service packs for NT4...).
>  Anyway, dwBuildNumber will have to be increased to 1381, that's no 
problem.
>   But the szCSDVersion is currently the only way for
> usermode programs to 
get
>   the ReactOS version. I know it's used by e.g.
> cmd.exe to display the 
version
>   number.
>  So, I don't think we have much choice, szCSDVersion will have to be set to
>  "Service Pack 6". Question is how to make the ReactOS version string
>  available. I've been thinking about adding it after the "Service Pack 6"
>  string (so the sp6 string is terminated with a nul byte, following the nul
>  byte is the ReactOS version string). Another option would be to store it 
in
>   the registry, but that would mean that it could get
> out of sync with the
>  version info in the kernel.
>  So, I'd like to store it as second string in szCSDVersion. Any objections 
to
>   that?
>
>  Gé van Geldorp.
>

[Jonathan Wilson]

Is there any reason for ReactOS to return different values in response to 
operating system version information queries?

Assuming the windows implementation in ReactOS is written correctly, 
ReactOS should look to an app just like whatever version of windows it 
claims to be. (NT4 I think in this case)

IMNSHO, the point of ReactOS (or more specifically those parts that match 
with the API calls that userspace WIN32 applications see and can call) is 
to look as close to <some version of> windows as it is possible to get 
without violating microsoft IP rights somewhere. (e.g. we shouldnt look at 
the leaked MS source code or directly take any code, icons or whatever else 
from MS).

[Joseph Galbraith]

I can imagine an application that wants to take
advantage of specific ReactOS features wanting
to be able to discern at runtime whether or
not the current system is ReactOS or plain-vanilla
windows.

How about a seperate API (RosGetVersion) to query the
'Reactos Native' version, and let GetVersion() and
GetVersionEx() query the emulated 'Win32' version.

Applications that want to use RosGetVersion() and
still run on windows can easily use 'GetProcAddress'
on 'RosGetVersion()' to tell if they are running
under ReactOS, and if GetProcAddress() succeeds,
they can then call the RosGetVersion() API to find
specific version information.

This seems very clean to me.

- Joseph

Jonathan Wilson wrote:
>   Is there any reason for ReactOS to return different
> values in response 
>  to operating system version information queries?
>  
>  Assuming the windows implementation in ReactOS is written correctly, 
>  ReactOS should look to an app just like whatever version of windows it 
>  claims to be. (NT4 I think in this case)
>  
>  IMNSHO, the point of ReactOS (or more specifically those parts that 
>  match with the API calls that userspace WIN32 applications see and can 
>  call) is to look as close to <some version of> windows as it is possible 
>  to get without violating microsoft IP rights somewhere. (e.g. we 
>  shouldnt look at the leaked MS source code or directly take any code, 
>  icons or whatever else from MS).
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>

[K McI]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Joseph Galbraith wrote:
| I can imagine an application that wants to take
| advantage of specific ReactOS features wanting
| to be able to discern at runtime whether or
| not the current system is ReactOS or plain-vanilla
| windows.
|
| How about a seperate API (RosGetVersion) to query the
| 'Reactos Native' version, and let GetVersion() and
| GetVersionEx() query the emulated 'Win32' version.
|
| Applications that want to use RosGetVersion() and
| still run on windows can easily use 'GetProcAddress'
| on 'RosGetVersion()' to tell if they are running
| under ReactOS, and if GetProcAddress() succeeds,
| they can then call the RosGetVersion() API to find
| specific version information.
|
| This seems very clean to me.
|
| - Joseph

I don't know how feasible that is, but it seems to be better then hoping
that apps wont notice the ROS info stuck on the end of long string.

~     -uniQ
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFBxzEq7mze81O92HkRAvDQAKCLVj6x+dQ3ms7jtixeu0eeo9gKzQCff12K
> PTgDotUipsxHj9MOsIEmPrw=
> =k5IE
> -----END PGP SIGNATURE-----