Quote Originally Posted by 2kaud View Post
The issue in interfacing with say WIN32 APIs is that the underlying CRT (c run time) that provides the memory management doesn't provide necessary functions to enable run-time checking (eg is address valid, start address of allocated block, size of memory block etc). This has been an issue since the beginning of c and isn't likely to change any time soon.
It's actually a reflection of the time Windows was developed in. C is filled with a bunch of undefined behaviors by design. It wasn't a mistake. You see there are penalties for safety and I guess it was considered acceptable to not take that bargain in the 80s and 90s. You have to sacrifice power and performance for safety. This is one of the underlying reasons why BASIC for most of it's life was never taken seriously as a language because it gave up power and performance for safety.

I mean lets take arrays for example. What would it have taken to make them safe in C? Well you'd have to define what happens when you write outside of it. This means that you now have to keep track of where every array starts in memory and where it ends. Finally, the compiler has to insert checks using these values to determine every time the array is accessed if the access was out of bounds. What is this starting to sound like? Yes, it sounds exactly like how SAFEARRAYS work in COM which is what VB6 uses for it's native arrays. However, you pay a penalty, every array access now adds the penalty of bounds checking. If you did this same mental exercise for pointers, starting with the question, what would it take to make them safe, you'd end up with something resembling object references. Object references are actually one possible solution to the problem of unsafe pointers.

These abstractions are costly in performance and memory which is why the C compiler doesn't provide them. It keeps the language fast but places the burden of responsibility for safety on the programmer. You have to make sure to never access an out of bounds array and you also have to be willing to pay the price if a bug in your code leads to that.

Things have changed today. Abstractions like object references and safe arrays are now considered acceptable in "serious" languages probably due to the extreme performance characteristics of modern CPUs compared to their ancient ancestors. However, it's too late to change the monolithic juggernaut that is Windows to reflect this so we are stuck with having to deal with C's mess in the Windows API.

However, I don't think it's necessary to change the Windows API if you want to be able to create completely safe and well behaved programming languages targeting Windows. Python and .Net in particular prove this. You can write just about kind of program in these languages without ever having to touch the unsafe Windows API yourself. This too has a cost though, which is a massive layer of abstraction between you as the Python/.Net coder and the operating system.

To bring it back around to this topic of pointers in TwinBASIC. I've always viewed VB6 as sitting somewhere between C and something like .Net/Python. It provides enough abstractions to make it a relatively safe language while also maintaining near C-like performance and power. TwinBASIC starts at this mid point too because it begins as a VB6 clone. But the language will inevitably evolve and it has to go in one of two directions. It can either move closer to C or closer to .Net. Introducing first class pointers to TwinBASIC moves it a lot closer to C and while I don't really object to it, I worry about this direction. Debugging C code is an absolute nightmare because of how unsafe it is. Someone gives you some code that prematurely releases a pointer that is later dereferenced good luck trying to discover it. You're not going to get some nice neat error that tells you what is wrong. The application might just bomb out with no error or warning and it may not do that every single time. This makes forensics extremely difficult. I wonder if we are ready to bring more of this kind of thing to BASIC.

I guess I always imagined one day that the talents of the VB6 community like Olaf, Trick, Fafalone, Elroy etc would all make contributions to TwinBASIC that would become something of a standard library that covers just about everything a programmer would need so they can move away from doing unsafe stuff with CopyMemory, VarPtr and the Windows API. The result of this would be well behaved code bases that are easy to debug. This seems like a very natural direction for a descendant of BASIC.