Printable View
The issue here is that 99% of the use case for this is interacting with the Windows API-- i.e. the things you see wrapped in unsafe in Rust. I searched for examples of doing some simple things with shell interfaces like I typically do in Rust, unsafe unsafe unsafe unsafe....Quote:
Originally Posted by Niya
I found that JS, python, VBS, VBA, VB6, many languages are similar to scripts, which do not need to specify the ,type of variables.variant,So VB6's route was correct.
But Microsoft completely abandoned him. VB. Net, mandatory declaration of variable types, very long syntax.
It can be said that it deviates too much from VB6.
Just like when we drive too close, the anti-collision system will automatically turn on.
If you accidentally doze off, he will also remind you. It also has an automatic driving system.
Without specifying the type of the variable, it runs a little slower, but the more powerful the CPU is, the more it makes up for.
In fact, if Microsoft takes a little time. Adding multithreading to VBA or VB6 can take less than a week, or even a day.
As long as he doesn't value users. He doesn't want to spend an extra hour or a month.
[Total Rowlocks. Well meaning perhaps but nevertheless, rowlocks not in context. Bloody obvious statements too.]
I retract that, it did make some sense but I had to read it ten times before the meaning arrived.
I see what you're saying but the truth is, you really cannot avoid this with the Windows API, no matter how safe the host language is but let's pretend for a minute we had real pointers in VB6/TwinBASIC. This is what I'm concerned about:-Quote:
Originally Posted by fafalone
Pointers would allow you to do stuff like that and while no one would ever do that deliberately, such things will happen accidentally. Now of course you could do the same thing like this:-Code:'Imagine this is a pointer to a Long
Dim p As Long*
'This is just a normal Long value
Dim value As Long
'Assign an arbitary address to the pointer
p = &HDEADBEEF
'Dereference the pointer. The result is undefined because
'we just assigned a random address to p
value = *p
This difference here is that you have to deliberately circumvent the protections of the runtime and compiler to do it. In the first instance the language itself is unsafe because it's actually supported by the compiler.Code:Public Declare Sub RtlMoveMemory Lib "kernel32" (ByVal Destination As Long, ByVal Source As Long, ByVal Length As Long)
Private Sub Form_Load()
'Imagine this is a pointer to a Long
Dim p As Long
'This is just a normal Long value
Dim value As Long
'Assign an arbitary address to the pointer
p = &HDEADBEEF
'Dereference the pointer. The result is undefined because
'we just assigned a random address to p
RtlMoveMemory VarPtr(value), p, 4
End Sub
But like I said, I personally have no problems with pointers being introduced into a BASIC variant but I do think that violates that silent contract of safety we have come to expect from any language derived from BASIC. BASIC compilers have traditionally never allowed undefined behavior through it's own primitives. It was only ever allowed on a kind of opt-in basis through functions like VarPtr or Peek/Poke in the QuickBasic era.
See I just can't draw a meaningful barrier between the language itself and an API whose use is ubiquitous. Who's making any serious program *without* calling CopyMemory at least once somewhere?
The ship sailed when VarPtr and AddressOf became language features. If you view VarPtr as opt-in, which I didn't think you would since it's language-intrinsic rather than an optional api needing to be declared, then so would the other hypothetical pointer keywords (I don't think * would be the way to go, since as you say it is BASIC).
I am seeing this as a bit of a Catch 22 scenario - currently VB6 requires the use of CopyMemory (and related APIS) and therefore pointers to do an awful lot of things, therefore making pointers accessible is the solution. However, if the language didn't require the use of CopyMemory etc. for so many things, would the need for pointers be so high on your list of needs?Quote:
Originally Posted by fafalone
But how could that happen without relying on a massive framework and likely moving to a managed code model; i.e. becoming .NET?
Ok let's look at compilers at a more fundamental level. Lets think of all the things provided by the VB6 compiler except the ability to call functions. We have arrays, UDTs, variables of different types like String, Longs, Integers, For...Next loops, Do...While loops, On Error statements, Goto statements, GoSub/Return, Redim, Set statements, the Nothing keyword, operators like =, +, And, Or. Considering all of these compiler primitives, I challenge you to find any way to combine them such that they produce undefined behavior. If you divide by 0, you will get a division by 0 error every time. If you try to assign a String to a Long, you will get a type mismatch every time. If you try to write past the end of an array, you will get a subscript out of range error. There is no kind of mistake you can make that doesn't have a defined outcome. This is a very deliberate design and has been true of just about every variant of BASIC since the beginning of time. Introducing pointers at this level changes this.Quote:
Originally Posted by fafalone
Now, the reason I excluded the ability to call functions is not arbitrary. It is because no compiler on Earth can make guarantees about functions. Compilers can guarantee the behavior of their operators or arrays but they cannot guarantee that functions will behave. This is why they are the only way you can overcome the barriers put in place by the VB6 compiler to prevent undefined behavior.
Now if we did the same exercise with C, we can induce all kinds of undefined behaviors using just the basic compiler primitives. Eg:-
Division by 0 is undefined in C. It could throw an error on one compiler and give you a garbage result on another. Even different versions of the same compiler may do different things. There's no guarantees about it. Here's another example:-Code:int i = 4 / 0
We allocated space for 5 ints but are writing 100 ints to the array. There is no guaranteed outcome here either. BASIC compilers on the other hand, have always guaranteed an error when you do this with it's arrays. BASIC has always been this kind of language at the most fundamental level. This is what I'm trying to get at. It's about the guarantees provided by the compiler at a fundamental level. You can do anything with functions and APIs but the very building blocks of the language itself has built-in ironclad guarantees.Code:int array[5];
int* ptr = array;
for (int i = 1; i <= 100; i++)
*(ptr++) = i;
[EDIT]
I almost forgot, AddressOf. This is also a provided by the compiler and while it does deal in pointers, you actually cannot produce undefined behavior with it fundamentally. You cannot combine it with any of the other language's fundamentals such that it will produced undefined behavior. You can only do that when you involve function calls like VarPtr or APIs.
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.
Just because .Net can do this and it has a large runtime framework doesn't mean that the large framework is required to do this...Quote:
Originally Posted by fafalone
The compiler could be aware of how to pass structures / classes to the various dll conventions (cdecl, stdcall, etc.) and it could take care of managing the actual call. You could have the ability to give the compiler hints, similar to attributes in dotnet, that could control memory layout and padding.
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.Quote:
Originally Posted by 2kaud
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.
TwinBASIC has a package manager does it not? You can have the benefits of a large framework without having to ship a large framework. Every programmer could import only the packages that they need.Quote:
Originally Posted by fafalone
Since the topic of pointers in TwinBASIC came up, I've been trying to figure out where this itch about it really came from. I just remembered, it's about VarPtr. An impression was made on me long before VB6 came onto the scene. BASIC has always had wizards like the trick who could work black magic in the language. When us mortals needed to do something really exceptional in the early days of Visual Basic, we'd very to often end up with finding code written by one of these gods. A curious undocumented function came up quite a bit. It was called VarPtr. It wasn't like it is today. It was undocumented so you couldn't really find official documentation on it and you had to import it from the runtime itself using a declare statement.Quote:
Originally Posted by Niya
Every time it came up it was always accompanied by warnings about how dangerous it was and how it should not never be used unless you absolutely know what you're doing. They made sure we understood why it was undocumented and made us very scared of it. Now in those days, I hadn't really learn about pointers or how ABIs and memory worked or any of that more advanced low-level stuff so you can imagine this left an impression on me.
VarPtr was never meant to be a part of Visual Basic. My guess is that it became more and more popular over the years until MS just gave in and put it in the language when VB6 came around. Microsoft always intended for Visual Basic to be a safe language. I guess this is why it's weird to me for TwinBASIC to have first class pointers because I learned back then that this was never a direction Microsoft wanted to go with the language. Since that time I have always understood why BASIC is the way it is, I just forgot where it started.
You were scared of it, statements about it being undocumented and dangerous have always been like waving a red flag at a bull for me... Im charging full speed right at it and will use it even when it's not necessary.
But if you really want to dig into history, I learned something interesting: ZX-BASIC (Sinclair et al) supported inline asm natively
ASM
...
END ASM
So not *entirely* unprecedented in BASIC.
The ability of advanced users to do fancy things that everyone can then drop in and use is of the big reasons for the enduring popularity of VB6. But it's not just the gods like The trick using pointers, even beginners use them with APIs.
That's true now but back in the day, I remember Visual Basic being a glorified version of VBA. I'm talking in the days of VB2, and maybe VB3. It was mostly used for data-centric CRUD applications. Things like Pascal and C were still being used for "serious" programming. For example, I don't think many people would have dared to attempt creating something like PhotoDemon in Visual Basic back then. Today, that would shock no one. Non-enterprise data-centric CRUD applications do not require that much. Forms, TextBoxes, Lablels, ListBoxes etc, along with a COM based database API like DAO and some simple built-in file I/O functionality would have been enough for most needs. There were people writing exotic programs back then but it wasn't the norm like it is today.Quote:
Originally Posted by fafalone
I wasn't ready for that back in those days. I simply didn't yet have enough foundational knowledge to understand or appreciate these things yet.Quote:
Originally Posted by fafalone
Well this I didn't know. My path was BASICA, GW-BASIC, QuickBasic, VB2 to VB6 then onto VB.Net later. Never encountered ZX-BASIC as far as I know.Quote:
Originally Posted by fafalone
to talk about the first basic, here is mine which allowed me to make my first programs, the keyboard was intended for the Basic, it was a feat in 1983 :confused:
Attachment 187768
Neat, didn't know Sega made a PC like that.
2 years before MSX same hardware Z80 microprocessor at 3.58 MHz;Quote:
Originally Posted by fafalone
twinBASIC status update:
twinBASIC Update: June 4, 2023
Highlights include a search option to match whole words only, some handy ways to generate GUIDs, and a clever way to deploy and register custom ActiveX controls.
https://nolongerset.com/twinbasic-update-june-4-2023/
can we use like this in twinbasic?Code:Sub Test1()
Dim Arr1() As Variant
Arr1 = Array(1, 2)
' Call DoSub(Array(1, 2)) 'Array() Compilation error: Type mismatch: missing array or user-defined type
Call DoSub(Arr1)
End Sub
Sub DoSub(Arr1() As Variant)
'
End Sub
Code:Call DoSub(array(1.5,2.3))
Call DoSub(array$("a","b"))
Call DoSub(array&(11,22))
No, but you can't in VB6 either.
Wow. That's surpising. Yall need to get on that quick. Almost every language supports this kind of thing now:-Quote:
Originally Posted by fafalone
VB.Net
PythonCode:Public Sub Test1()
DoSub({1, 2})
End Sub
Public Sub DoSub(ByVal values As Integer())
End Sub
JavaScriptCode:def test1():
do_sub([1, 2])
def do_sub(values):
pass
And so on.......Code:function test1() {
doSub([1, 2]);
}
function doSub(values) {
// Your code here
}
It's one of those things where I'd say it's a "must have" in a programming language. I personally use that a lot and it's extremely convenient. You get a lot a value out of this feature no matter what language.
Shouldn’t the parameter of the sub not be without parentheses?
Code:Sub DoSub(Arr1 As Variant)
'
End Sub
The Array function returns an array of Variants, not a Variant containing an array.Quote:
Originally Posted by Arnoutdv
twinBASIC have released an updated 12 month roadmap for twinBASIC...
https://github.com/twinbasic/twinbasic/issues/335
Highlights as follows...
2023-Q2/Q3 (JUN-SEP)
- Complete UserControl / ActiveX support
- Finish all remaining basic controls
- Complete the missing App object methods
- Add Printer/Printers support
- Add the missing features to the new IDE, e.g. rename-refactoring and Test Explorer
2023-Q4 (OCT-DEC)
- Support optimized builds, using the LLVM backend compiler (only available to paid subscribers)
- v1 RC builds at the end of this period
VERSION 1 RELEASE
- Tentative Release Date: 3rd January 2024
2024-Q1 (JAN-MAR)
- Start Analysis Extension API
- Support full inheritance
- Add vbWatchdog support
- Add multi-threading syntax support
- Start cross-platform support for x86/x64 Linux/Mac (only available to paid Ultimate Edition subscribers)
2024-Q2 (APR-JUN)
- Support Edit & Continue
- Start cross-platform support for ARM Linux/Mac/Android (only available to paid Ultimate Edition subscribers)
- Start of reimplementation of all remaining VB6 shipped controls, such as Winsock, MAPI, Adodc, DataGrid, MSCOMM, etc
- Support ActiveX controls on tB forms with unmatched bitness, using a proxy-process (e.g. 64-bit app using a 32-bit ActiveX control)
i hope twinbasic is compatible with vb6, but a lot of new features have been added, after all, vb6 is too old, and many necessary functions have not been implemented
Errr...I don't see any support for first class functions anywhere there in that plan. Do I have to come over on Discord and make some noise :DQuote:
Originally Posted by VB6 Programming
twinBASIC status update:
twinBASIC Update: June 11, 2023
Highlights include a new target release date for version 1, an accompanying roadmap update, and support for Control Arrays.
https://nolongerset.com/twinbasic-update-june-11-2023/
Being excited about control arrays feels a little nerdy but nevertheless I feel the tingle.
can we make twinbasic ide addin(not for vb6 ide addin)
Code:Public FormDisplayed As Boolean
Public VBInstance As VBIDE.VBE
Dim mcbMenuCommandBar As Office.CommandBarControl
Dim mfrmAddIn As New frmAddIn
Public WithEvents MenuHandler As CommandBarEvents '命令栏事件句柄
Sub Hide()
On Error Resume Next
FormDisplayed = False
mfrmAddIn.Hide
End Sub
Sub Show()
On Error Resume Next
If mfrmAddIn Is Nothing Then
Set mfrmAddIn = New frmAddIn
End If
Set mfrmAddIn.VBInstance = VBInstance
Set mfrmAddIn.Connect = Me
FormDisplayed = True
mfrmAddIn.Show
End Sub
twinBASIC status update:
twinBASIC Update: June 18, 2023
Highlights include bug fixes related to timer events, argument/property handling, and IntelliSense, plus a screenshot of a simple browser written in twinBASIC.
https://nolongerset.com/twinbasic-update-june-18-2023/
Excuse my ignorance, but does this happen every time the program looks at the array? In advanced options, if you choose to activate the "Remove array bounds checks" it means that it would be faster, but less secure, is that it?Quote:
Originally Posted by Niya
Hope to keep a few mature old versions of IDE exe and source code, like VB3.0,VB5.0,VB6.0, VBA
Some people prefer that the entire IDE takes up less hard disk space.
When more like VB6, the installation package may change from the earliest 50M to 200M, and finally become 500M.
We like VB6, but we don't like VB.NET.
We only need VB6 to add a few features, such as 64-bit support, CDECL support, and creating multithreading. Add a nice IDE interface.
If you do not save the VB5 source code, want to have less hard disk space, but also want to improve a little is impossible.
-What does your post have to do with tB beta releases?
-VB6 supports CDecl with The trick's patch
-VB6 is never getting updated again unless the source leaks, and it hasn't. Unfortunately not even the msvbvm source leaked with all the other leaks.
-tB is only 11MB; WebView2 is heavier but it's an independent package.
twinBASIC status update:
twinBASIC Update: June 25, 2023
Highlights include experimental data-binding support, a new Q&A channel in the twinBASIC Discord server, and coming 64-bit support for Kr00l's VBFlexGrid control.
https://nolongerset.com/twinbasic-update-june-25-2023/
I know that TwinBasic is under development, but is there any dedicated place where we could raise bugs ?Thank you.
Try its github repo, I would use issues there.Quote:
Originally Posted by Daniel Duta
The ides is once out of development (i.e. 100% done) all issues will be closed and repo removed but frankly no software is 100% ever done so the chance repo's issues section remaining available is pretty high.
cheers,
</wqw>
I can't see the repo being closed unless tB is shut down via legal action or buyout for purpose of killing it... there's always going to be bugs just like every other large scale project, and there's plans for tB long after 1.0, just like all the other languages continue to be updated. According to the roadmap Wayne posted, the long sought-after cross platform work and built in multithreading syntax aren't even getting started until next year after the 1.0 release. (You can multithread now via API; CreateThread can be called without any of the hacks required for that in VB)
You can also report bugs on the twinBASIC Discord #bugs channel, which is just as active as GitHub, or in this thread if neither of those options are acceptable.
twinBASIC status update:
twinBASIC Update: July 2, 2023
Highlights include support for vbaObjAddRef, improvements to the Problems pane, and twinBASIC moving up the BASIC-like language rankings.
twinBASIC Update: July 2, 2023 (nolongerset.com)