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.
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@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
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.
On Thu, 16 Dec 2004 20:05:49 +0100 "Ge van Geldorp" gvg@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.
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.
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 )
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@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
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.
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).
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@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
-----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
-
art yerkes -
Ge van Geldorp -
Gunnar Dalsnes -
Jonathan Wilson -
Joseph Galbraith -
K McI -
Maarten Bosma -
Robert Köpferl -
Royce Mitchell III