The 'VB' (Visual-Basic) of 'olde' debate...

[GlennSprigg]

I'm an OLD bastard xox  and my introduction to 'Programming' was 'BASIC'.
For the un-initiated, that was an 'Acronym' for.... "Beginners All-purpose Symbolic Instruction Code"
It was INTENDED to be just that, as an introduction to how a structured programming interface could be.
UNFORTUNATELY, the 'Acronym' suggested that it was way inferior and useless... (sigh). I 'beg' to differ.

TRUE 'programmers' back then, MOCKED it, as it was not a 'REAL' language, with any real 'Power'....
EVEN code breakers/hackers hated it, quoting that "No real programmer would use this!!", mainly because
when they used their "You-Beaute" tools on it, to crack/follow, ALL they got was thousands of procedure
calls, (an unfortunate result of 'basic' xxx) without being able to 'follow' in a simple way, the '.exe' coding.
THAT always made me laugh, so even LATER.. I would write the 'encryption' module in 'VB'  xxxxxx

NOW... that it had initially advanced to 'VB', (Visual Basic), and now 'Object-Oriented' in reference,it NOT
only became more wide-spread in it's own right, as "THAT IS WHAT MOST PEOPLE KNEW/UNDERSTAND"
and so there is LITTLE reason that most people had to throw this on the scrap-heap & start all over again !!!

Of COURSE, there were the non-contenders, like 'C', "C++" resulting in the fact that OBVIOUSLY we would
NOT write an 'App' in 'VB' for the next 3D version of "Call Of Duty" etc.  But it's 'Horses-For-Courses'..

And then came the TRUE compilers, so the original 'code' is now optimised.
Then came 'VB-Net'... which is a whole new kettle of fish.....
NOW there is LIMITED differences, as long as you understand 'Classes' etc.....
The "Syntax' almost seems irrelevant now, but the 'compiled' result is what is important.

[Bruce Abbott]

...the 'compiled' result is what is important.

I 'beg' to differ.

What made BASIC useful was being interpreted rather than compiled. This was a huge advantage for beginners because they didn't need to learn how to drive a compiler, linker and debugger. Just type in a line of BASIC and RUN it to see the results immediately! Break into a running program to view/change variables or GOSUB a procedure, then CONTinue or GOTO another line to jump back into the program - or even execute individual instructions directly from the command line.

Add comprehensive syntax and runtime error checking, put the interpreter in ROM so it can't be corrupted, and you have an environment that is practically bulletproof. With no compile and link stage there is no need for a storage device to hold intermediate files. The command line can also be the primary User Interface, then you have an IDE which is ready to use moments after switching on the computer. In the days when RAM and disk drives were expensive, this made ROM BASIC the obvious choice for home computers. 

Of course all this convenience came at a price - execution speed. A typical BASIC interpreter is 100-1000 times slower than 'raw' machine code. This was not helped by prioritizing memory footprint over speed, and using high precision floating point when integers could do. I think that was the main reason we considered BASIC to be 'inferior' and 'useless' - we wanted something that produced efficient machine code for graphics etc. (read 'games'), not a souped-up programmable calculator. Secondary complaints included the need for line numbers  (really a limitation of the editor) and lack of structured coding style. However CPUs have now become so powerful that these complaints no longer apply. A reasonably modern PC runs QBASIC so fast you would think the code was compiled!

I have done a bit of coding in FreeBASIC, which is compatible with QuickBASIC but also interfaces with C, Windows API, OpenGL and GTK+ etc. I just write the code in Textpad, then invoke the FreeBASIC compiler with a control key. Compilation only takes a few seconds so it's almost like using an interpreter, and it produces standalone apps that don't need any extra runtime libraries.
   

Then came 'VB-Net'... which is a whole new kettle of fish.....

A whole lot of crap IMO. Recently I needed to upgrade the firmware on a transceiver module, for which they provided a small utility program. Tried to install it and got this...
 
       
       

[hamster_nz]

A lot of BASIC's popularity in the 80s was that it was small enough to be put in a 16kB (or smaller) ROM - making it the "Minimum Viable Product" of programming languages for "Minimum Viable Product" of computers.

I remember the joys of getting my hands on a C compiler - Borland Turbo C for MSDOS. Lugging kilos of manuals home on the train, calling INT 10h and then writing to memory at ((unsigned char far *)0xA000000) without resorting to assembler.

[kripton2035]

