Hi to all!
Attached to this post is a fully-functional memory reporting utility. This is NOT a usual application; read further.
Program features:
o The Program is compatible and fully functional on Windows systems with any size of memory (RAM and Swap file (sometimes called a paging file)).
In short: The program is not limited to show info only under 4 GB of RAM. It shows the size of memory which is actually installed in the system and supported by the OS. For example, on 32-bit WinXP with PAE enabled, the program will show info about any size of memory, let's say 8 GB. Under old Win9x systems, the program will work and show the proper memory size as well.
o The information is displayed in a format that is comfortable for reading. There are no "crazy" big unreadable numbers, eliminating the need for manual conversion of values. Each size value (i.e. Total RAM size, Free RAM size, Total Paging File size, Free Paging File size) in the results is converted independently.
In short, you may see something like these results (this is an example):
RAM:
Size: 1.998 GB
Free: 987.654 MB
Swap:
Size: 4.998 GB
Free: 3.210 GB
o The program has a useful pseudo-3D "for first-sight" indicator of the free RAM. Indicator has high sensitivity, and graduating from orange color (low amount of free RAM) to green color (high amount of free RAM).
o The program has a shell icon. I'm pointing this out to make it clear that the program does have a Windows resources structure, which contains the icon itself. I.e., the program's file contains about 200 bytes of data which is not required to for functionality, in general; The icon is just "cool stuff" and is what you see as the pseudo-3D indicator from the point above in the program features list (i.e. this point in the features list is just a technical point on the file format and details of complication of implementation in general).
Some parts of the resource structure contains import name strings. Moreover, the control structure of the icon itself contains the imported dll name string (user32.dll).
The resource structure was also modified to be "truncated" a bit. In particular, part of the IAT and part of the resource data are "overheaded" - part of the IAT is actually contained in the start of the resource structure :lol
o The program supposedly works under all Windows versions. The word "supposedly" is not the case for laughing on the "strange_crazy_non-standard-format_etc_etc program", actually, it was tested and working properly on Win95, Win98, Win2000 32 bit (:lol), WinXP 32 bit, Win Vista 32 bit/64 bit, Win7 32 bit/64 bit, Win8 64 bit, and even on Wine 1.3.8. "Supposedly" refers to the fact that the program may not work under future Windows versions. But... any program has a chance to not work under future Windows versions due to some compatibility flaws (also called "revolutionary improvements in the OS").
o The program requires a minimum of a i386 CPU with FPU hardware. Recommended configuration is the i486DX and compatible or better (due to fwait omission) ::)
o The program does not require any runtime libraries (like msvcrt*.dll, crtdll.dll or similar) - it imports the kernel32.dll and user32.dll only.
Decimal fraction notation of FP numbers is supported via tricky "final-integer" code + just wsprintfA of user32.dll, including proper substitution of memory size units. Also, this part of the code (conversion of the binary size of the memory to the resulting formatted string) uses a self-modifying trick for supporting memory of any size, including the possibility of old Win9x.
o The programs size is under 1 KB. It is so small, and works because it has proper format. It works not because of curiousity, but because of the labour that I put into it. So, there is no place for comments about some "specifications", "standards" and "right way of doing things" - it is in compliance with them... This is a fancy remake of the program - stuff just for fun, and that's all.
Originally, the program was not assembled with MASM, it was not recompilable at all and had no textual source code. The program file was just built/edited/modified/developed_further, manually, in the HEX-editor.
The program uses a really crazy-modified PE file to be as small as possible, while maintaining functionality. For this reason, some crappy AVs could easily "proudly reveal" that the program is a virus. This is not true ::)
For now I will try to solve the source code omission problem, and will make the program recompilable. The only thing which will not be implemented in the "sources-mode" program tweak is the resource icon. Due to impossibility of resource modification in a straightforward manner.
Differencies between MemInfoMicro.exe (the original handmade program EXE) and MemInfoMicro25.exe (source-code tweak):
Source-code mode has no icon and thus, no graphical indicator with the code to make it change color; it has no initial code loader which builds startup code from the pieces placed in the header; it does not use self-modifing code; the programs file is a pure PE-file - it is compatible with any operating system, as much as possible, even the author's post-processed source-code compiled EXE, which is placed in the archive.
Notes on source-code tweak: Even if it isn't straightforward, we can still do some tricks :bg We can put some strings in the stub field of the PE header. This is actually a proper method, in accordance with the spec. So, I've made the binary stub with the required strings, and 3 BATch files for program compilation - one is the standard, simple compilation without any tricks. The other two - for LINK and POLINK, which use a crafted stub as the "data section". When you use one of these two BATch files, you'll get an EXE file with a size of 1 KB, and this file will be straightforwardly compatible with the spec. So, still, this is the program with the size of 1 KB (author's post-processed EXE is under 1 KB, and it is still in full compliance with the specifications). Read comments in the BAT files.
Testing on any Windows systems is greatly appreciated, as well as reporting any flaws. Also very much appreciated are reports about successful tests on Windows operating systems not listed in the tested OS list in the program features list.
Many thanks to Frank (frktons) for patient testing of the program under Windows 7 x64!
Many thanks to MASM32 project, which inspired me to build these kinds of utilities!
Many thanks to all people who will test or have already tested this program and report(ed) results.
Many thanks to Alan (redskull) who found a non-exiting bug due to hanging on parasitive thread on some configurations of Win Vista.
Many thanks to Dave (dedndave) who was very kind to check and to properly edit the text you're reading, as well as comments in the sources.
You may use this program any way you want, so long as you preserve the copyright (it is MINE :)), and at your own risk.
This program is not a virus, but I have no responsibility for usage of the information provided or techniques used in this program.
The archive attached to this post contains the program. Feedback and testing is welcome.
There is an screenshots under different Windows, to prove my text:
(http://www.masm32.com/board/index.php?action=dlattach;topic=15159.0;id=8287)
Thanks to Frank for making screenshot under Windows 7 x64!
Not needed to download file attached to *this* post - it is just image which is shown in this post.
Alex
I cannot believe - no one download the program! Peoples, this is NOT a virus!!!
Alex
Quote from: Antariy on October 25, 2010, 09:37:02 PM
I cannot believe - no one download the program! Peoples, this is NOT a virus!!!
Avira says it's a virus - but I trust you more than I trust Avira, of course :green2
Alex, you are a madman, but it works just fine!
:U
The first posted image is what my Win7/64 bit ultimate shows.
Great job. Nobody knows, except Alex, how he got this small size.
Frank
Quote from: jj2007 on October 25, 2010, 09:48:57 PM
Quote from: Antariy on October 25, 2010, 09:37:02 PM
I cannot believe - no one download the program! Peoples, this is NOT a virus!!!
Avira says it's a virus - but I trust you more than I trust Avira, of course :green2
Alex, you are a madman, but it works just fine!
:U
Thank you,
Jochen!
When I first time send program to Frank for testing, his mail served disallow him to download archive - server says what it found a virus :green2
Alex
P.S why I'm madman? :bg
Quote from: frktons on October 25, 2010, 09:51:14 PM
The first posted image is what my Win7/64 bit ultimate shows.
Great job. Nobody knows, except Alex, how he got this small size.
Well, just documentation of this program is harder than writing it :green2
Jokes apart - for documenting all things would be needed write text which will be bigger than program at 20 times, at least. With consideration of my English - this is not so simple thing to do.
Alex
Alex,
(http://www.masm32.com/board/index.php?action=dlattach;topic=15159.0;id=8290)
rock solid and well done :U. Do you plan to release the source?
Gunther
Quote from: Antariy on October 25, 2010, 09:52:14 PM
P.S why I'm madman? :bg
Only a madman can squeeze so much functionality in 1008 bytes :U
Quote from: Gunther on October 25, 2010, 10:37:43 PM
Alex,
(http://www.masm32.com/board/index.php?action=dlattach;topic=15159.0;id=8290)
rock solid and well done :U. Do you plan to release the source?
Sources is not available - they just does not exist :bg
This is handmade in hex editor.
Alex
Quote from: Gunther on October 25, 2010, 10:37:43 PM
(http://www.masm32.com/board/index.php?action=dlattach;topic=15159.0;id=8290)
rock solid and well done :U. Do you plan to release the source?
Old good WinXP - more than 75% of system resources serves to user, not to OS :green2
Alex
looks great here, Alex :U
(http://img820.imageshack.us/img820/3087/screenshotouz.jpg)
(XP Pro)
On Vista, the program does not exit properly (each instance of the process remains in task manager, and must be killed manually). Otherwise, nice work.
-r
Quote from: dedndave on October 25, 2010, 11:14:48 PM
looks great here, Alex :U
(http://img820.imageshack.us/img820/3087/screenshotouz.jpg)
(XP Pro)
Thank you,
Dave!
You have not only WinXP Pro, but WinXP Media Center Edition, as I see? :bg
Alex
yes - that's correct
for this, it is the same OS as XP Pro :P
i need to buy some memory - lol
Quote from: dedndave on October 25, 2010, 11:22:54 PM
i need to buy some memory - lol
WinXP work nice with almost all stuff at 96 megs of RAM.
With 64 megs it works well without many
not needed stuffs. With 48 megs it woooooooorrrrrrrkkkkkksssssss........ :P
You screenshot have a plus - it show what program differently shows units of size, and really change color of indicator :P
Alex
Quote from: redskull on October 25, 2010, 11:19:03 PM
On Vista, the program does not exit properly (each instance of the process remains in task manager, and must be killed manually). Otherwise, nice work.
Alan, does not you see title of thread?
It is: Re: MemInfoMicro :
The Return. And return to OS for exit... is not work. That is planned, "We made that bug planned" :green2
Jokes apart - there are no place for implementation of ExitProcess.
Nice Vista create other thread somewhere (I guess - at MessageBeep).
Alan, can you find and disable call to MessageBeep, and after this check app?
Most good solution (close your ears :green2) woud be silent crash of application - for termination. :bg
Alex
Without MessageBeep program can stand smaller :green2
On other hand, if use DEP-incompatible variant (which have size 984 bytes), we have much more space for ExitProcess + MessageBeep.
But that variant would not work with DEP enabled systems (because part of the code in a "bad place").
Alex
Quote from: redskullOn Vista, the program does not exit properly (each instance of the process remains in task manager, and must be killed manually).
I'm running Vista on my laptop and it exits properly. ??
I run Vista Home Premium, sp2, 32-bit. i'm going to try to do that fancy jpeg as zip attachment, but no promises.
-r
(http://www.masm32.com/board/index.php?action=dlattach;topic=15159.0;id=8294)
This is a snap of process manager, after starting and stopping a few. Please, no jokes about using eclipse (it's for school, i promise :bg 0
Quote from: GregL on October 26, 2010, 12:57:13 AM
I'm running Vista on my laptop and it exits properly. ??
There are strange matter, in any case. Many times ago, I stubled with thing - under Win2k program is not terminated after ShellExecute, if it is exited from main (and only one) thread by RET, not by ExitProcess. Under XP and 9x it works well.
There are the same strange thing. First my think was that some API (I thinked MessageBeep) create different thread, and it prevent app to close.
In any way, if switch using of MessageBeep to ExitProcess, I can get this program to work with small changements.
So, voting is opened: who argue for MessageBeep, and who for ExitProcess?
:bg
Alex
Quote from: redskull on October 26, 2010, 01:05:25 AM
I run Vista Home Premium, sp2, 32-bit. i'm going to try to do that fancy jpeg as zip attachment, but no promises.
Alan, TaskManager, and ProcessExplorer, can show threads count in working prog. Run the program, move it above screen and back, move mouse pointer to close button at title, wait before ToolTip was showed, but not close program! - and after this see count of threads please.
This is witch-doctors method, but this is based on some funny experience, really.
Alex
After that test, there are two threads running. After hitting 'okay', one thread exits, and the other sticks around in "Wait:UserRequest" mode. The stack for the remaining one is:
ntdll.dll!KiFastSystemCallRet
kernel32.dll!WaitForMultipleObjects+0x18
msiltcfg.dll!RestartMsi+0x327
kernel32.dll!BaseThreadInitThunk+0x12
ntdll.dll!RtlInitializeExceptionChain+0x63
ntdll.dll!RtlInitializeExceptionChain+0x36
Quote from: redskull on October 26, 2010, 01:28:41 AM
After that test, there are two threads running. After hitting 'okay', one thread exits, and the other sticks around in "Wait:UserRequest" mode.
Well, as I decide initially, there are created one thread more into some API.
Very nice thing. :green2
Wait:UserRequest almost always meant what some window is waits for input. Of course, there are hidden window which created by system for "a good purpose - just in case" :green2
Strage thing what member of the ball is MSI subsystem??? Initially I guess that this is would be sndPlaySound...
NOTE: program does not create any threads itself - it just runned in main thread, and exit from it by RET. Creation of other thread is not planned, more over, this *must* not be done.
I'm not use any APIs which is creates threads, but initially I guessed that MessageBeep under Vista do this.
So, how be with voting?
Alex
I would assume the second thread is started by the message dialog routine. After stepping through it, there is one thread present before and after the message beep, a second one starts up after calling MessageBoxIndirect, but *does not* terminate after the message box has been closed. It is that same thread that stays active after the program has 'ended'. My hypothesis is that the dialog box thread is not being ended properly.
Also, the symbol names are garbage, don't assume anything based on them :bg
-r
Quote from: redskull on October 26, 2010, 01:42:12 AM
I would assume the second thread is started by the message dialog routine. After stepping through it, there is one thread present before and after the message beep, a second one starts up after calling MessageBoxIndirect, but *does not* terminate after the message box has been closed. It is that same thread that stays active after the program has 'ended'. My hypothesis is that the dialog box thread is not being ended properly.
Also, the symbol names are garbage, don't assume anything based on them :bg
Well, I *do not create any dialogs* I just call to MessageBoxA. There is a bug or oversight in Vista code, probably. If MessageBox->... create new thread, it *must* terminate it, I decide. There is law of programming - if you create - you must destroy.
Alex
I'm only seeing one thread. I'm also running Vista Home Premium SP2 32-bit.
Processor is: Intel(R) Core(TM)2 Duo CPU T5750 @ 2.00GHz.
(http://www.masm32.com/board/index.php?action=dlattach;topic=15159.0;id=8305)
Quote from: GregL on October 26, 2010, 01:46:43 AM
I'm only seeing one thread.
This can be hard to find stuff - some of shell extensions can hook program. Any other program can hook my program - create thread with its own Window (for simple interconnection with "server") etc. Moreover - COM creates hidden window for objects which is not designed for multithreading.
In short words, if Windows *wants* to do something that we are don't wait - it don't say to us about this...
Probably I'll change call to MessageBeep to call to ExitProcess, wich appropriate changements at executable.
Thanks to all for tests and attention! Good day/evening/night!
Alex
It's tough without source, but here's what the debugger is showing:
0040119c ff5314 call dword ptr [ebx+14h] ds:0023:00401014={user32!MessageBeep (75dde42b)}
0040119f ff5318 call dword ptr [ebx+18h] ds:0023:00401018={user32!MessageBoxIndirectA (75e0d4d9)}
Both these "work", in that the first makes the computer beep and the second brings up the dialog (and creates the thread that never exits). I hope someone can corroborate my findings, or i'll think i'm going crazy.
-r
Quote from: redskull on October 26, 2010, 01:57:27 AM
It's tough without source, but here's what the debugger is showing:
0040119c ff5314 call dword ptr [ebx+14h] ds:0023:00401014={user32!MessageBeep (75dde42b)}
0040119f ff5318 call dword ptr [ebx+18h] ds:0023:00401018={user32!MessageBoxIndirectA (75e0d4d9)}
Both these "work", in that the first makes the computer beep and the second brings up the dialog (and creates the thread that never exits). I hope someone can corroborate my findings, or i'll think i'm going crazy.
Yes, first call is to MessageBeep, second to MessageBoxInderectA, really this is have no meaning under XP and above - call to MessageBox/Ex/Indirect go by one way - SoftModalMessageBox.
You are not crazy :bg, param for MessageBoxIndirect is passed before param to MessageBeep.
So, when you are trace, when program calls to MessageBeep and exited from it (i.e. - step over), but don't call yet to MessageBox, exists only one thread?
EDITED: sources does not exist, really.
Alex
redskull,
It's just something different in your system.
Alex,
I vote for ExitProcess instead of MessageBeep.
Interesting:
Dependancy Walker says - Error processing the module's imports table.
OllyDbg v1.0 says - Bad or unknown format of 32-bit executable file.
VC 2010 Express debugger loads it without error.
Quote from: GregL on October 26, 2010, 02:03:02 AM
redskull,
It's just something different in your system.
Alex,
I vote for ExitProcess instead of MessageBeep.
Interesting:
Dependancy Walker says - Error processing the module's imports table.
OllyDbg says - Bad or unknown format of 32-bit executable file.
VC 2010 Express debugger loads it without error.
Thanks for your vote,
Greg, I'm also inclined for that.
Dependancy Walker assume puritan's using of import table. :bg
OllyDbg 2.0 load it rightly, as I recall.
Alex
Greg, you can download OllyDbg 2.0 from here: "http://www.ollydbg.de/version2.html"
Alex
Alex,
Yes, I know, thanks. As far as I'm concerned OllyDbg v2.0 isn't done until it supports symbols, so I prefer v1.0 for now. Actually I don't use OllyDbg v1.0 much at all, I prefer the Visual C debugger and that's the one I use 99% of the time.
Hi,
Win 2000. Thanks Antariy for image posting.
Steve
(http://www.masm32.com/board/index.php?action=dlattach;topic=15159.0;id=8295)
Quote from: Antariy on October 25, 2010, 11:44:56 PM
It is: Re: MemInfoMicro : The Return. And return to OS for exit... is not work. That is planned, "We made that bug planned" :green2
On XP, a retn eventually calls invoke ExitProcess, 0 - has that changed with Vista?
include \masm32\include\masm32rt.inc
.code
start: retn
end start
7C816FD7 50 push eax
7C816FD8 E8 7B50FFFF call ExitThread
..
ExitThread 6A 14 push 14
...
7C80C0AD FF15 6C14807C call near [<&ntdll.NtTermi>; ntdll.ZwTerminateThread
7C80C0B3 FF75 08 push dword ptr [ebp+8]
7C80C0B6 E8 1F0D0100 call ExitProcess
To do the same thing in code :
GlobalMemoryStatus
just use \masm32\examples\exampl10\MemInfoMicro and follow:
http://msdn.microsoft.com/en-us/library/aa366586(VS.85).aspx
use LINK instead of polib with the /LARGEADDRESSAWARE option.
That all.
Here the compiled sample to verify if it work
Quote from: jj2007 on October 26, 2010, 09:45:01 AM
Quote from: Antariy on October 25, 2010, 11:44:56 PM
It is: Re: MemInfoMicro : The Return. And return to OS for exit... is not work. That is planned, "We made that bug planned" :green2
On XP, a retn eventually calls invoke ExitProcess, 0 - has that changed with Vista?
Jochen, the thing is not that. Central thing is: one from called APIs create different thread, when we out from main (first and only planned) thread by RET, then system just call ExitThread, not ExitProcess. So, if app contain not only main thread - other thread(s) will prevent it to terminate. On Vista of Alan MessageBox creates thread - and that is all.
Alex
Quote from: ToutEnMasm on October 26, 2010, 12:46:44 PM
To do the same thing in code :
GlobalMemoryStatus
just use \masm32\examples\exampl10\MemInfoMicro and follow:
http://msdn.microsoft.com/en-us/library/aa366586(VS.85).aspx
use LINK instead of polib with the /LARGEADDRESSAWARE option.
That all.
Thank you for pointing and using my old utility :bg Yes, that program is my - that is reasor for "The Return". :bg
But, that program have much less functionality - it does not support memory greater than 4 GB, it does not have shell icon, it does not have graphical indicator...
The new program (which is posted in first post of this thread) is new level of functionality of that app, your pointed app is grandfather of the new one :bg
Alex
News: I have update the program for using of ExitProcess. Also size is changed.
See updated attachent at the first post of this thread.
Alex
Alex,
you're - shortly spoken: молодец. :lol
Gunther
Quote from: FORTRANS on October 26, 2010, 06:14:11 AM
Win 2000. Thanks Antariy for image posting.
No, thank to you for testing,
Steve!
Alex
Greg, Vista which you are running on your laptop is 32bit or 64?
Alex
New version exits cleanly. Nice work. :thumbu
Alex,
It's 32-bit.
Thank you, Alan!
Thank you, Greg!
Alex
Well, due to sources is not exist, anybody have some questions, suggestions?
Which principles used is most interesting?
If nobody wants asks something, I'ld not bothered to write many text at my nice English :bg
Alex
Here is the modify sample of masm32 with sources.
He use GlobalMemoryStatusEx instead of GlobalMemoryStatus and wait your futur machines.
Here you go Alex. Windows 7 Professional 64-bit. Pentium D 940.
(http://www.masm32.com/board/index.php?action=dlattach;topic=15159.0;id=8312)
I would be interested in how you kept it so small.
Quote from: ToutEnMasm on October 27, 2010, 07:11:37 AM
Here is the modify sample of masm32 with sources.
He use GlobalMemoryStatusEx instead of GlobalMemoryStatus and wait your futur machines.
ToutEnMasm, your remake of my program still have functionality much less than new version of MemInfoMicro.
If system have big memory, for example 8.5 GB, old program would show "8704 MB" - it is hard to read and understand. In case of future machines with, for example, 128 GB of memory, reading of "131072 MB" is just awesome. Program must be useful - i.e. results must be readable in easy way; and program must be *usable* - i.e. - compatible. GlobalMemoryStatusEx is does not supported by Win9x.
The differences between my old (even with your changes) and NEW programs:
My new program
support memory of any size, without loss of compatibility with old Windows systemsMy new program
make results comfortable for reading independedly from size of memory.
My new program
watch units of memory sizes - again for unified algo and comfortability of reading of results.
My new program
have graphical indicator of free RAM - it is useful and have high sensitivity.
My new program
have shell icon.
My new program
works on ALL Windows, even on old Win9x.
My new program
have size 984 BYTEsI wonder why you still post my *old* (even remaked) programs to thread - this thread of *NEW* generation of that program, and this *NEW* generation is have much more functionality and still compatible with old Windows 9x. Also have look to size - this is most general thing which I point. The old program written to be small - too - I have send it to Hutch more than 2 years ago.
Alex
News: program was updated, new size 984 bytes (without loss of functionality of course!).
See for update an archive at first post of this thread.
Alex
Probably my English is so bad, that most of peoples is not understand it.
So, to make clear: MemInfoMicro which is included to MASM32 package is mine program! And this is very funny, that it is recalled after such big time :)
Alex
Alex.
Your English isn't that bad, I understand you just fine.
Quote from: GregL on October 27, 2010, 10:28:43 PM
Your English isn't that bad, I understand you just fine.
Really? Well, I'm glady if that :bg
Greg, I have updated program, too. It is at first post of thread.
Alex
Quote from: GregL on October 27, 2010, 05:51:20 PM
I would be interested in how you kept it so small.
Greg, which details you wants to know at first order?
Well, I assume from start of the file format.
File has only one section, which contains code, initialized data, uninitialized data, resources, imports.
All spare places within PE file was used to place code and/or data. Some parts of format-data structures was trimmed to have smaller size. At that place I put code and/or data, too.
Some *not spare* parts of structures was used at "non-puritan's" style, they just obsolette, or have no meaning. Some parts have meaning, but it have some range which is make them illegal, and Windows does not use them. Some parts is documented as used, but actually have not any meaning since Win95.
Each thing of format needed to be explained in details much more. Please, say me what needed in first order.
I guess, all peoples who tried this my prog, already see it under debugger, and understand how it works. If some questions exists, or suggestions for improvements of something - this is welcomed.
Alex
Quote from: GregL on October 27, 2010, 05:51:20 PM
Here you go Alex. Windows 7 Professional 64-bit. Pentium D 940.
I would be interested in how you kept it so small.
Thank you,
Greg!
Alex
Alex,
Thanks for the explanation. I have read some discussions on creating small PE files so I am aware of some of the techniques. I only worry about the size or the speed of a program if I have to, which is very rarely. You don't need to go into more detail for my sake, I would find it interesting if you did though. It is impressive the amount of functionality you fit into such a small size and that it still runs under all Windows versions.
Quote from: AlexI guess, all peoples who tried this my prog, already see it under debugger, and understand how it works.
I doubt it.
Quote
I wonder why you still post my *old* (even remaked) programs to thread
This allow useful comparisons between the versions,that all.
Quote from: ToutEnMasm on October 27, 2010, 07:11:37 AM
Here is the modify sample of masm32 with sources.
He use GlobalMemoryStatusEx instead of GlobalMemoryStatus and wait your futur machines.
ToutEnMasm,
On my machine which has a swapfile of 307,200 Mbs, your program is showing 820 Mbs.
Quote
On my machine which has a swapfile of 307,200 Mbs, your program is showing 820 Mbs
He can have a little difference with the value indicated by the systeme.(config panel -- systeme)
The Unit used by the systeme panel is in GiB (power of 2 more near of a GB )
Usually the disk capacity is given in GB instead of GiB (it is like that in my country).
But the difference couldn't be so big (*2)
Are you sure of your number ?.
pic
Magnum,
what do you get with Alex' new version?
Quote from: ToutEnMasm on October 27, 2010, 07:11:37 AM
Here is the modify sample of masm32 with sources.
He use GlobalMemoryStatusEx instead of GlobalMemoryStatus and wait your futur machines.
meminfo is giving 648 for swapfile.
The actual value of my pagefile.sys is 384 MB (402,653,184 bytes)
This is the value on a system with XP Pro Sp3.
Error also occurs on my XP home Edition.
Quote from: jj2007 on October 28, 2010, 04:36:35 PM
Magnum,
what do you get with Alex' new version?
This is big quiet, probably :bg
On Win9x, returned the really params of the *SWAP file* in the dwXXXPageFile. So, info returned by GlobalMemoryStatus is show really values of the things.
On WinNT, with no differency between GlobalMemoryStatus/Ex, returned the size of *available virtual memory*, not just size of swap file.
But this is not simpe sum of size of RAM + size of the swap file, this is sum with substraction of the some working size, which is differents from versions of system, moreover, it is dependent from total size of VM.
So, this is not a bug of any program - see results shown by *ANY* program which is used APIs to gets the sizes of memorys. They will show the same results.
This is just extension/changement in Windows NT - it show to program the real size of memory, which can be allocated in total, instead of showing simple size of the swap file.
Alex
Quote from: ToutEnMasm on October 28, 2010, 04:39:00 AM
Quote
I wonder why you still post my *old* (even remaked) programs to thread
This allow useful comparisons between the versions,that all.
I hope I will not looks harming, but they just incomparable.
Alex
Hi to all!
Due to some peopes was interested to know how program works, and due to some peoples does not understand main point of this thread :green2, I have written this text, which is explain work of program in general words - this is not require many text to be written, and this is gives easy opportunity to debug program, and understand which part do the explained things.
So.
Program, which is included to the examples of the MASM32 package, and located there: "\masm32\examples\exampl10\MemInfoMicro" just is simple example, written by me more than 2 years ago.
But that program inspire me to make the new one, which is something like the current program. But the history of that is too long, and current program is not similar to many previous versions, where I have implemented something new, in parallel with decreasing of size and testing across different Windows.
Anybody can see at this thread a remake of the my old MASM32 example, which in result:
Have the uncomfortable showing of results
Have not graphical indicator, which is useful enough
Have not contain an shell icon
Have size at 7168 bytes (7KB)
Uses one code path which is not compatible with Win9x, but appear in Windows 2000...
...And moreover - compiled executable is not runnable even under Windows 2000, due to required subsystem version in PE header is set to 5.1. This is subsystem version of Windows XP, and this is happened due to using default setting of LINK.EXE from MSVC v.10 package.
So, that is without comments... :green2
My work been much more harder, I guess.
So, in short.
Initially program has entry point which is been inside PE-header, because big part of code located at that place.
But on DEP-enabled systems that program not work - due to PE-header placed in first section of .EXE, which is not marked as executable.
The new one is use re-loader, or re-locator, which is copy pieces of the code from header to the end of the single section, which have read/write/execute attributes. So, old good DOS stuffs is still possible at Windows 7, and do a great job :bg
So, after start of program, it firtsly copy all code pieces to the not used place, after than it calls that code, which is already placed as monolithic stuff.
That code do preparations for right work of program on different Windows which is have different opportunities.
In short, that code searches for presence of GlobalMemoryStatusEx, which is present since Win2k, and uses QWORDs for results. If this functions is founded, then program change some variables, which is used further in the code, and have great meaning due to unification of the main algorightm - the *one* code path is works with DWORD or QWORDs.
Also some parts of the code is patched to have opcodes which is loads QWORDs, not DWORDs.
These things provide opportunity of using single unified algo which is works with totally different structures of the different APIs on Windows 9x and Windows 2000 +.
NOTE: under memory size/sizes I have understand any size with no difference between RAM or SWAP.
Main alorithm, which is parse sizes, based on FPU code, which is do conversion to the readable form of results, and to the integer values.
Anybody can see, what program does not use any RTL (like MSVCRT.DLL), so, I was needed in manual preparation of the results to showing them in compfortable fractional decimal format. The integer part of the each size is the one DWORD, passed onto stack, the fractional part is the other DWORD which is passed onto stack.
The memory size units, which is needed for comfortability reading of the fractional results, and further compatibility with greather memory, is changed at the parsing loop, for *each* reported size. So, for example, if your system have 2 GB of memory, but only 1023 MBs is free, then program show this at comfortable manner- "2 GB" and "1023 MB".
So, my current program would not confuse the user with incredible big or strange fractional values - it just change the unit of the memory size, and will show result in more readable form. The more is memory size - not bigger awesome number will be shown, but bigger stand the unit (currently supported units to the ExaBytes - i.e. greatest unit for 64bit integer). The less is memory size - the smaller is unit.
Further, the calculation of the color for indicator is made by code, which is calculates the green and red values of the bitmap channels. After that I have replace the corresponding pixels of the main (and single) icon of the executable.
Probably, anybody was wondered, how I put such high-gradient, up to 48x48 sized TrueColor icon to that file? The 48x48x24 icon will have size ~7 KB itself, but program with icon and all other things have size 7 times smaller? :bg
Maybe this is would be an discovery, maybe - not. This is big discuss itself. So, I have just point to this fact - program have no bad icon.
I hope, after explaining, the program would not appear as something uninteresting thing.
One note: if remove resources (a shell icon) and graphical indicator, then program will have size less than 800 bytes, with the same compatibility and algorithm of showing results. So, resources and icon still the one from the biggest things in the program's file.
And, of course, program's file have no place which is not used for placing of code and/or data. This is parts of control structures of the header, spare places, and places which is trimmed to be compactly. Used some parts of the resources structures also, moreover, the icon contain some parts of imports :bg
Alex
Alex,
so we know what you've done. You are a really code Волшебник (kind of magician like Merlin). Thank you.
Gunther
Quote from: ToutEnMasm on October 27, 2010, 07:11:37 AM
Here is the modify sample of masm32 with sources.
He use GlobalMemoryStatusEx instead of GlobalMemoryStatus and wait your futur machines.
Sorry but...
This is the version I used and the total swapfile results are wrong for both XP Pro and XP Home Edition.
I will be glad to help with any info you need to fix it.
Interesting Alex, thanks.
Anybody have a Windows 95, installed on real or virtual machine? Just curious about test on such great OS :bg
Alex
Running under Windows 95 OSR2.1:
I forgot to add that the color is off because the monitor on that system has no red output.
Quote from: MichaelW on October 30, 2010, 09:54:40 PM
Running under Windows 95 OSR2.1:
Thank you very much,
Michael !
Very nicely looks!
Windows 95 not use swap file at all, with 256 MBs of RAM.
So, now is proved that even Win95 can run MemInfoMicro! :bg
Alex
Quote from: MichaelW on October 30, 2010, 09:54:40 PM
I forgot to add that the color is off because the monitor on that system has no red output.
Your archive, which I downloaded at first time, contains the colored image. ???
Alex
Quote from: MichaelW on October 30, 2010, 09:54:40 PM
I forgot to add that the color is off because the display on that system has no red output.
Michael, probably, if I understand right, you meant that the icon does not have red channel?
If that - this is not because hardware things, this is because program change color of the indicator automatically - the more free RAM is available - the much green the indicator; the less memory is available - the more is orange an indicator. This is part of the program. Your Win95 system has very many free RAM - the indicator is bright-green. The color changements of indicator have high sensitivity, dependedly from RAM loading.
Alex
QuoteYour archive, which I downloaded at first time, contains the colored image. ???
Yes, it does. I'm half asleep again, thinking that I was capturing what was actually displayed, instead of what Windows was trying to display.
Quote from: MichaelW on October 30, 2010, 10:25:50 PM
QuoteYour archive, which I downloaded at first time, contains the colored image. ???
Yes, it does. I'm half asleep again, thinking that I was capturing what was actually displayed, instead of what Windows was trying to display.
Yes, indicator is green because many free RAM is available. So, all things in program works as planned even on Win95 :bg
Thank you!
Alex
Quote from: Alex... the more free RAM is available - the much green the indicator; the less memory is available - the more is orange an indicator.
Do you use the
MEMORYSTATUSEX.dwMemoryLoad value for this calculation?
Quote from: GregL on October 30, 2010, 10:36:30 PM
Quote from: Alex... the more free RAM is available - the much green the indicator; the less memory is available - the more is orange an indicator.
Do you use the MEMORYSTATUSEX.dwMemoryLoad value for this calculation?
No. Current program's algo have 128 levels of the sensitivity, not 100 as in dwMemoryLoad. I use unified loading of size of free memory and total memory size. After that calculated the green channel. Red channel is inversion of the green channel.
Alex
Quote from: GregL on October 30, 2010, 10:36:30 PM
Do you use the MEMORYSTATUSEX.dwMemoryLoad value for this calculation?
Probably you found the new way to decrease the program's size for about ~10 bytes, at least. :bg
But current algo is maded intentionally - must I do something different from Windows?! :bg
Alex
Anybody have a Windows Vista x64? To test the program on it.
Alex
Quote from: GregL on October 30, 2010, 10:36:30 PM
Quote from: Alex... the more free RAM is available - the much green the indicator; the less memory is available - the more is orange an indicator.
Do you use the MEMORYSTATUSEX.dwMemoryLoad value for this calculation?
Why I have suggested to see the program under debugger - is fact that you see its algo in work.
You will see, that program use one code path to work with absolutely different structures of two APIs - GlobalMemoryStatus and GlobalMemoryStatusEx.
All needed offsets of members in that structures is different, so code is needed to be universal - it *must* work with different structures, and it *do* that. One part of this - is patching the code, other part of this - is using of unified code, which depends from variables. That variables is setted dependedly from current system capabilityes.
EDITED: Patching change the datasize of FPU loadings only. The variables provide selection of members from different structures.
Alex
Alex,
here is the Wine image:
(http://www.masm32.com/board/index.php?action=dlattach;topic=15458.0;id=8541)
At your service, every day, Alex.
Gunther
Quote from: Gunther on November 28, 2010, 10:12:22 PM
Alex,
here is the Wine image:
(http://www.masm32.com/board/index.php?action=dlattach;topic=15458.0;id=8541)
Thank you very much! :U
Alex
Quote from: Antariy, November 28, 2010, at 10:21:56 PMThank you very much!
You're welcome, Alex.
Gunther
New update of MemInfoMicro is available. The program is 976 bytes long now (8 bytes less).
See the first post of the thread for an updated archive.
Alex
It still says that half of my one Gig of RAM is completely wasted. This Forum is just no good for the hardware market.
Quote from: jj2007 on December 12, 2010, 11:22:34 PM
It still says that half of my one Gig of RAM is completely wasted. This Forum is just no good for the hardware market.
You meant that that Windows eats too much?
i am like Jochen - lol
i need to buy some more RAM for this machine :P
it has (4) 256 Mb PC-3200 400 MHz DDR SIP's
i need to see what it takes to upgrade
it should be on my christmas list :bg
I mean that half of my RAM is unused because we all run NoBloatWare here. Of course, WinXP is pretty bloated itself... ;-)
Quote from: jj2007 on December 13, 2010, 12:02:54 AM
I mean that half of my RAM is unused because we all run NoBloatWare here. Of course, WinXP is pretty bloated itself... ;-)
Of course, MemInfoMicro require only 8 KB of memory to image mapping. Other things is Windows data and code :bg
Program was updated. 968 bytes for now.
looks good here, Alex :U
XP MCE2005 SP3
(http://img851.imageshack.us/img851/4287/mim32.png)
we have missed you :P
Hello Alex, good to hear from you. :U
Hi Alex,
January 7 update works fine on Win XP SP3 - of course :U
The main post of the thread was updated: the new archive "MemInfoMicro25.zip" was attached - with the source-code program tweak, the text of main post is updated as well.
Also, is there anyone who can test original MemInfoMicro.exe (from MemInfoMicro.zip) on the Windows 8, please?
Quote from: jj2007 on January 07, 2012, 11:20:18 PM
Hi Alex,
January 7 update works fine on Win XP SP3 - of course :U
Thank you,
Jochen! :bg
Both work on win8 no problems.
Quote from: sinsi on January 08, 2012, 12:10:44 AM
Both work on win8 no problems.
Thank you very much,
Sinsi!