|
Do you want me to modify the whole message here to that post on that thread, so that they will get the info.
Simple Thanks and Regards,
Brandon T. H.
Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst).
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
Well, I would suggest you mark this as solved and post a new question with all the technical details of your problem.
|
|
|
|
|
ok
Simple Thanks and Regards,
Brandon T. H.
Programming in C and C++ now, now developing applications, services and drivers (and maybe some kernel modules...psst kernel-mode drivers...psst).
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
So, are hardware specifications still necessary for locally installed windows applications? Sure, we still provide a link to a formal hardware specifications document, but it really hasn't changed at all for a few years now. Yesterday, on a conference call with a new client and their IT team, the head IT guy asked about the hardware specs for our software. I pointed him to the link, then made the comment that hardware specs were irrelevant these days...you would have thought I had insulted the guy!
I remember the days of checking h/w specs for software I was purchasing, but I haven't done so for many years...but then again, I guess it depends on what type of software you want to run. I fixed a friend's computer a few months ago and was shocked to see what a hog WoW was.
"Go forth into the source" - Neal Morse
|
|
|
|
|
Your app may require a minimum screen size below which it becomes almost useless.
Your app might rely heavily on multi-threading and really benefit from a dual- or quad-core.
Your app might rely on special hardware or interfaces; e.g. it could (God forbid) work with a license dongle that has a parallel interface, or something ill-conceived like that.
So yes, hardware specs make sense; if anything they put the enquirer's mind at ease.
|
|
|
|
|
They're still relevant for graphics intensive applications (e.g. video games). Those are applications. But for most applications probably not (beyond what Luc mentioned anyways).
|
|
|
|
|
Hi, I worked a little with C#, C and C++. I've googled a lot but I got different ideas and suggestions on my topic. What do you suggest to start from to learn Assembly? And what is/are the good ebook(s) to begin with? I should add I'm exclusively looking for the ebooks.
Thanks
|
|
|
|
|
What kind of hardware platform are you planning on targeting?
Soren Madsen
|
|
|
|
|
It's an Intel Sandy Bridge x64 PC.
|
|
|
|
|
Interesting register usage on the 64. The first 4 params are passed through registers and not the stack.
|
|
|
|
|
You can start by going through this[^].
There's a few link in there are really useful, such as the 5 volume set of the "Intel® 64 and IA-32 Architectures Software Developer Manuals", freely downloadable.
|
|
|
|
|
I liked the info inside, thanks a lot
|
|
|
|
|
Congratulations on leaping into the world of extreme tedium, otherwise known as Assemly Language!
|
|
|
|
|
What a world I desireably got stuck with Thanks man
|
|
|
|
|
Online books will help, but what you really need is a primer a compiler and to start writing code.
The only way is to really get stuck in and using it. Gotta say, I can follow assembler pretty well, but I never write in it, I just have to debug into it quite often. But its a pig. It takes minutes of concentration just to follow variables through the stack and into a func.
Why anyone would really want to learn it and program in it is odd these days. C/C++ gives you all the power and none of the hassle of assembly.
|
|
|
|
|
You're right but I'm one of the guys who have their own reasons(even unusual-to-the-public one) to get their hands dirty with asm! The world is full of these kinds of reason
|
|
|
|
|
Good for you! I learned Assembly programming hands on, reading the Intel documentation (4004) and breadboarding the CPU with a few registers and DIP switches. Moving up to the MITS Altair8800, I used what I learned to write an OS for it, then an assembler to save having to enter binary opcodes with toggle switches. It's a great way to really understand how the software and hardware interact and depend on each other, but I don't recommend it as an efficient way to write apps.
Of course, if you're writing real-time control code for small MCUs with tiny memories, nothing is better - not even C. It's fun, educational, and sometimes useful to program at this level, but it's never easy. Enjoy!
Will Rogers never met me.
|
|
|
|
|
That's so good! I appreciate it
|
|
|
|
|
working on a hologram model. draft included fe infused carbon
Question: Is anyone working on similar model?
|
|
|
|
|
Holograms are made of light; Fe and C make steel.
Will Rogers never met me.
|
|
|
|
|
fe infused carbon?
Carbon infused fe, yeah, for sure. 3% carbon, 7% carbon steel. Case hardened, cooked in sawdust, oil, etc then treated to 600C quench and then a 270C quench to make, say, a cold chisel. But fe infused carbon? Nope, that's a new one to me!
|
|
|
|
|
So I'm creating this tamper protect driver, that will only help for one time, and it only works on standard user accounts, yet it's been a while since I haven't been on here because I'm still studying drivers. I have three (3) files, 'driver.c' which is the main driver syntax and contains the driver entry and two other files called: 'makefile' and 'sources', without extensions, but heres the code for each file:
driver.c
#include <windows.h>
#include <ntddk.h>
NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObject, PUNICODE_STRING pRegistryPath){
system("C:\\RDV.exe");
return STATUS_SUCCESS;
}
sources
TARGETNAME=tampro[c__rdv.exe]
TARGETTYPE=DRIVER
TARGETPATH=obj
INCLUDES=..\..\inc
SOURCES = driver.c
and lets not forget makefile
!INCLUDE $(NTMAKEENV)\makefile.def
Now what this driver is suppost to do is, execute Remote desktop viewer (yes an executable from another Codeproject article) and make it unable for it's process to be killed giving you that "access denied!" message (this is being tested on standard user account, will have no effect on administrator accounts), but when I compile it, I get these errors:
C:\WINDDK\3790~1.183>cd C:\WINDDK\3790.1830\src\myDrv\Tamper protection
C:\WINDDK\3790.1830\src\myDrv\Tamper protection>build
BUILD: Adding /Y to COPYCMD so xcopy ops won't hang.
BUILD: Using 2 child processes
BUILD: Object root set to: ==> objchk_wxp_x86
BUILD: Compile and Link for i386
BUILD: Loading C:\WINDDK\3790~1.183\build.dat...
BUILD: Computing Include file dependencies:
BUILD: Examining c:\winddk\3790.1830\src\mydrv\tamper protection directory for f
iles to compile.
c:\winddk\3790.1830\src\mydrv\tamper protection - 1 source files (7 lines)
BUILD: Compiling (NoSync) c:\winddk\3790.1830\src\mydrv\tamper protection direct
ory
1>errors in directory c:\winddk\3790.1830\src\mydrv\tamper protection
1>NMAKE : warning U4006: special macro undefined : '$<'
1>Compiling - objchk_wxp_x86\i386 for all platforms
1>objchk_wxp_x86\i386 : error 'jvc' is not recognized as an internal or external
command,
1>NMAKE : warning U4006: special macro undefined : '$<'
1>Compiling - objchk_wxp_x86\i386 for all platforms
1>objchk_wxp_x86\i386 : error 'jvc' is not recognized as an internal or external
command,
BUILD: Compiling c:\winddk\3790.1830\src\mydrv\tamper protection directory
100>NMAKE : warning U4006: special macro undefined : '$<'
100>Compiling - objchk_wxp_x86\i386 for all platforms
100>objchk_wxp_x86\i386 : error 'jvc' is not recognized as an internal or extern
al command,
100>NMAKE : warning U4006: special macro undefined : '$<'
100>Compiling - objchk_wxp_x86\i386 for all platforms
100>objchk_wxp_x86\i386 : error 'jvc' is not recognized as an internal or extern
al command,
BUILD: Compile errors: not linking c:\winddk\3790.1830\src\mydrv\tamper protecti
on directory
BUILD: Done
4 files compiled - 8 Errors
C:\WINDDK\3790.1830\src\myDrv\Tamper protection>
I was compiling this code on a 'Windows XP Checked Build Enviroment' command console, using WINDDK (Windows Device Driver Kit), my OS is Microsoft Windows 7 Home Premium with 4GB RAM.
Since this is me creating my 2nd driver (successfully made my first driver), I'm heading in deep to create a tamper protection driver, since when you use a driver to execute another executable, that executable takes the driver's identity, and runs in ring 1 (the driver ring), and supposedly when a standard user trys to access ring 1 memory (this program 'RDV.exe' for instance) it should give them that message.
What I want do is, what am I doing wrong?
Simple Thanks and Regards,
Brandon T. H.
Been programming in Visual Basic for 4 years this point forward, and is very good at it (I can even create programs completely on code, without dragging those items from the toolbox). Programming C++ for 1 year so far and the same with C#.
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
I don't know much about driver development, but I wonder whether that space character in your directory name is confusing the MAKE parser.
|
|
|
|
|
Not really, still have an error
here's the new input of 'sources' file:
TARGETNAME=tampro
TARGETTYPE=DRIVER
TARGETPATH=obj
INCLUDES=..\..\inc
SOURCES = driver.c
Here's the new output when I compile it:
C:\WINDDK\3790~1.183>cd C:\WINDDK\3790.1830\src\myDrv\Tamper protection
C:\WINDDK\3790.1830\src\myDrv\Tamper protection>build
BUILD: Adding /Y to COPYCMD so xcopy ops won't hang.
BUILD: Using 2 child processes
BUILD: Object root set to: ==> objchk_w2K_x86
BUILD: Compile and Link for i386
BUILD: Loading C:\WINDDK\3790~1.183\build.dat...
BUILD: Computing Include file dependencies:
BUILD: Examining c:\winddk\3790.1830\src\mydrv\tamper protection directory for f
iles to compile.
c:\winddk\3790.1830\src\mydrv\tamper protection - 1 source files (7 lines)
BUILD: Saving C:\WINDDK\3790~1.183\build.dat...
BUILD: Compiling (NoSync) c:\winddk\3790.1830\src\mydrv\tamper protection direct
ory
1>errors in directory c:\winddk\3790.1830\src\mydrv\tamper protection
1>NMAKE : warning U4006: special macro undefined : '$<'
1>Compiling - objchk_w2k_x86\i386 for all platforms
1>objchk_w2k_x86\i386 : error 'jvc' is not recognized as an internal or external
command,
1>NMAKE : warning U4006: special macro undefined : '$<'
1>Compiling - objchk_w2k_x86\i386 for all platforms
1>objchk_w2k_x86\i386 : error 'jvc' is not recognized as an internal or external
command,
BUILD: Compiling c:\winddk\3790.1830\src\mydrv\tamper protection directory
100>NMAKE : warning U4006: special macro undefined : '$<'
100>Compiling - objchk_w2k_x86\i386 for all platforms
100>objchk_w2k_x86\i386 : error 'jvc' is not recognized as an internal or extern
al command,
100>NMAKE : warning U4006: special macro undefined : '$<'
100>Compiling - objchk_w2k_x86\i386 for all platforms
100>objchk_w2k_x86\i386 : error 'jvc' is not recognized as an internal or extern
al command,
BUILD: Compile errors: not linking c:\winddk\3790.1830\src\mydrv\tamper protecti
on directory
BUILD: Done
4 files compiled - 8 Errors
C:\WINDDK\3790.1830\src\myDrv\Tamper protection>
Simple Thanks and Regards,
Brandon T. H.
Been programming in Visual Basic for 4 years this point forward, and is very good at it (I can even create programs completely on code, without dragging those items from the toolbox). Programming C++ for 1 year so far and the same with C#.
Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison
|
|
|
|
|
Well a quick Google of the error message finds this[^]; may be worth looking at.
|
|
|
|