try Xojo : www.xojo.com
free to try, there is a VB converter available
you pay a licence to compile a standalone application, but you can try forever in debug mode.
it's object oriented, but there is no .net

[EEVblog]

TRUE 'programmers' back then, MOCKED it, as it was not a 'REAL' language, with any real 'Power'....

BASIC (7.1) PDS was an excellent professional compiler and environment.
I remember running various speed and code size tests on it compared to Turbo PASCAL and Turbo C at the time, and it beat them.

[shawty]

Well since my first ever exposure to computing back in the late 1970's was "Sinclair Basic" I suppose I should really be Biased.

However, as good as it was, I was only discovering on a ZX80 at the time, so very quickly I learned that to get the best out of the language, what I needed to be doing was using Basic as a vehicle to poke Z80 machine code bytes directly into ram, and hence became rather good at writing data statements and loops to process them, but not much else ...

It wasn't until a few years later round about the age of 10, that I got my hands on what I still consider today, my first REAL computer, a BBC Model B Micro.

Prior to getting my BEEB , everything else just felt like a glorified toy, the BBC was the machine that really propelled me forward, and that would never have happened if not for "BBC Basic"

Even when I progressed to the Archimedes, I still made heavy use of the built in Basic Interpreter, even if I was still using them as a vehicle to also do assembly programming.

The thing with BBC Basic for those that have never used it however, was it had a built in Assembler, so you could freely intermix high level and low level code, and it would be readable too.

My BBC However opened me up to a whole world of new Languages.  The BBC Could have extra "Language Roms" added to it, and for mine I had "ISO Pascal", "BCPL" and "Comal" languages, and also at some point a C compiler called "Small C" that ran entirely from 5.25 floppy disk!

Eventually though like many, I ended up working in the glorious IBM Compatible / Windows environment, and eventually VB6 did indeed appear on my radar.  VB6 worked for me at the time, beacuse I was still trying to wrap my head around the windows API, and making windows programs by having to build the winmain and message pump loops by hand.

VB6 instantly took ALL of this pain away from me, and made me productive again.

C/C++ was never really a problem, and doing console stuff, with gfx libs that I knew was fairly easy, but I knew then that GUI stuff was the way forward, and it wouldn't be too long before majority of folks started using Computers in a point & click fashion.

So back to VB6 I went.  Never really left C/C++ behind, but never really used it to make windows apps with.

VB6 then led onto Delphi, and even though I set my self the task of learning OOP (Beacuse I thought I didn't know what it was) it turned out eventually, that VB6 had been showing me what OOP was for a year or more, and I'd been using it all along.  When the penny finally dropped, boy did I feel stupid :-)

Delphi eventually lead onto C#, and I gradually drifted back into C/C++ like languages, today most of the work I do is in C# and all that hideous stuff folks collectively refer to as the "Web Stack" hughhh it's rancid... it really is :-(

Given that Iv'e been getting back into embedded programming recently, Iv'e also started getting back into small scale C and remembering all my optimization tricks from my early years, however as far as VB6 goes, I don't think I'd be doing what I'm doing today if it wasn't for the language.

I'd still be a developer, that much is for sure, but I'dd likley be doing games programming in C++ or I might even have stuck more to the hardware side, and been full time in embedded dev instead of looking up on it as a hobbyist extension of my career. :-)

[Berni]

There is also the fact that some old HP test gear can run HPs own "Instrument BASIC" right on the instrument. Also lots of test gear manuals give examples of how to talk to it over GPIB inside of BASIC.

But the modern VB.net still serves perfectly fine as a VB6 replacement. The IDE is sort of similar with its ease of use. Its still quick to jump in and make a quick little app without setting up anything. Tho the language itself has become a bit more convoluted but in return you get tons of built in libraries and very quick code execution. Yes its still interpreted, but its modern tricks lets it get surprisingly close to raw compiled C code.

But if we are looking for a modern BASIC then that could perhaps be Python. It shares a lot of characteristics, its designed to be simple and friendly to new programmers, its just a text file that gets fed into a interpreter directly, its meant for quickly making small tools rather than big full fledged applications. It also had the usual speed penalty. Its a bit more popular with the open source crowd tho since pretty much anything with linux has a python interpreter installed.

[GlennSprigg]

