Hello,
With Windows 10 the getversionEx don't work without following this MSDN article:
"Targetting your application four windows "
Thefunction need a manifest to work.
It's what i do in this vc++ project and it work.
But ....
Try the same thing with masm(jwasm) and he don't work,Why !!!!!!!!
there is no manifest in this console-mode program
http://masm32.com/board/index.php?topic=4653.msg50128#msg50128 (http://masm32.com/board/index.php?topic=4653.msg50128#msg50128)
and here is what he return on Windows 10
Quote
〱.0
Press any key to continue ...
Let me know if there is a getversionEx sample who return 10.0
I WANT IT (dead or alive) !!!!!!!!
.386
.model flat, stdcall
option casemap:none
ExitProcess proto stdcall :dword
includelib kernel32.lib
RtlGetVersion proto stdcall :dword
includelib ntdll.lib
printf proto cdecl :vararg
_getch proto cdecl
includelib msvcrt.lib
RTL_OSVERSIONINFOEXW struct
dwOSVersionInfoSize dd ? ; ULONG
dwMajorVersion dd ? ; ULONG
dwMinorVersion dd ? ; ULONG
dwBuildNumber dd ? ; ULONG
dwPlatformId dd ? ; ULONG
szCSDVersion dw 128 dup (?);
wServicePackMajor dw ?
wServicePackMinor dw ?
wSuiteMask dw ?
wProductType db ?
wReserved db ?
RTL_OSVERSIONINFOEXW ends
.data
osviex RTL_OSVERSIONINFOEXW <sizeof RTL_OSVERSIONINFOEXW>
sMsg db "Version %u.%u",13,10,0
sEnd db "Press any key to continue...",13,10,0
.code
mainCRTStartup proc c
invoke RtlGetVersion, offset osviex
invoke printf, offset sMsg, osviex.dwMajorVersion, osviex.dwMinorVersion
invoke printf, offset sEnd
invoke _getch
invoke ExitProcess, 0
mainCRTStartup endp
end mainCRTStartupLIBRARY ntdll.dll
EXPORTS
_RtlGetVersion@4=RtlGetVersion
Quote from: ToutEnMasm on October 31, 2015, 01:03:47 AMLet me know if there is a getversionEx sample who return 10.0
I WANT IT (dead or alive) !!!!!!!!
There isn't. You have to use the right API:
Quote from: sinsi on October 02, 2015, 01:42:15 PMNetWkstaGetInfo returns JOHN runs OS version 10.0
try this program Yves
no manifest, no compatibilty mode, no UAC
Those who don't have masm32
.386
.model flat, stdcall
option casemap:none
ExitProcess proto stdcall :dword
includelib kernel32.lib
printf proto cdecl :vararg
_getch proto cdecl
includelib msvcrt.lib
.data
sMsg db "Version %u.%u",13,10,0
sEnd db "Press any key to continue...",13,10,0
.code
mainCRTStartup proc c
mov edx,fs:[30h]
;mov eax,[edx+0A4h]
;mov ebx,[edx+0A8h]
;invoke printf, offset sMsg, eax, ebx
invoke printf, offset sMsg, [edx+0A4h], [edx+0A8h]
invoke printf, offset sEnd
invoke _getch
invoke ExitProcess, 0
mainCRTStartup endp
end mainCRTStartup
Thanks for your help :greenclp:
But all methods (except wmi) don't get as many information as OSVERSIONINFOEX.
Another question is:
Is my prog in masm less compatible with other system if the manifest don't work.The annoying question is here.
I dont see differencetypedef struct _OSVERSIONINFOEXW {
ULONG dwOSVersionInfoSize;
ULONG dwMajorVersion;
ULONG dwMinorVersion;
ULONG dwBuildNumber;
ULONG dwPlatformId;
WCHAR szCSDVersion[128];
USHORT wServicePackMajor;
USHORT wServicePackMinor;
USHORT wSuiteMask;
UCHAR wProductType;
UCHAR wReserved;
} RTL_OSVERSIONINFOEXW, *PRTL_OSVERSIONINFOEXW;
typedef struct _OSVERSIONINFOEX {
DWORD dwOSVersionInfoSize;
DWORD dwMajorVersion;
DWORD dwMinorVersion;
DWORD dwBuildNumber;
DWORD dwPlatformId;
TCHAR szCSDVersion[128];
WORD wServicePackMajor;
WORD wServicePackMinor;
WORD wSuiteMask;
BYTE wProductType;
BYTE wReserved;
} OSVERSIONINFOEX, *POSVERSIONINFOEX, *LPOSVERSIONINFOEX;
HI, TOUTENMASM,
GetVersionEx (https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451(v=vs.85).aspx), is officially deprecated starting in Windows Operating System version 8.1. You CANNOT get accurate version information in a way that works in both Windows 7 and Windows 8. In Windows 8.1, GetVersionEx returns 6.2.9200, which is the version number for Windows 8.0.
Microsoft recommends that for Operating Systems, 8.1 and higher, you use: Version Helper Functions, MSDN (https://msdn.microsoft.com/en-us/library/windows/desktop/dn424972(v=vs.85).aspx)
...I know that you are familiar with WMI: Win32_OperatingSystem Class, MSDN (https://msdn.microsoft.com/en-us/library/aa394239(v=vs.85).aspx)
deprecated but can work with c++ adding a manifest.
https://msdn.microsoft.com/fr-fr/library/office/dn481241.aspx
I have done it it work
that's not the same as your manifest
yours has a "IA64" line in it that doesn't make sense for 32-bit code
...Hhhmmm,...
I wonder why Microsoft is making it so difficult just to get accurate Operating System information,...
...It doesn't make sense,...assembly programmers are disgruntled,... ::)
i've heard that Frenchmen are easily pleased :biggrin:
INCLUDE \masm32\include\masm32rt.inc
.CODE
Start:
print chr$('10.0'),13,10
inkey
exit
END Start
Quote from: Zen on October 31, 2015, 07:55:15 AM
...Hhhmmm,...
I wonder why Microsoft is making it so difficult just to get accurate Operating System information,...
...It doesn't make sense,...assembly programmers are disgruntled,... ::)
Looks like : meanwhile system difficult itself - dependences check like in nix-systems package manager appearing, in analogue susbsystem like manifests - means this dependences itself is manifests.
:biggrin:
Find the soluce
In the sample upper , i have added a proc in asm called by the winmain.
// targetting.cpp : définit le point d'entrée pour l'application.
//
#include "stdafx.h"
#include "targetting.h"
#pragma comment (lib,"H://sdkrc81/crt_lib/IX86/release/crt10_32")
// Variables globales :
HINSTANCE hInst; // instance actuelle
CHAR szversion[100];
// __cdecl, __thiscall, __fastcall and the wonderfully named __naked. __stdcall
// Pré-déclarations des fonctions incluses dans ce module de code :
int Version (POSVERSIONINFOA pversion);
int StartJwasmProc(_In_ HINSTANCE hInstance,_In_opt_ HINSTANCE hPrevInstance,
_In_ LPWSTR lpCmdLine,
_In_ int nCmdShow);
int APIENTRY wWinMain(_In_ HINSTANCE hInstance,
_In_opt_ HINSTANCE hPrevInstance,
_In_ LPWSTR lpCmdLine,
_In_ int nCmdShow)
{
UNREFERENCED_PARAMETER(hPrevInstance);
UNREFERENCED_PARAMETER(lpCmdLine);
//OSVERSIONINFOEX * pointeur;
StartJwasmProc(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
return 0;
}
The called asm must be a syscall proto
include sdk32.inc
include conio.sdk
include stdio.sdk
include stdlib.sdk
?StartJwasmProc@@YAHPAUHINSTANCE__@@0PA_WH@Z PROTO syscall hInstance:HINSTANCE ,hPrevInstance:HINSTANCE,\
lpCmdLine:LPWSTR,nCmdShow:DWORD
;includelib msvcrt.lib
includelib H:\sdkrc81\crt_lib\IX86\release\crt10_32.lib ;needed only windows 10
;InitInstance PROTO :DWORD
.const
;EXTERNDEF sprintf_s
TXT MACRO quoted_text:VARARG
local etiquette
.data
etiquette db quoted_text,0
.code
EXITM<addr etiquette>
ENDM
.data
osversion OSVERSIONINFOEX <>
chaine db 200 dup(0)
.code
;StartJwasmProc(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
?StartJwasmProc@@YAHPAUHINSTANCE__@@0PA_WH@Z proc syscall hInstance:HINSTANCE ,hPrevInstance:HINSTANCE,\
lpCmdLine:LPWSTR,nCmdShow:DWORD
lea edx,osversion
mov [edx].OSVERSIONINFOEX.dwOSVersionInfoSize,sizeof OSVERSIONINFOEX ;156
invoke GetVersionEx,edx ;OSVERSIONINFOEX <>
invoke sprintf_s,addr chaine,sizeof chaine,TXT("Windows version %d.%d",13,10,\
"Windows prouctype %d",13,10," Platformid %d"),osversion.dwMajorVersion,osversion.dwMinorVersion,osversion.wProductType,osversion.dwPlatformId
invoke MessageBox,NULL,addr chaine,TXT("JWASM"),MB_OK
mov eax,0
ret
?StartJwasmProc@@YAHPAUHINSTANCE__@@0PA_WH@Z endp
end
and now you have here the first asm proc able to return the correct value with GetversionEx.
The method give at the asm prog the same properties as the c++ proc.
Manifest do the trick, look here (https://msdn.microsoft.com/en-us/library/windows/desktop/dn481241%28v=vs.85%29.aspx)<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!-- Application supports Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
<!-- Application supports Windows 8.1 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!-- Application supports Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!-- Application supports Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!-- Application supports Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
</application>
</compatibility>
</assembly> .386
.model flat, stdcall
option casemap:none
ExitProcess proto stdcall :dword
GetVersionExA proto stdcall :dword
includelib kernel32.lib
printf proto cdecl :vararg
_getch proto cdecl
includelib msvcrt.lib
OSVERSIONINFOEXA struct
dwOSVersionInfoSize dd ?
dwMajorVersion dd ?
dwMinorVersion dd ?
dwBuildNumber dd ?
dwPlatformId dd ?
szCSDVersion db 128 dup (?)
wServicePackMajor dw ?
wServicePackMinor dw ?
wSuiteMask dw ?
wProductType db ?
wReserved db ?
OSVERSIONINFOEXA ends
.data
osviex OSVERSIONINFOEXA <sizeof OSVERSIONINFOEXA>
sMsg db "Version %u.%u",13,10,0
sEnd db "Press any key to continue...",13,10,0
.code
mainCRTStartup proc c
invoke GetVersionExA, offset osviex
invoke printf, offset sMsg, osviex.dwMajorVersion, osviex.dwMinorVersion
invoke printf, offset sEnd
invoke _getch
invoke ExitProcess, 0
mainCRTStartup endp
end mainCRTStartup
I know all the trick on the subject that i have already posted.
They don't work with asm Under WINDOWS 10.
If you have a full application who can be tested,post it here.
Sure
Quote from: ToutEnMasm on November 01, 2015, 04:43:24 AM?StartJwasmProc@@YAHPAUHINSTANCE__@@0PA_WH@Z proc syscall ...
man's work - extern "C" would be too simple ;)
Ok,the extern "C" made the name more simple.
For the manifest he had no effect in a Windows prog in Windows 10.
Your prog is a dos (not Windows) and not compiled in Windows 10.
In this case,it is more simple to solve.
The _getch function in used need a special lib,it is INLINE in Windows 10,it's at that I see you haven't compile it Under Windows 10.
The c++ (/WX-) made the job instead of the manifest
I search a way to put the wWinMain proc in a lib who works as the msvcrt.lib,that is just include the lib with no declaration of the entry point ?
any idea ?
Quote from: ToutEnMasm on November 01, 2015, 07:18:55 PM
For the manifest he had no effect in a Windows prog in Windows 10.
Your prog is a dos (not Windows) and not compiled in Windows 10.
The _getch function in used need a special lib,it is INLINE in Windows 10,it's at that I see you haven't compile it Under Windows 10.
My example is compiled and tested under Windows 10.
My msvcrt.dll is version 7.10....
and _getch() is there.
i create msvcrt.lib from msvcrt.def like this
LIBRARY msvcrt.dll
EXPORTS
printf
scanf
wprintf
_getchPlease use PEView.exe (http://wjradburn.com/software/) to examine that program.
I don't mess with Visual Studio 2015.
Quote from: ToutEnMasm on November 01, 2015, 07:12:14 AM
I know all the trick on the subject that i have already posted.
They don't work with asm Under WINDOWS 10.
If you have a full application who can be tested,post it here.
Quote from: jj2007 on October 06, 2015, 03:45:38 AMRtlGetNtVersionNumbers returns hardcoded version numbers.
The issue here is whether you really want to know the OS version, then RtlGetNtVersionNumbers is the way to go, or whether you want to tell your app "you are running in xyz, believe it or not". The other options rely on the TIB, and Windows will set it based on compatibility modes.
RtlGetNtVersionNumbers returns hardcoded version numbers.
The issue here is whether you really want to know the OS version, then RtlGetNtVersionNumbers is the way to go, or whether you want to tell your app "you are running in xyz, believe it or not". The other options rely on the TIB, and Windows will set it based on compatibility modes.
RtlGetNtVersionNumbers returns hardcoded version numbers.
The issue here is whether you really want to know the OS version, then RtlGetNtVersionNumbers is the way to go, or whether you want to tell your app "you are running in xyz, believe it or not". The other options rely on the TIB, and Windows will set it based on compatibility modes.
RtlGetNtVersionNumbers returns hardcoded version numbers.
The issue here is whether you really want to know the OS version, then RtlGetNtVersionNumbers is the way to go, or whether you want to tell your app "you are running in xyz, believe it or not". The other options rely on the TIB, and Windows will set it based on compatibility modes.
(I know it's difficult to understand, so I repeated it a few times 8))
Output for Win7-64, no compatibility mode:RtlGetVersion 6.1 SP 1.0 build 7601
Suite mask 0300: SINGLEUSERTS PERSONAL
ProductType WORKSTATION
CSDVersion Service Pack 1
RtlGetNtVersionNumbers (same for all 'compatibility modes'):
major 6
minor 1
build 7601Output for Win7-64 but compatibility mode 'server 2008':
RtlGetVersion 6.0 SP 1.0 build 6001
Suite mask 0300: SINGLEUSERTS PERSONAL
ProductType WORKSTATION
CSDVersion Service Pack 1
RtlGetNtVersionNumbers:
major 6
minor 1
build 7601
Output for Win7-64 but compatibility mode 'Vista SP2':
RtlGetVersion 6.0 SP 2.0 build 6002
Suite mask 0300: SINGLEUSERTS PERSONAL
ProductType WORKSTATION
CSDVersion Service Pack 2
RtlGetNtVersionNumbers:
major 6
minor 1
build 7601
Output for Win7-64 but compatibility mode 'Vista':
RtlGetVersion 6.0 SP 0.0 build 6000
Output for Win7-64 but compatibility mode 'Windows 7':
RtlGetVersion 6.1 SP 0.0 build 7600
GetVersionPEB example don't follow compatibility mode?
For your re-posted sample it is always in dos mode.
Did you know what is a Windows program?????
I repeat the problem.
The problem is to have the same results using the c++ or masm in Windows mode.
Miss an answer:
Where can be found the printf function in Windows 10 ?????
here:
Quote
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt\stdio.h
_Check_return_opt_
_CRT_STDIO_INLINE int __CRTDECL printf(
_In_z_ _Printf_format_string_ char const* const _Format,
...)
#if defined _NO_CRT_STDIO_INLINE
;
#else
{
int _Result;
va_list _ArgList;
__crt_va_start(_ArgList, _Format);
_Result = _vfprintf_l(stdout, _Format, NULL, _ArgList);
__crt_va_end(_ArgList);
return _Result;
}
#endif
I am agree to pay for an asm compiler able to compile INLINE functions written in c++
Quote from: ToutEnMasm on November 02, 2015, 12:49:54 AM
For your re-posted sample it is always in dos mode.
Did you know what is a Windows program?????
???????????? ::)
Do you you mean console-mode?
That looks better,but:
You use the poasm tools who import is own libraries.
I use only the sdk libraries.
It isn't the same things.
Hi ToutEnMasm,
Concerning the symbol decoration problem, you can use Agner Fog's objconv tool to rename the symbols :
http://agner.org/optimize/
Thanks,
Perhaps Someone have the answer to Library question.
I had try to put the start proc in C++ in a Library,the c++ proc is given as the entry point.
This work with a c source file (the Library work as the msvcrt.lib),WinMain entry point.
But,there is no effect on getversionex who failed.
The same proc in a .cpp accept to build a lib,he accept only wWinMain or WinMainCRTStartup as name.
Then when included lib,the start don't work with msvcrt.lib.There is only the /ENTRY option who work but had not the same effect.
Any experiment in this ?
Quote from: ToutEnMasm on November 02, 2015, 12:49:54 AM
For your re-posted sample it is always in dos mode.
Did you know what is a Windows program?????
I repeat the problem.
The problem is to have the same results using the c++ or masm in Windows mode.
Never heard of such crap ::)
You mean Windoze, ehm, "fenetres"? And they follow different rules, really?
:dazzled:
it is correct for my XP SP3 (although it does not say media center edition - not expected)
it reports 5.1.2600, SP3
Jochen - do you see how RtlGetNtVersionNumbers gets the build number ?
is it also in the TEB ?
Quote from: dedndave on November 02, 2015, 05:08:21 AMJochen - do you see how RtlGetNtVersionNumbers gets the build number ?
is it also in the TEB ?
No, it's not the TEB - it's hardcoded in ntdll.dll :P
77456CEE ³. 8B45 08 mov eax, [ebp+8]
77456CF1 ³. 85C0 test eax, eax
77456CF3 ³. 74 06 jz short 77456CFB
77456CF5 ³. C700 06000000 mov dword ptr [eax], 6
77456CFB ³> 8B45 0C mov eax, [ebp+0C]
77456CFE ³. 85C0 test eax, eax
77456D00 ³. 74 06 jz short 77456D08
77456D02 ³. C700 01000000 mov dword ptr [eax], 1That is why you get the true OS version. The TEB has what Windows pokes there - and this depends on manifest crap and/or "compatibility modes". Although, sometimes this may actually be what you need ::)
thanks - not that the build number helps that much - lol
very interesting also is how WMI do to find all the needed iformations