Reading the 4 points will teach you almost nothing about system architecture. You need to go further in depth before you are capable of understanding this thread.Ok googlee for that guy and read about his 4 points
Reading the 4 points will teach you almost nothing about system architecture. You need to go further in depth before you are capable of understanding this thread.Ok googlee for that guy and read about his 4 points
because our axioms that support our theorems are beyond you capability currently. I already hinted at one standard way of working on certain I/O devices.I might not be capable of undersanding this thread, but you also seem to be incapable of supporting your statements.
there used to be something here, but not anymore
Just about any time you do something low-level, it will be system specific. Generality is a luxury of high-level abstraction. So, while the concrete applications of C/C++'s low-level functionality are system specific, the mechanisms (memory manipulation, mainly) that allow the low-level functionality are standard.
as I said, Memory-Mapped IO tends to be a standard way of mapping IO devices in modern systems(atleast it used to be), just one of the reasons the assembler in and out mneumonics exist.you can't do anything that low level and the thing the guys said you can
there used to be something here, but not anymore
Can't do anything low level in C????
Wrong.
You can do anything you want in C within restrictions of the OS....and for that you would use asm....but either way you should be able to accomplish the same task in both languages.
For instance all the gurus here say that interrupts are not possible in XP right? Wrong. Look at command.com and run some of your old DOS apps or your code on it. All the interrupts work fine. How is this?? Well write some code that crashes inside of command.com and watch what XP spits out.
Command.com (DOS 16-bit environment) has performed an.....blah blah blah.
Since you cannot perform interrupts in protected mode...well you can but I won't go into the IDT here, then command.com is executing your old DOS programs in virtual 8086 mode. The only way to get into virtual 8086 mode is to set the correct bit(s) in the CR0 register. XP won't let you set this.....or will it? Obviously there are ways to gain a higher privilege level in XP because command.com does it, and command.com is nothing more than another separate program written by Microsoft...it's not really part of the OS per se. So in theory I could write interrupt handlers and low level hard drive routines in C that would work under XP - given that you dismounted the volume....another convenient call inside of the XP API. This would be pretty low level and it can all be done in C. And if you don't want to use ARPL to set your privilege level then emit the correct opcode into the code stream via C.
You can do a lot of low-level stuff in C....in fact C is very very very good for low level functions.
So since command.com pops into virtual 8086 mode to execute your DOS apps, it would be possible to have your code do this as well and then call your C low-level interface functions.
With C you can program the DMA controller (was important for old school sound drivers/engines), SVGA hardware, monitor refresh rates, perform low-level IO (out* and in* family of C functions) - useful for directly programming VGA registers, floppy drive control, external device control, etc.
There are about a million things you can do and it all even works under XP contrary to what some may think. I've gotten away with murder in command.com - basically stuff that I thought Windows XP would puke on....executes flawlessly.
I'm sure you prob didn't understand much of this...but trust me you can do some pretty crazy stuff at the hardware level using pure C. All that DLL stuff you see in Windows is probably loaded into memory via C code. Probably most, if not all, of XP is written in C.
And what do you think Direct3D and OpenGL do? They access the hardware at the lowest level and many of the drivers are written in C via the DDK from MS. Most OS's, including MS's are written in C - they have a pure assembly bootstrap (since this cannot be done in pure C) that loads a pure C or C/C++ kernel and then jumps to it.
So about the only low level thing you cannot do in C that I can think of is write an OS bootstrap. That pretty much has to be in pure assembly.
Last edited by VirtualAce; 07-21-2004 at 04:58 PM.
OK, lets make it simple. I can manipulate random bits in memory by using standard C pointers. I cannot do this in C# ( or only with more coding/workarounds/third party libraries ).
Therefore, C is more low level than C#.
hth
-nv
She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."
When in doubt, read the FAQ.
Then ask a smart question.
Originally Posted by C+++C_foreverIn C you can set any bit in Memory you would like. Including those interfacing with the hardware like the video buffer. You cannot do this in C# ( or other higher level languages ) with such ease.Originally Posted by ober
Therefore standard C is a low level language.
If this does not answer your question, please try to rephrase it.
hth
-nv
She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."
When in doubt, read the FAQ.
Then ask a smart question.
As I understand it, those old dos programs do not run in virtual 8086...they run in a dos emulation layer (which is why lots of DOS programs wont work on NT based systems). This emulation will allow you to do a lot of things that you could do under dos - or at least simulate the ability to call interupts etc - but it's not the same as the free reign you get under virtual mode. This is why lots of old dos programs fail under windows NTOriginally Posted by Bubba
If you want complete control you need to write a driver and ask windows to load it - then you pretty much get all access. Oh...and most drivers are written in C by the way. Most real low level access that they may need is provided by a HAL that is created by microsoft for whatever processor is running - And C can call the facilities that the HAL exposes
Writing directly to the video buffer was something that could be accomplished using 5 lines of standard C without any APIs.Any interaction with the world, other than through the console and files, is not a part of standard C.
The resulting program wasn't portable, but that's another point. C is low level because it's perfectly possible to perform low level operations.
hth
-nv
She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."
When in doubt, read the FAQ.
Then ask a smart question.
If I recall correctly, in DOS Graphics mode 13 the video buffer resided at 0xA000.
So setting a pointer to this memory location, you could write to the video buffer.
Example:
unsigned char* pVideoBuffer = 0xA000;
int x;
int y;
x = 10;
y = 10;
pVideoBuffer[ (y*320)+x ] = 0;
This would put a black pixel to 10/10 of a DOS mode 13h 320*200 Monitor in pure standard C.
( You might not have a DOS Operating System installed to try this, and it will not work on windows. Also, you have to put your DOS into 13h mode which I forgot how to do, but googling should yield some results. )
hth
-nv
She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."
When in doubt, read the FAQ.
Then ask a smart question.
Originally Posted by nvoigt
You can also check out some of the old stuff here at CProg - http://www.cprogramming.com/advtutorial.html
No. It will write to a part of memory that is mapped to the video buffer ( DOS only ) and therefore set the color of a pixel directly.
hth
-nv
She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."
When in doubt, read the FAQ.
Then ask a smart question.
It's all along the same lines, with pointers allowing you to write directly to memory. If you've ever read about a PCs boot process, you'll know all about how different programs required for startup are written to certain locations in memory. And drivers do this as well. The program above wouldn't work in Windows because all the formats, etc... are different, but basically the same thing. If you need a control that's not standard in windows (like more than just a button or a drop-down menu) you'll have to do stuff like this to code it from scratch.
oh, you can, but you have to enter DOS 13h graphics mode, which is pretty easy:Windows don't allow you to do anything like that ( don't know about Linux ) so in windows you are helpless with the standard
then you can get a pointer to 0XA000 and go to town so to speak.Code:__asm { mov ah,13h int 0x10 }
well, windows itself (with just the basic functions) wont let you do it, however, you can program through the HAL like if you were programming a driver., or you can use "wrap around" techniques to somewhat avoid Windows.and Windows don't allow you to do anything like that ( don't know about Linux ) so in windows you are helpless with the standard
there used to be something here, but not anymore
actually a more safe version of the code:
16-bit DOS version
That code is safer because if you specify an offset from screen >64000 then it will wrap around since it is a BYTE pointer.Code:typedef unsigned char BYTE; #define XYTOMEM(x,y) (unsigned int)((y<<6)+(y<<8)+x) BYTE far *Screen=(BYTE far *)MK_FP(0xA000,0); //Plot white pixel at 160,100 Screen[XYTOMEM(160,100)]=15; //Fill screen asm { les di,[Screen] mov cx,07D00h mov al,0Fh mov ah,0Fh rep stosw }
You can do the same in Windows but you must get a pointer to the buffer which is easy enough.
32-bit Win32 version with faster bit blt
You can also just call the API to move the memory, zero it, etc.Code:... ... unsigned char *ptrMem=NULL; //Get handle to memory from Windows HGLOBAL memhandle=GlobalAlloc(GMEM_MOVEABLE,64000); //Lock memory region and get pointer to first byte of region (unsigned char *)ptrMem=(unsigned char *)GlobalLock(memhandle); //Fill region asm { les edi,[ptrMem] mov ecx,03E80h mov eax,0FFFFFFFFh rep stosd }
You don't have to use asm you could just as easily use memcpy() but memcpy() only copies BYTEs not WORDs/DWORDs. Best bet would be to have Windows do it for you with ZeroMemory() or some other memory management function the API exposes. Check the Platform SDK for more info.