Mainly to Bruce Abbott..... (though thanks to others !!!)
I understand what you are saying mate...., and I am not trying to dis-agree 
Although as I said, once the final 'code' (Psudo-code) WAS fully 'Compiled', it WOULD
run faster, and be less dependent on sub-systems & .DLL's etc.  As I stated, it could not,
and does not, compare to more directly interpreted high-end languages, however the MAIN
difference I'm talking about is "average/normal" processing software, (on a modern computer)
as opposed to say Hi-Res 3D animation software, for which there is obviously no comparison.
Many people were 'brought-up' on 'Basic'/VB/VB.net', which Sufficed beyond the original Acronym 

And even back when I was using the original 'VB', the First thing I learn't was to NEVER use GOSUB/GOTO 
and instead learning about proper structured programming, which would be interpreted properly.....

Obviously, "VB.net" has thrown many spanners in the works! in it's desire to more 'Standardize' the structure.
Which has virtually meant a complete re-write, so as to conform with 'standard' Classes etc etc.
And this obviously involves the 'dreaded' "VB.net UpDates" at times, but SO DOES the "C/C++" Libraries ??

I only ask not to'kill' what a hell of a lot of people know & use, if 90% of the time that is all that is needed 
We don't need a 'Lamborghini' to drive around the corner to the shop, to get some milk !!  (Or wine... )

[dferyance]

I see the JavaScript world kinda becoming the new Visual Basic at least in the field I work in. Instead of copying / pasting VB snippets everyone uses NPM in a similar way; don't know, or care what the code does, just throw it in and hope it works. GUIs are done in Electron, not because it is good, but it is what people know. It is a simple language to learn with lots of information available on the web.

The issues running Node.JS applications remind me of the old missing VBRun DLLs. Oh, you have the right DLL, but it is the wrong version... oh, now that you upgrade you broke something else. That all happens between nodejs versions and NPM package versions. I miss being able to give someone an EXE and just run it.

I will always mock it as not a real language and the horrible limitations it has. It has no integer data type, no threads, no static typing. Performance is just terrible. This is despite the fact that I do a lot of work in JavaScript. So it is very ugly, but also very practical.

The only thing I see as being very different is in the JavaScript world they like to throw away "old" libraries after 6 months as being obsolete and you should know better than to use this, cause something new and cool is here. VB was never like that. That is a pretty striking difference. But outside of this craziness, there is a lot of beginner-friendly, simple stuff being done in it.

[shawty]

I see the JavaScript world kinda becoming the new Visual Basic at least in the field I work in. Instead of copying / pasting VB snippets everyone uses NPM in a similar way; don't know, or care what the code does, just throw it in and hope it works. GUIs are done in Electron, not because it is good, but it is what people know. It is a simple language to learn with lots of information available on the web.

The issues running Node.JS applications remind me of the old missing VBRun DLLs. Oh, you have the right DLL, but it is the wrong version... oh, now that you upgrade you broke something else. That all happens between nodejs versions and NPM package versions. I miss being able to give someone an EXE and just run it.

I will always mock it as not a real language and the horrible limitations it has. It has no integer data type, no threads, no static typing. Performance is just terrible. This is despite the fact that I do a lot of work in JavaScript. So it is very ugly, but also very practical.

The only thing I see as being very different is in the JavaScript world they like to throw away "old" libraries after 6 months as being obsolete and you should know better than to use this, cause something new and cool is here. VB was never like that. That is a pretty striking difference. But outside of this craziness, there is a lot of beginner-friendly, simple stuff being done in it.

It's not just electron.  Folks use that for "Native Apps" (Or that's what the marketing folks want you to believe anyway), NPM is a cancer for sure, but it's way more than that.  In the last 4 years we've got npm, and we've had bower, oh and we've had "Build Systems" such as Grunt & Gulp, and now WebPack.

In GUI terms, we have Angular, Aurelia, Vue, React, React+Native, Redux, Knockout, and about a million others which I just can't remember at the moment...

JavaScript is simply put, just a bloody minefield, end of.

The problem is, is it's not so much the "Visual Basic" mentality, that strikes me as the problem of code copying, it's the plethora of people who would have you believe that it's "EASY".

Most of these folks are the ones trying to sell books, and JS training courses, and anything else that involves learning the hottest cross platform environment ever....   and as anyone knows who's spent more than a shake of the fist in this industry it's definitely not easy.

I run a number of user groups on the net, and the sheer amount of people that ask the same question (Whats the quickest way for me to get from 0 to hero and the riches it brings me) in different guises is just mind boggling.  People genuinely believe that writing software in JavaScript is easy, and more and more jump on the band waggon every day.

