Goal is to devlelope a Window Diagnostic memory test program
1)I choose VC++ for window because it support 64-bit data. ulong long type. whereas regualr C or C++ compiler only support 16/32 bit
2)However, using VC++ mean in user mode I can’t write low level function like to turn on/off CPU cache.
I need to write those in assembly language.
3)Somewhat I need to have a .sys device driver file so I would access the kernel mode.
But does WINDDK support assembly language? Can it access the CPU register in its code??
4)Use Malloc to get free memory to test. But when a failure occur the system does not give me its physical address of the memory failure.
It might sounds confusing. Anyone have an idea how to approach this.
xxxxx@yahoo.com wrote:
Goal is to devlelope a Window Diagnostic memory test program
Put simply, this is NOT a good idea. A good-sized fraction of physical
memory is occupied by the operating system and its resident tables. You
can’t move that, which means you can’t test that memory. Because of
paging, a single piece of data can move from one physical address to
another at any time, making it impossible for you to locate the physical
address of a failure. Further, because of the multitasking nature of
Windows, other threads might run at any time, trashing the cache.
And finally, many (most?) memory failures are going to prevent Windows
from coming up at all. By the time Windows is ready to run
applications, it has already exercised a lot of the physical memory.
You need an environment that comes up quickly, without so much impact.
1)I choose VC++ for window because it support 64-bit data. ulong long type. whereas regualr C or C++ compiler only support 16/32 bit
I don’t know what a “regular C or C++ compiler” might be. Every Win32
compiler supports a 64-bit data type.
It might sounds confusing. Anyone have an idea how to approach this.
Yes. Abandon the idea, and write a memory test that runs WITHOUT
Windows. There are several good free DOS-like operating systems now,
where you can control virtually all of physical memory yourself.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
There is no kernel malloc. I assume that you are using malloc up in user
mode. You could have your driver lock down the memory allocated and produce
a virtual->physical translation for you. From your post I am not convinced
that you should not first get a good book on windows os internals first, and
then rethink this whole project.
=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Friday, August 25, 2006 2:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Newbie question on developing a Window based
64 bit memory diagnostic
Goal is to devlelope a Window Diagnostic memory test program
1)I choose VC++ for window because it support 64-bit data.
ulong long type. whereas regualr C or C++ compiler only
support 16/32 bit
2)However, using VC++ mean in user mode I can’t write low
level function like to turn on/off CPU cache.
I need to write those in assembly language.
3)Somewhat I need to have a .sys device driver file so I
would access the kernel mode.
But does WINDDK support assembly language? Can it access the
CPU register in its code??
4)Use Malloc to get free memory to test. But when a failure
occur the system does not give me its physical address of the
memory failure.
It might sounds confusing. Anyone have an idea how to approach this.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer
> 1)I choose VC++ for window because it support 64-bit data. ulong long type.
whereas regualr C or C++ compiler only support 16/32 bit
DDK’s compiler supports ULONGLONG for years.
But does WINDDK support assembly language? Can it access the CPU
register in its code??
On 32bit - yes. Be careful not to disturb the other CPU operations.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Put simply, this is NOT a good idea.
Abandon the idea, and write a memory test that runs WITHOUT
Windows. There are several good free DOS-like operating systems now,
where you can control virtually all of physical memory yourself.
sys_eng00, you may want to look at http://www.memtest86.com/
or http://www.memtest.org/ as starting points.
----- Original Message -----
From: “Tim Roberts”
To: “Windows System Software Devs Interest List”
Sent: Friday, August 25, 2006 3:45 PM
Subject: Re: [ntdev] Newbie question on developing a Window based 64 bit
memory diagnostic
> xxxxx@yahoo.com wrote:
>
>>Goal is to devlelope a Window Diagnostic memory test program
>>
>>
>
> Put simply, this is NOT a good idea. A good-sized fraction of physical
> memory is occupied by the operating system and its resident tables. You
> can’t move that, which means you can’t test that memory. Because of
> paging, a single piece of data can move from one physical address to
> another at any time, making it impossible for you to locate the physical
> address of a failure. Further, because of the multitasking nature of
> Windows, other threads might run at any time, trashing the cache.
>
> And finally, many (most?) memory failures are going to prevent Windows
> from coming up at all. By the time Windows is ready to run
> applications, it has already exercised a lot of the physical memory.
> You need an environment that comes up quickly, without so much impact.
>
>>1)I choose VC++ for window because it support 64-bit data. ulong long
>>type. whereas regualr C or C++ compiler only support 16/32 bit
>>
>>
>
> I don’t know what a “regular C or C++ compiler” might be. Every Win32
> compiler supports a 64-bit data type.
>
>>It might sounds confusing. Anyone have an idea how to approach this.
>>
>>
>
> Yes. Abandon the idea, and write a memory test that runs WITHOUT
> Windows. There are several good free DOS-like operating systems now,
> where you can control virtually all of physical memory yourself.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
Thank for all the inputs.
If I choose to build a DOS program(access protected mode) using Win32 compiler(for 64 bit purpose) then what type of project I should choose
1)Win32 apps
2)Win32 console
3)Win32 Static lib
4)utility project
I don’tsee a DOS program option in VC++
I have tried Memtest86, I modified the code but it’s very difficult to make it work after modification.
I compile OK under GCC linux but generate alot of linking issue relate PIC code and relocation which I don’t know how to fix.
The Win32 compiler targets the Win32 environment, not DOS or any other environment. You’ll have to do your homework on whatever environment you choose.
– arlie
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Friday, August 25, 2006 2:06 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Newbie question on developing a Window based 64 bit memory diagnostic
Thank for all the inputs.
If I choose to build a DOS program(access protected mode) using Win32 compiler(for 64 bit purpose) then what type of project I should choose
1)Win32 apps
2)Win32 console
3)Win32 Static lib
4)utility project
I don’tsee a DOS program option in VC++
I have tried Memtest86, I modified the code but it’s very difficult to make it work after modification.
I compile OK under GCC linux but generate alot of linking issue relate PIC code and relocation which I don’t know how to fix.
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Hi Arlie,
That’s my dilemma of having 64 bit data access capability yet fully accessible to all the internal hardware.
I not sure which compiler can offer me that, maybe GCC but it’s very hard to compile and link.
You need some DOS Extender for this. I don’t think MS provides one. DJGPP
is fine and is open-source, and includes the gcc compiler port.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Saturday, August 26, 2006 1:05 AM
Subject: RE:[ntdev] Newbie question on developing a Window based 64 bit memory
diagnostic
> Thank for all the inputs.
> If I choose to build a DOS program(access protected mode) using Win32
compiler(for 64 bit purpose) then what type of project I should choose
> 1)Win32 apps
> 2)Win32 console
> 3)Win32 Static lib
> 4)utility project
>
> I don’tsee a DOS program option in VC++
>
> I have tried Memtest86, I modified the code but it’s very difficult to make
it work after modification.
> I compile OK under GCC linux but generate alot of linking issue relate PIC
code and relocation which I don’t know how to fix.
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
“Tim Roberts” wrote in message news:xxxxx@ntdev…
> xxxxx@yahoo.com wrote:
>
>>Goal is to devlelope a Window Diagnostic memory test program
>
> Put simply, this is NOT a good idea. A good-sized fraction of physical
> memory is occupied by the operating system and its resident tables. You
> can’t move that, which means you can’t test that memory.
Not only this. The memory tests, like memtest86 or the MS one,
tinker a lot with the cache control registers and other esoteric chipset features.
You can not do this under Windows.
If your goal is to test a hot-pluggable memory bank while it is “offline”, please state so.
–PA