Visual Basic vs C++

This is a discussion on Visual Basic vs C++ within the A Brief History of Cprogramming.com forums, part of the Community Boards category; Ok googlee for that guy and read about his 4 points Reading the 4 points will teach you almost nothing ...

  1. #31
    Super Moderator
    Join Date
    Sep 2001
    Posts
    4,913
    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.

  2. #32
    'AlHamdulillah
    Join Date
    Feb 2003
    Posts
    790
    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.
    there used to be something here, but not anymore

  3. #33
    Toaster Zach L.'s Avatar
    Join Date
    Aug 2001
    Posts
    2,686
    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.

  4. #34
    'AlHamdulillah
    Join Date
    Feb 2003
    Posts
    790
    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.
    there used to be something here, but not anymore

  5. #35
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    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.

  6. #36
    the hat of redundancy hat nvoigt's Avatar
    Join Date
    Aug 2001
    Location
    Hannover, Germany
    Posts
    3,139
    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.

  7. #37
    the hat of redundancy hat nvoigt's Avatar
    Join Date
    Aug 2001
    Location
    Hannover, Germany
    Posts
    3,139
    Quote 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.
    Quote 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.
    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.

  8. #38
    &TH of undefined behavior Fordy's Avatar
    Join Date
    Aug 2001
    Posts
    5,789
    Quote 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

  9. #39
    the hat of redundancy hat nvoigt's Avatar
    Join Date
    Aug 2001
    Location
    Hannover, Germany
    Posts
    3,139
    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.
    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.

  10. #40
    the hat of redundancy hat nvoigt's Avatar
    Join Date
    Aug 2001
    Location
    Hannover, Germany
    Posts
    3,139
    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.

  11. #41
    &TH of undefined behavior Fordy's Avatar
    Join Date
    Aug 2001
    Posts
    5,789
    Quote 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

  12. #42
    the hat of redundancy hat nvoigt's Avatar
    Join Date
    Aug 2001
    Location
    Hannover, Germany
    Posts
    3,139
    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.

  13. #43
    Super Moderator
    Join Date
    Sep 2001
    Posts
    4,913
    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.

  14. #44
    'AlHamdulillah
    Join Date
    Feb 2003
    Posts
    790
    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.
    there used to be something here, but not anymore

  15. #45
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    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.

Page 3 of 8 FirstFirst 12345678 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 10
    Last Post: 11-22-2007, 11:13 PM
  2. Run Visual Basic code inside C++?
    By torbjoen in forum Windows Programming
    Replies: 8
    Last Post: 07-31-2002, 11:41 PM
  3. <list>
    By Unregistered in forum C++ Programming
    Replies: 9
    Last Post: 02-24-2002, 03:07 PM
  4. Visual Basic C++
    By gussguss in forum C++ Programming
    Replies: 8
    Last Post: 11-20-2001, 09:58 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21