Many quickly give up when they realize it's not the easy ride they hoped, but there are many who continue to chase that dream of zero work with maximum profit, and as long as we still have those, the marketing folks will just keep peddling to them.

I'll shut up now.....

Sorry... I get a bit passionate about this subject sometimes :-D

For those that hate JavaScript, but have no choice but to use it, I would strongly suggest taking a look at TypeScript....

Shawty

[mikeselectricstuff]

Even when I progressed to the Archimedes, I still made heavy use of the built in Basic Interpreter, even if I was still using them as a vehicle to also do assembly programming.
The thing with BBC Basic for those that have never used it however, was it had a built in Assembler, so you could freely intermix high level and low level code, and it would be readable too.

Yes - BBC Basic was awesome (both on the 6502 and ARM). The built-in assembler meant that your assembler macro language was Basic, so you could do ridiculous things with conditional & looped assembly etc. You could type in assembler at the commmand line, run it and look at results etc. interactively.

VB6 instantly took ALL of this pain away from me, and made me productive again.

I started PC programming with Turbo Pascal under DOS, which was OK, but for Windows, VB6 made knocking up reasonable-looking Windows apps extremely quick and easy - you only needed to learn the bits you actually needed to do what you needed. I still use it a lot as I don't do enough  PC stuff to spend the time learning anything else.  biggest PITA is it needs DLLs so you can't create standalone .exe Lack of unsigned types is also a pain when doing the sort of serial comms stuff I mostly use it for.

[hagster]

VB.net is actually very powerful and easy to use. Its much much better and less restricitve than VB6. Being able to run intesive calculations on a seperate thread to the GUI is the biggest single advantage(i know there were some really horrid workarounds with VBy to do this).

Currently there is very little technical difference between VB and C#. I can use either and they basically compile to the exact same IL.

I have also done some C# on ARM microcontrollers with .netmf. That really great if you can stand the performance hit. Sadly MS never really invested in this tech. GHI have now created their own fork called TinyCLR, which I havent tried yet.

Currently though the MS lineup is really confusing to me. Every year or so, i give WPF a try so you can get all the sweet graphical updates and create universal windows apps etc, but the XAML crap is just a mess. I really hate it. The learing curve is so steep, i feel I might as well switch to a completely new language.

[Berni]

Well VB6 could do multi threading too but it requires API calls in to the OS much like most of the more advanced things in VB. These calls let it do some pretty impressive things but using them was a mess and if you did something really wrong it had the potential to not only crash your program in the weirdest of ways but also the entire IDE with it

VB.net just made all the advanced things a lot easier by cramming the .net framework full of built in libraries for just about any thing you would imagine. This is great when you want to quickly throw something together and it doesn't create any external DLL dependencies. Tho you might have to stay away from the latest libraries if you still want to be able to run on Windows XP.

As for WPF i never liked it. I don't see the appeal of making a UI like is a web page. Sure its multiplatform but this is not new. Back in 2005 if you simply targeted your forms based app at the right version of .net framework it would create a EXE file that runs both on a Windows PC or on Windows CE/Windows Mobile/Windows Smartphone. But then Microsoft axed that platform to replace it with Windows Phone 7 and we all know how well that went.

[kaz911]

Even when I progressed to the Archimedes, I still made heavy use of the built in Basic Interpreter, even if I was still using them as a vehicle to also do assembly programming.
The thing with BBC Basic for those that have never used it however, was it had a built in Assembler, so you could freely intermix high level and low level code, and it would be readable too.

Yes - BBC Basic was awesome (both on the 6502 and ARM). The built-in assembler meant that your assembler macro language was Basic, so you could do ridiculous things with conditional & looped assembly etc. You could type in assembler at the commmand line, run it and look at results etc. interactively.

VB6 instantly took ALL of this pain away from me, and made me productive again.

I started PC programming with Turbo Pascal under DOS, which was OK, but for Windows, VB6 made knocking up reasonable-looking Windows apps extremely quick and easy - you only needed to learn the bits you actually needed to do what you needed. I still use it a lot as I don't do enough  PC stuff to spend the time learning anything else.  biggest PITA is it needs DLLs so you can't create standalone .exe Lack of unsigned types is also a pain when doing the sort of serial comms stuff I mostly use it for.

And BBC Basic was procedural ! No need for GOTO! There was real FUNCTION CALLS ...

