Visual Basic vs C++

**sean** · 07-21-2004

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.

**EvBladeRunnervE** · 07-21-2004

I might not be capable of undersanding this thread, but you also seem to be incapable of supporting your statements.

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.

**Zach L.** · 07-21-2004

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.

**EvBladeRunnervE** · 07-21-2004

you can't do anything that low level and the thing the guys said you can

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.

**VirtualAce** · 07-21-2004

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.

**nvoigt** · 07-22-2004

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#.

**nvoigt** · 07-22-2004

Originally Posted by C+++C_forever

Why does everyone say that C is a low level language? I can't see what's the so low level thing someone could do with standard C.

Originally Posted by ober

Hardware interfacing. Low level means that you can do things like set bits and flags in the OS that affect hardware that you can't do in higher level languages.

In 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.

Therefore standard C is a low level language.

If this does not answer your question, please try to rephrase it.

**Fordy** · 07-22-2004

Originally Posted by Bubba

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.

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 NT

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

**nvoigt** · 07-22-2004

Any interaction with the world, other than through the console and files, is not a part of standard C.

Writing directly to the video buffer was something that could be accomplished using 5 lines of standard C without any APIs.

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.

**nvoigt** · 07-22-2004

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. )

**Fordy** · 07-22-2004

Originally Posted by nvoigt

( 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. )

You can also check out some of the old stuff here at CProg - http://www.cprogramming.com/advtutorial.html

**nvoigt** · 07-22-2004

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.

**sean** · 07-22-2004

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.

**EvBladeRunnervE** · 07-22-2004

Windows don't allow you to do anything like that ( don't know about Linux ) so in windows you are helpless with the standard

oh, you can, but you have to enter DOS 13h graphics mode, which is pretty easy:

Code:

__asm
{
mov ah,13h
int 0x10
}

then you can get a pointer to 0XA000 and go to town so to speak.

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

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.

**VirtualAce** · 07-22-2004

actually a more safe version of the code:

16-bit DOS version

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
}

That code is safer because if you specify an offset from screen >64000 then it will wrap around since it is a BYTE pointer.

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

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 can also just call the API to move the memory, zero it, etc.

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.