And I went for Poly Pascal after BBC (Poly Pascal was the CPM version prior to the DOS version & Borland versions/re-branding by Philippe Khan)  - and then Borland Turbo Pascal...

[shawty]

....

VB classic has the P-code mode and native code mode, and the native code mode is indeed a compiled mode, but still, the generated EXE heavily depends on runtime libraries (yes, plural, a lot of them, somewhere like 7 DLLs) even for some very basic functions, so though compiled to machine code, it's still fairly managed code. P-code is an IL, just like .NET, but a bit closer to the low level. I presume .NET has a lot learned from P-code.

....

You could argue that, that was one of it's best features.  Even today.  I can easily take an app done in VB.NET and reverse engineer it, even one that's been obfuscated, but try doing the same with a P-Code or native VB6 app, and you where in for a mountain of pain.  It was doable, don't get me wrong, but it took tremendous effort, and was only worth it if the stakes where high enough.

That said, dotnet core and it's new native/stand alone modes is starting to address the problem of code protection, so it's not all bad. :-)

[shawty]

Even when I progressed to the Archimedes, I still made heavy use of the built in Basic Interpreter, even if I was still using them as a vehicle to also do assembly programming.
The thing with BBC Basic for those that have never used it however, was it had a built in Assembler, so you could freely intermix high level and low level code, and it would be readable too.

Yes - BBC Basic was awesome (both on the 6502 and ARM). The built-in assembler meant that your assembler macro language was Basic, so you could do ridiculous things with conditional & looped assembly etc. You could type in assembler at the commmand line, run it and look at results etc. interactively.

VB6 instantly took ALL of this pain away from me, and made me productive again.

I started PC programming with Turbo Pascal under DOS, which was OK, but for Windows, VB6 made knocking up reasonable-looking Windows apps extremely quick and easy - you only needed to learn the bits you actually needed to do what you needed. I still use it a lot as I don't do enough  PC stuff to spend the time learning anything else.  biggest PITA is it needs DLLs so you can't create standalone .exe Lack of unsigned types is also a pain when doing the sort of serial comms stuff I mostly use it for.

And BBC Basic was procedural ! No need for GOTO! There was real FUNCTION CALLS ...

And I went for Poly Pascal after BBC (Poly Pascal was the CPM version prior to the DOS version & Borland versions/re-branding by Philippe Khan)  - and then Borland Turbo Pascal...

Agree 100% with all of this... in fact, I think a lot of today's modern day programmers should be exposed to this kind of environment, it might make a lot of them better developers.

@mike I too did Turbo Pascal (64k Com files... those where the days :-)   ) but with my BBC, I also had ISO Pascal in ROM too which was quite interesting.

[bd139]

BBC BASIC and assembly was a winner for me. Assembly to do the work. BASIC to glue the bits together.

The BASIC that shipped on the Archimedes series of machines was a completely different language to usual basic. No line numbers required.

[mikeselectricstuff]

BBC BASIC and assembly was a winner for me. Assembly to do the work. BASIC to glue the bits together.

The BASIC that shipped on the Archimedes series of machines was a completely different language to usual basic. No line numbers required.

..and do / While loops, Switch type statements etc. etc. 
And it was hand-coded in assembler by the person who designed the instruction set, so it's as fast as any interpreted language could be. You can run it on a RasPi at ridiculous speeds...
 

[shawty]

BBC BASIC and assembly was a winner for me. Assembly to do the work. BASIC to glue the bits together.

The BASIC that shipped on the Archimedes series of machines was a completely different language to usual basic. No line numbers required.

..and do / While loops, Switch type statements etc. etc. 
And it was hand-coded in assembler by the person who designed the instruction set, so it's as fast as any interpreted language could be. You can run it on a RasPi at ridiculous speeds...

That would be Sophie Wilson (https://en.wikipedia.org/wiki/Sophie_Wilson) or "Roger Wilson" as s(he) was known back then :-)

She's also responsible primarily for the ARM Instruction set, and the first batch of ARM 2/3 CPU's too.    (Sorry I'm a bit of a history geek too....)

[Berni]

VB has never been a "true" compiled language (machine code?).

VB classic has the P-code mode and native code mode, and the native code mode is indeed a compiled mode, but still, the generated EXE heavily depends on runtime libraries (yes, plural, a lot of them, somewhere like 7 DLLs) even for some very basic functions, so though compiled to machine code, it's still fairly managed code. P-code is an IL, just like .NET, but a bit closer to the low level. I presume .NET has a lot learned from P-code.

Then comes to .NET. Unless you hack the CLR or use some weird, evil methods from Cecil or something, you will never be able to touch machine code from .NET unless you import an unmanaged library.
AOT can compile your managed code to lower level, but that's still not very low level as machine code. It can embed Mono runtime, but it still needs it.

Don't think i ever seen a machine code compiled implementation of VB, but one could argue that the making API calls in to system DLLs brings machine code in to VB.

As for mixing .NET with machine code i have done it before using a unmanaged DLL. In VisualStudio the process is surprisingly smooth once its set up since you can just add a VisualC project in to the workspace and have all its stuff show up in C# with proper intelisense. Upon running the main app it recompiles the DLL if needed and debug single steps into the DLL and back out just fine. It even lets you change the C++ code while the app is running and incrementaly compile the code back up in to memory once you resume execution. However moving data in and out of that blob of C++ code is not as straight forward as throwing an array at it. It always needs converting back and forth between the fancy managed array objects and the "pile of numbers somewhere in memory" arrays that C++ uses. Its not fun.

[shawty]

VB has never been a "true" compiled language (machine code?).

VB classic has the P-code mode and native code mode, and the native code mode is indeed a compiled mode, but still, the generated EXE heavily depends on runtime libraries (yes, plural, a lot of them, somewhere like 7 DLLs) even for some very basic functions, so though compiled to machine code, it's still fairly managed code. P-code is an IL, just like .NET, but a bit closer to the low level. I presume .NET has a lot learned from P-code.

Then comes to .NET. Unless you hack the CLR or use some weird, evil methods from Cecil or something, you will never be able to touch machine code from .NET unless you import an unmanaged library.
AOT can compile your managed code to lower level, but that's still not very low level as machine code. It can embed Mono runtime, but it still needs it.

Don't think i ever seen a machine code compiled implementation of VB, but one could argue that the making API calls in to system DLLs brings machine code in to VB.

As for mixing .NET with machine code i have done it before using a unmanaged DLL. In VisualStudio the process is surprisingly smooth once its set up since you can just add a VisualC project in to the workspace and have all its stuff show up in C# with proper intelisense. Upon running the main app it recompiles the DLL if needed and debug single steps into the DLL and back out just fine. It even lets you change the C++ code while the app is running and incrementaly compile the code back up in to memory once you resume execution. However moving data in and out of that blob of C++ code is not as straight forward as throwing an array at it. It always needs converting back and forth between the fancy managed array objects and the "pile of numbers somewhere in memory" arrays that C++ uses. Its not fun.

Don't forget you have "Unsafe" mode in C# too.  As well as doing funky pointer arithmetic, I do believe you can also do ASM direct inline with the C# code too, although I have to admit, Iv'e never tried it.

Don't know if VB.NET has anything similar though, I'm more of a C# person "I Like Brackets" :-)

[digsys]

Started on Basic, GWBasic, QuickBasic and several versions after. With HEAPS of 3rd parts add-on libraries - with all machine code supplied.
Still use VB6, VB.net 5? is compatible. Sometimes have to use VBExpress / Net10? which is very different and a pain. Still do my own assembly inserts.
Too old to change :-)

[Johnboy]

Secondary complaints included the need for line numbers  (really a limitation of the editor) and lack of structured coding style.

10 REM SUPERFLUOUSEND
20 GOTO 10
30 END

Sorry, couldn't resist. Honestly, most of the programming in BASIC I did involved laboriously copying text games by hand while changing dialogue and command options. It was fun while it lasted. 

[Tony_G]

Then comes to .NET. Unless you hack the CLR or use some weird, evil methods from Cecil or something, you will never be able to touch machine code from .NET unless you import an unmanaged library.

I remember sitting in several meetings where we disucssed adding an inline MSIL capability to C# (just like C/C++ has inline assembler - Still not a machine code thing, this thread just brought up the memory) From my admittedly hazy memory, I think several tests showed that the ability to handcraft MSIL wasn't going to be much better than the compiler after the JITer had finished with it anyway so that feature never got implemented as a value vs cost decision.

Then again, now I think about it, this might actually have been from VJ++ with inline bytecode (I'm old and forgetful now) - Either way never made the cut.

TonyG

[free_electron]

Try PowerBasic ... It kicks almost all other languages to the curb in terms of speed. That is a really clever compiler ...