TwinBasic

[VB6 Programming]

BETA releases of the twinBASIC programming IDE are available for download here...

https://github.com/twinbasic/twinbasic/releases

To install,

• Click on "Assets" for the latest release
• Download and Extract the ZIP file into a local folder
• Then run the twinBASIC.exe from that local folder

Information about current BETA releases of twinBASIC is now posted here...
https://www.vbforums.com/showthread....-Beta-releases


Further details 'How to install':
https://nolongerset.com/how-to-install-twinbasic/

See also:
https://twinbasic.com/
https://twinbasic.com/preview.html

[Niya]

Out of curiosity... could you give an example for such a "need"?

I can imagine accessing SIMD being a need only addressable by embedded assembly. .Net gets around this by providing SIMD specific classes that the JIT recognizes and generates SIMD instructions for. Other compilers(I believe some versions of GCC can do this) use advanced heuristics to identify parallelizable coding patterns for which it then generates SIMD instructions. Both these solutions are a quite involved so I can't imagine Wayne would attend to this need any time soon. However, the ability to write embedded assembly is probably something he could do in an afternoon.

In any case, it would be a temporary solution. He will at some point have to address it in a high level way for TwinBASIC to be competitive with other modern high level languages.

[fafalone]

Out of curiosity... could you give an example for such a "need"?

Olaf

Not saying it's a technical issue, but rather an issue of not implementing every conceivable low level routine somebody might want to implement. Or are we really playing a game of "why would anyone ever want to do something in asm"?

[Niya]

I just remembered something, didn't you write a kernel mode driver once in TwinBASIC fafalone? That right there by itself is a very compelling reason for embedded assembly. Low level kernel mode drivers is one of the few remaining domains of programming where assembly language is still quite viable. If others want pursue such projects in TwinBASIC, they will find this very attractive.

[xiaoyao]

Maybe you can compile dynamically with JS code in the future, and you can get the compiled code.

You may not know that the whole IDe is actually a web page. If you want to change it into other languages, open it with Notepad and replace it. It will become a Chinese version or a French version.

Just now someone was asking, how to read the control attributes on the Liuchuan form? Perfect explanation for him.
twinbasic,Yes, he must have solved them technically.
In terms of cracking vb6 compilation principles, the Russians may have the most say, and they have super-high black technology.

But if he can't make a profit from it, he won't do it.
Perhaps only this software can do the best in this respect.

In fact, the future trend is the web version of IDe development tools, writing code debugging.
Visual Forms Designer.After all, office has now become a web version.Do you think he can still use VBA? You can only use JS in the future.

抛弃vb6,vb.net,He'll be dumping the VBA next.

[xiaoyao]

Now on Microsoft Cloud Server and some other websites, they provide online debugging capabilities for many programming languages, and you may only need to pay $100 a month.

They bought them for billions of dollars.

However, none of them currently support visual tables, and the single design can only return results or run python code in time like an online run.

[xiaoyao]

As long as you want to do it, it is not a problem to crack the compilation principle of VB6, implement almost 100% of the functions, and then go beyond it and add 50% to 200% of the functions.

That's what Delphi did back in the day. c++builder
c# vs java,javascript,vbscript。ie，chrome。 Technically, it can be imitated.But it costs a lot, maybe tens of millions of dollars, maybe hundreds of millions of dollars.Maybe just a million dollars.

I don't know if the engineers who developed VB are still alive. Let them do it. Can we redevelop an IDe like VB6.

[fafalone]

I just remembered something, didn't you write a kernel mode driver once in TwinBASIC fafalone? That right there by itself is a very compelling reason for embedded assembly. Low level kernel mode drivers is one of the few remaining domains of programming where assembly language is still quite viable. If others want pursue such projects in TwinBASIC, they will find this very attractive.

Yup I did, and indeed one of the issues that has come up as I've moved onto to drivers that actually do something, is there's a number of common compiler intrinsics that emit asm. One common one is atomic operations... in user mode, these are used for multithreading too, and I solved the lack of those under x64 (because Windows exports them in 32bit versions but not 64bit) by making a C++ DLL to export the intrinsics (see here). But that's not a good solution and it relies on outside modules in other languages. So is tB really going to expose a direct language feature for this rare but important use case? Sure under the hood the functionality might be there somewhere for multithreading, likely limited compared to the full range needed for other tasks, but independently, and in a form that doesn't use any external APIs (because those are a no-go in drivers)?

Here's another example: Strings functions. Do we expect tB to reimplement all the string functions in high performance asm versions not using any external APIs? Though I'd like it support inline C too which would be preferable for implementing these.

e.g. StrRev

	public	_strrev
_strrev proc \
	uses edi esi, \
	string:ptr byte

	mov	edi,[string]	; di = string
	mov	edx,edi 	; dx=pointer to string; save return value

	mov	esi,edi 	; si=pointer to string
	xor	eax,eax 	; search value (null)
	or	ecx,-1		; cx = -1
repne	scasb			; find null
	cmp	ecx,-2		; is string empty? (if offset value is 0, the
	je	short done	; cmp below will not catch it and we'll hang).

	sub	edi,2		; string is not empty, move di pointer back
				; di points to last non-null byte

lupe:
	cmp	esi,edi 	; see if pointers have crossed yet
	jae	short done	; exit when pointers meet (or cross)

	mov	ah,[esi]	; get front byte...
	mov	al,[edi]	;   and end byte
	mov	[esi],al	; put end byte in front...
	mov	[edi],ah	;   and front byte at end
	add	esi,1		; front moves up...
	sub	edi,1		;   and end moves down
	jmp	short lupe	; keep switching bytes

done:
	mov	eax,edx 	; return value: string addr

ifdef	_STDCALL_
	ret	DPSIZE		; _stdcall return
else
	ret			; _cdecl return
endif

_strrev endp
	end

[Niya]

One common one is atomic operations... in user mode, these are used for multithreading too, and I solved the lack of those under x64 (because Windows exports them in 32bit versions but not 64bit) by making a C++ DLL to export the intrinsics (see here). But that's not a good solution and it relies on outside modules in other languages. So is tB really going to expose a direct language feature for this rare but important use case? Sure under the hood the functionality might be there somewhere for multithreading, likely limited compared to the full range needed for other tasks, but independently, and in a form that doesn't use any external APIs (because those are a no-go in drivers)?

Yea, embedded assembly would have definitely made things a lot easier here. For example, this is all it takes to implement InterlockedIncrement in assembly:-

use32			;32 bit code

mov eax, [esp + 4]	;Load the first parameter into EAX.
			;This value is a pointer to a 32 bit integer

lock inc DWORD [eax]	;Perform an atomic increment of 32 bit integer
			;pointed to by the pointer in EAX

ret 4			;Clear the stack

It's so simple, I didn't even bother to setup a proper stack frame which has the nice side of removing some of the typical function call overhead. The above works in VB6 with Trick's Add-In using this signature:-

Sub ASMInterlockedIncrement(ByRef value As Long)

The 64 bit version of that would be even simpler since the pointer would be passed in a register instead of on the stack so you'd only need 2 lines of assembly instead of 3.

It would have made your life a lot easier if you could have done this in TwinBASIC instead of having to go through the trouble you did with the DLLs.

So yea, all in all, I'd say you have a solid argument for the inclusion of inline assembly in TwinBASIC.

Here's another example: Strings functions. Do we expect tB to reimplement all the string functions in high performance asm versions not using any external APIs?

Yep. This is a good point.

Though I'd like it support inline C too which would be preferable for implementing these.

Actually what you really want here is first class pointer support. The power of C doesn't come from the syntax, a lot of it comes from the fact that pointers are first class citizens in the language. However, I'd strongly advise against this because while such a thing will make TwinBASIC a lot more powerful, you will open up the language to a lot of the ugliness of C, mainly the innumerably amount of undefined behaviors that comes with the language. This is a deep rabbit hole that I don't think BASIC programmers would want to navigate.

[fafalone]

There's been some discussion about improving pointer support (one of them here)...

Here's my position on this:

Pointers are *already* a reality of VBx. tB is not looking to change the fact that VBx programs interact directly with low level Windows APIs rather than high level frameworks. So the best course of action here is to make them more friendly, make code using them easier to understand. The existing situation is a lot of work is done with CopyMemory calls and pointer math (with few people bothering to make that large-address safe)... these are more difficult to navigate than true first class pointer support would be. People looking to completely cut themselves off from the lower levels won't want to move off .NET or other framework-heavy languages anyway.

For example, UDTs with pointers to other UDTs...

Type Foo
a As Long
b As Long
End Type

Type Bar
f As LongPtr 'PFOO
End Type


If you receive a Bar UDT, and want it's FOO type, you have to do

Dim tFoo As Foo
CopyMemory tFoo, ByVal tBar.f, LenB(tFoo)

Now imagine a world of first class pointer support?

Type Foo
a As Long
b As Long
End Type

Type Bar
f As PointerTo Foo
End Type


Now you need no CopyMemory at all and it's automatically dereferenced when you need it. This is by far the more friendly option in a world where pointers are unavoidable, and so long as nearly every app we all make uses pointers with the Win32 API, that's the one we're living in.

[Niya]

I hear you. However, I'm surprised nobody in that GitHub discussion talked about this. You see, one of the strong points of BASIC since the beginning of time is that the language is well behaved. You could call it a safe language. What do I mean by this? Well consider what happens when you try to read pass the end of an array, you get a "subscript out of range" error. If you try to call a method on an object variable with a null reference, you get an "object variable not set" error. The language gives you guarantees about what would happen under different circumstances. This makes the language very safe and easy to debug.

When you introduce pointers, you are essentially bypassing a lot of abstractions that make the language safe and well behaved. You introduce undefined behaviors into the language. For example, there is no defined behavior for accessing an invalid pointer. It could do nothing today, crash your program tomorrow or erase your hard drive the next day. There is never a guarantee about what would happen. This is very very un-BASIC-like and a source of the most frustrating bugs in languages like C. It also makes it much easier to write exploitable code. Buffer overflow attacks become more likely to succeed without the protection of automatic bounds checking.

Now I know what you might be thinking, which is that you could already walk this path through VarPtr/RtlMoveMemory/PutMem etc. However, these are simply functions. They do not change the fundamental nature of BASIC as a safe, well behaved language. You have to opt into this otherwise you could never find yourself in a situation where a certain operation doesn't have clearly defined results under all conditions.

Here's the long and short of it. I'll never say TwinBASIC shouldn't have pointers. You are correct, they will make the language more powerful and add a lot of convenience but it will also undermine one of the very fundamental parts of BASIC's identity. The real question, will you guys be able to live with that.

.Net has the ability to handle pointers but it's deliberately disallowed in VB.Net. C# allows them and even then, they discourage it's use by forcing you to have to explicitly opt-in to using them. So even Microsoft is weary of pointers being a first class citizen in a language. You guys need to really put some thought into what having first class pointer support in TwinBASIC would really mean for the language.

[fafalone]

I don't see how there's any 'opt in' or separation at all when I can't even remember the last time I saw a non-trivial VB program that wasn't calling into APIs. The the purest sense you'd still be opting in, in the sense that nothing is making you use any enhanced pointer functionality, and the language supports ways to avoid it for all the most common situations. We could consider taking the VB6 road of "This is undocumented and unsupported"... like I don't know how official the current situation is with being able to substitute LongPtr for a UDT or As Any.

Public Sub Foo(p As Bar) can be called with Dim ptr As LongPtr: Foo ptr

You make fine points but none of them address the reality that there is no avoiding raw pointers in VBx/tB, for any program of meaningful complexity. Are we saved from buffer overruns and accessing invalid pointers by requiring CopyMemory and manual pointer math? No, in fact I think we open up a *larger* attack surface. Unless there's a world where the use of pointers isn't needed (or at least, only rarely needed), making them friendlier is the only option.

.NET can get away with those restrictions because of the massive, massive frameworks that dramatically limit the need as they wrap nearly the entire API surface. But that's not the road tB is taking, nor the road I'd want it to take. There's a reason so many of us haven't abandoned VB6 for .NET. So given that pointer use will remain pervasive, it's better to have first class support.

[PlausiblyDamp]

I don't see how there's any 'opt in' or separation at all when I can't even remember the last time I saw a non-trivial VB program that wasn't calling into APIs. The the purest sense you'd still be opting in, in the sense that nothing is making you use any enhanced pointer functionality, and the language supports ways to avoid it for all the most common situations. We could consider taking the VB6 road of "This is undocumented and unsupported"... like I don't know how official the current situation is with being able to substitute LongPtr for a UDT or As Any.

Public Sub Foo(p As Bar) can be called with Dim ptr As LongPtr: Foo ptr

You make fine points but none of them address the reality that there is no avoiding raw pointers in VBx/tB, for any program of meaningful complexity. Are we saved from buffer overruns and accessing invalid pointers by requiring CopyMemory and manual pointer math? No, in fact I think we open up a *larger* attack surface. Unless there's a world where the use of pointers isn't needed (or at least, only rarely needed), making them friendlier is the only option.

.NET can get away with those restrictions because of the massive, massive frameworks that dramatically limit the need as they wrap nearly the entire API surface. But that's not the road tB is taking, nor the road I'd want it to take. There's a reason so many of us haven't abandoned VB6 for .NET. So given that pointer use will remain pervasive, it's better to have first class support.

I think yourself and Niya are approaching this from different viewpoints.... If you are used to VB6 then having to use APIs to overcome a lot of the limitations is completely normal, plus the language makes it hard to pass things to the APIs as well. CopyMemory, GetMem, PutMem, etc. are required to do a lot of things. I suspect Niya is approaching this from a C# / VB.Net point of view - the language provides easier ways of calling APIs that doesn't require your code to be full of pointers (or in the case of https://learn.microsoft.com/en-us/do...rce-generation this low level code is generated for you).

I think if you are constantly having to use raw memory access and pointers in a a high level language like Basic then something is wrong - either the language is not sufficiently high level enough, or you are using the wrong language for the job. I am willing to admit there will be occasions raw memory access is needed, but these shouldn't be the common case in a high level language. Ideally the environment should take care of as much of this as possible.

[xiaoyao]

Why am I called the Father of Visual Basic?
http://bbs.vbstreets.ru/viewtopic.php?f=27&t=56550

Ruby + EB = Visual Basic
https://blog.csdn.net/xiaoyao961/art...ails/130974374
http://bbs.vbstreets.ru/viewtopic.php?f=101&t=56551

VBStreets Conference • Topic View - § 12. How many lines of code and files are there in VB's own source code?
http://bbs.vbstreets.ru/viewtopic.php?f=101&t=56633

My First BillG Review – Joel on Software
https://www.joelonsoftware.com/2006/...-billg-review/

joel convinced the BASIC team that the Excel team needed something similar to BASIC for Excel. At the same time, he tried to insist that four features should be added to the language:
Add a Variant variable that can store any other type of value, otherwise you cannot store the value of the Excel table cell in the variable (at least without resorting to Select Case).
Late binding was added (via IDispatch) because the original Silver architecture required a deep understanding of the type system, which Excel macro writers didn't want to know.
Add the For Each construct borrowed from csh.
Add a With... End With construction, borrowed from Pascal.

Joel then sat down and wrote a specification for the future language, Excel Basic, about 500 pages long, which he sent to Bill Gates for review/verification

[xiaoyao]

Twinbasic gives us a lot of imagination for a similar successor to VB6, and the company's development capabilities are so strong that if it had started 20 years ago, it would have captivated developers around the world like PYTHON did.
Maybe it will become a public company, maybe it will become a great software product like DELPHI or VSCODE.

Because the IDE does not provide these interfaces, or because some of the information is intentionally not public, we have the option of using assembly code to read some unknown memory.
Unless the IDE provides a development interface such as add in, there is also an SDK API that allows us to participate in adding functionality to the IDE.

[fafalone]

I think yourself and Niya are approaching this from different viewpoints.... If you are used to VB6 then having to use APIs to overcome a lot of the limitations is completely normal, plus the language makes it hard to pass things to the APIs as well. CopyMemory, GetMem, PutMem, etc. are required to do a lot of things. I suspect Niya is approaching this from a C# / VB.Net point of view - the language provides easier ways of calling APIs that doesn't require your code to be full of pointers (or in the case of https://learn.microsoft.com/en-us/do...rce-generation this low level code is generated for you).

I think if you are constantly having to use raw memory access and pointers in a a high level language like Basic then something is wrong - either the language is not sufficiently high level enough, or you are using the wrong language for the job. I am willing to admit there will be occasions raw memory access is needed, but these shouldn't be the common case in a high level language. Ideally the environment should take care of as much of this as possible.

That's the idea behind turning VB into .NET.

The bottom line is tB is not meant to be another .NET. There's not going to be a framework wrapping the entire Win32 API in safe pointer using classes or wholesale replacing it. Fans of the .NET approach can lament that all they want, but it's simply not a good argument to say "Well, if tB was a .NET clone, low level feature x wouldn't be needed, therefore it's not needed." which seems to be what you're getting at here.

[xiaoyao]

But I have a question, and it may not be about that. But I don't want to put it in a separate topic. Plus, there are a lot of smart minds out there.
A lot of good programmers on the forums really like VB6 and would like to see MS develop it further - such as VBx64. But, my friends, what is stopping you from making this idea happen on your own? Some of the code has been implemented by MS itself in VBA for x64 MS Office. I know it won't be easy, but, as they say, "The road will overcome the walker." A good example is the hobbyist QB64. Sadly QB64 is not as good as VB, but it does support 64-bit, a lot!
Do you think you can handle such a project?

[Niya]

I suspect Niya is approaching this from a C# / VB.Net point of view - the language provides easier ways of calling APIs that doesn't require your code to be full of pointers (or in the case of https://learn.microsoft.com/en-us/do...rce-generation this low level code is generated for you).

Kind of but I'm actually not so much thinking of specific languages but I'm getting at something more intangible and fundamental about language design. It's very clear in my mind but extremely difficulty to describe to someone else. Let me see if I can add a bit of clarity. Consider the following VB6 code:-

    Dim sigature() As Byte
    
    ReDim signature(0 To 1)
    
    signature(0) = 119
    signature(1) = 116
    signature(2) = 102

That code has a bug in it that's easy to miss. If you ran that a hundred times, it will bomb out with a "subscript out of range" error every time. Run it a billion times, it crashes every single time. If the above code is on a hot-path, it's practically guaranteed that you will never ship production code with that bug in it because the runtime would have alerted you to the bug long before it's ready to ship. Now consider the same thing written in C:-

    uint8_t *signature = (uint8_t*)malloc(2 * sizeof(uint8_t)); // bug: should be 3

    signature[0] = 119;
    signature[1] = 116;
    signature[2] = 102; // bug: writing past the end of allocated memory
}

In C, arrays are just another way of using pointers. It's a more friendly syntax in certain situations but it doesn't change the fact that writing to an invalid pointer cannot be meaningfully defined. What this means is you could run that code 100 times or a billion times and nothing happens but on the 101st or billionth + 1 run, it bombs with an access violation error, but even the type of error isn't guaranteed. Even if this code is in a hot path, you could still end up shipping the software with this bug because you were never altered to it during development.

You see when I think of BASIC, whether it's VB6, VB.Net or TwinBASIC, I think of the language itself as a contract between creators of the language and the developers using it. The language devs are saying to us, the users of the language "Hey, if you use our language, we guarantee you that no features in this language will produce undefined behaviors but if you go outside of that, do so at your own risk. We make no guarantees then". We have to opt-in to writing unsafe code ourselves. If we avoid VarPtr and all that comes with it, the language guarantees that nothing we could do would ever have an undefined outcome. This has always been the contract between the language of BASIC and the developers using it. Introducing first class pointers would change this age old unspoken contract and I can imagine it upsetting a lot of BASIC purists. This is really about the very identity of BASIC here.

Now personally, I have no problems with first class pointer support in a BASIC variant for all the reasons fafalone stated, I think it's a great idea. Objectively speaking however, even I recognize this changes something very fundamental about the BASIC language and it tickles me somewhere deep in my soul. I doubt we have really considered all possible implications of such a drastic change.

[Shaggy Hiker]

But I have a question, and it may not be about that. But I don't want to put it in a separate topic. Plus, there are a lot of smart minds out there.
A lot of good programmers on the forums really like VB6 and would like to see MS develop it further - such as VBx64. But, my friends, what is stopping you from making this idea happen on your own? Some of the code has been implemented by MS itself in VBA for x64 MS Office. I know it won't be easy, but, as they say, "The road will overcome the walker." A good example is the hobbyist QB64. Sadly QB64 is not as good as VB, but it does support 64-bit, a lot!
Do you think you can handle such a project?

That question has been asked roughly every other year since 2002. The rate of asking that question does appear to have diminished somewhat, of late, and that might be because TB is the (or at least an) embodiment of the answer. It can be done, it is being done, it just isn't easy...as 300+ beta releases and counting can attest to.

[xiaoyao]

freebasic is qb64?it's support x64,gcc

CommonControls (Replacement of the MS common controls) - Page 87-VBForums
https://www.vbforums.com/showthread....ntrols)/page87

https://www.vbforums.com/showthread....ontrol)/page22

for this,if it's can run no errors in twinbasic,That represents a real success, even converted to 64-bit controls. As far as I know custom controls will be the hardest to import into TWINBASIC from VB6.

But something might be easier than parsing the data in the *.frx file, since all properties of the custom control are read as if it were an INI file. However, the highly complex design method will make it difficult for TWINBASIC to be successfully imported, and perhaps TWinbasic has perfectly realized it.

I used VFB (VISUAL freebasic ide) to load the DLL in the resource file written in VB6 in the memory and call the conversion successfully. It took several hours. It took me half a month to convert to 64-bit later, it was too difficult. Various data type conversions, and unknown errors.
So at that time, it was estimated that it would be difficult to upgrade VB6 to 64-bit. Microsoft spent all its time on wars with JAVA, and VB6 had long been abandoned.
The 64-bit VBA is because it is bound to the paid product OFFICE, cad (vba sdk), so they have upgraded it.

[yereverluvinuncleber]

Is that AI junk? - or just human-translated gobbledegook? What does he want? most of the time, I have no idea what the point is. Am I the only one who does not understand?

There is this 'too many posts within 1 minute' rule here on the forum. Could we add a 'one per day' rule for certain accounts - specifically, xiao? Or perhaps instead we could have a full-time moderator employed just to extract the pertinent and understandable bits from xiao's posts?

[Niya]

I think it's a real person that is using a very ineffective Chinese-to-English translator. When you read his posts carefully enough, it borders ever so slightly on making sense. There are also a few posts he has made that are very coherent but those are more rare.

[fafalone]

But I have a question, and it may not be about that. But I don't want to put it in a separate topic. Plus, there are a lot of smart minds out there.
A lot of good programmers on the forums really like VB6 and would like to see MS develop it further - such as VBx64. But, my friends, what is stopping you from making this idea happen on your own? Some of the code has been implemented by MS itself in VBA for x64 MS Office. I know it won't be easy, but, as they say, "The road will overcome the walker." A good example is the hobbyist QB64. Sadly QB64 is not as good as VB, but it does support 64-bit, a lot!
Do you think you can handle such a project?

The vast majority of programmers can't handle such a project, no, and among the few who can, nobody has shown the will to dedicate the time and effort to getting it done on a reasonable timescale until Wayne with twinBASIC. It's a *huge* undertaking you'd need to treat as a second job.

But twinBASIC supports x64, and will reach full compatibility before any alternative, by at least several years, if not a decade or more. It's the best (and only) compatible successor to VB6, so if you want that, it makes sense to support tB rather than post vague wishes more people would attempt such a thing.

[fafalone]

I think it's a real person that is using a very ineffective Chinese-to-English translator. When you read his posts carefully enough, it borders ever so slightly on making sense. There are also a few posts he has made that are very coherent but those are more rare.

I'm more patient than usual with him because he has posted a bunch of interesting links; doesn't seem to be anything malicious just like you say, someone who needs a better translator. Google is blocked in China so that may be related.

[Niya]

doesn't seem to be anything malicious

Yea. Annoying, sure but not malicious or offensive.

Google is blocked in China so that may be related.

I was thinking the same thing.

[xiaoyao]

i say,make 64 bit software IDE IS Very difficult,Thanks to twinbasic for the great invention and creative design。

if you read by Google Translate, it's probably easier to understand. If you look at the English words, you can't understand them.

I also found a lot of VB6 technical articles and code on Russian websites, which did not affect my reading because I use all translation software.

[Schmidt]

I think, there's a human behind the account (with an "attention-seeking psychosis") -
but most of the time, what we get is "badly mangled bot-output" which is not really staying in context
(of the onging discussion, like the output above my posting).

There's also never any citation-blocks, to make it more clear what the "spam" is trying to be "related to"...

It's (in my case) not only "annoying" - it's causing nausea -
(because my brain cannot detect any sense or intention behind this mess).

Olaf

[vbrad]

Is that AI junk? - or just human-translated gobbledegook? What does he want? most of the time, I have no idea what the point is. Am I the only one who does not understand?

There is this 'too many posts within 1 minute' rule here on the forum. Could we add a 'one per day' rule for certain accounts - specifically, xiao? Or perhaps instead we could have a full-time moderator employed just to extract the pertinent and understandable bits from xiao's posts?

I suspect that it's those of us who are native English speakers who struggle the most with posts that are in "broken" English.
I say this because there is another English language forum that I frequent where the majority of posters are non-native speakers of the language. Everyone there seems to get on fine while I feel like I'm the slowest to understand.
Now it's very possible that they are all smarter than me but it's also possible that they are more prepared to "solve" an English sentence for meaning and can accept a rough and ready result while I have a "need" for perfection in English.

[xiaoyao]

Maybe you don't know the problem I have.
Rc6 loading webview without registration

I need to load three DLLs.msvbvm60.dll,cariosqlite.dll,rc6.dll,
If it is not loaded in this order, it will be wrong.
If you add directcom.DLL ，That's a total of four DLLs.

So I was wondering if there was a way to load it all at once?

[Niya]

which is not really staying in context
(of the onging discussion, like the output above my posting).

There's also never any citation-blocks, to make it more clear what the "spam" is trying to be "related to"...

(because my brain cannot detect any sense or intention behind this mess).

I had a couple thoughts about this. One theory is that he is trying to reach some kind of post-per-day quota. I can barely keep up with 3 completely unrelated discussions at the same time. That's a lot of context to remember but he is often posting in like a dozen threads at the same time. If he has some kind of quota to meet a lot of it will be out of context. It's impossible to remember the context of a dozen different discussions at the same time. It's easier to just spam out of context stuff.

Another theory I have is that there is some kind of cultural element at play. Perhaps Chinese etiquette is different from western etiquette. Perhaps this kind of wanton spamming is acceptable forum etiquette among non-westernized Chinese people.

[Shaggy Hiker]

I suspect that it's those of us who are native English speakers who struggle the most with posts that are in "broken" English.
I say this because there is another English language forum that I frequent where the majority of posters are non-native speakers of the language. Everyone there seems to get on fine while I feel like I'm the slowest to understand.
Now it's very possible that they are all smarter than me but it's also possible that they are more prepared to "solve" an English sentence for meaning and can accept a rough and ready result while I have a "need" for perfection in English.

I totally agree. Those who have to use translators seem to have an easier time with English passed through a translator, even on here.

xiaoyao is as real as anyone else on here (some of you, admittedly, are kind of surreal), their message just gets mangled by a translator. Of course, we shouldn't be so complacent. A person can speak in one language, have it turned into a second language pretty much automatically in near real-time, and people are complaining because it doesn't do so well enough. Most of you lived the bulk of your lives without the ability to do that at all.

[SearchingDataOnly]

xiaoyao's thinking is so jumpy that even native speakers of Chinese sometimes have difficulty understanding him. But I don't think he's malicious, but he does need to pay attention to some forum rules and improve his own etiquette, especially not to hijack other people's threads.

I also use language-translators a lot, which can greatly shorten my reading time, but these translators keep my English skills declining.

[xiaoyao]

You always talk about junk mail. In fact, in China, mail has not been used for more than 10 years.
You might get an email every time someone responds.
I'm just responding to the technology I'm working on, and I don't understand or respond to anything irrelevant to me.

For example, recently I have been working on file drag and drop, string drag and drop technology, JS9, Google V8 Engine, WEBVIEW2, etc.
Because I lost a lot of VB source code before, so once I see good controls or source fragments want to download collections.
Some time ago also to the Russian website to find a lot of transparent text box, list box code.

www.pudn.com This site has a lot of VB6 source code, as well as many other languages. WWW.VBGOOD.COM before there are a lot of good source, but also closed.
The VB6 source community was largely shut down.

[Schmidt]

I'm just responding to the technology I'm working on, and I don't understand or respond to anything irrelevant to me.

And that's exactly, "what's wrong with you"...
(and what's inducing the nausea).

It's nearly all "out of context" (to anything or anyone else)...

You really seem to "respond" to your own thoughts only (and that, all over the place here) -
without giving any thoughts about:
- the "discussion-thread" you are currently in
- or what other participants in these threads have asked you (when trying to "clarify some context").

That's as ill-mannered (or just "ill") as it gets -
and no, I'm not talking about "a few missing english words" or "bad grammar" -
it's this "totally out of context", self-centered "jumpiness" which is giving this "ill" impression.

Olaf

[fafalone]

I keep finding really interesting looking code on Chinese sites, for APIs I can't find used in VB anywhere else, or sometimes even in other languages... but every time, I've gone through the arduous task of signup which is hard because there's no English version and a lot of important text is images or on popups I can't put through an automatic translator. But I've successfully registered on a few of them... only to find you need "points" to be able to download anything. It's infuriating.

[2kaud]

Introducing first class pointers would change this age old unspoken contract and I can imagine it upsetting a lot of BASIC purists

That depends upon the memory management used. It's perfectly possible to have a memory management system that verifies that all memory access is valid so that dereferencing an invalid first class pointer will cause a run-time error. Obviously this will slow down the run-time which is why it isn't done with c/c++ (which aim for the fastest possible code when compiled in release mode and hence assumes the programmer knows what they are doing).

[Niya]

@xiaoyao

I have to second what Olaf says. It's very difficult to understand you because your posts lack context. It seems you ignore all forum etiquette and just post whatever is on your mind into what every thread happens to be open on your browser at that moment. You have to understand, that is a very ineffective form of communication. Conversations have context which is derived from the topic of the thread and from the responses of previous posters in the thread. You can't just post stuff at random into any thread. It confuses the hell out of us and even drives some of us crazy.

[Niya]

That depends upon the memory management used. It's perfectly possible to have a memory management system that verifies that all memory access is valid so that dereferencing an invalid first class pointer will cause a run-time error. Obviously this will slow down the run-time which is why it isn't done with c/c++ (which aim for the fastest possible code when compiled in release mode and hence assumes the programmer knows what they are doing).

Yes this is very much true. This is EXACTLY why Rust exists. The borrow checker in Rust and all that comes with it is their way of removing undefined behavior from memory operations without a performance penalty. If I'm being perfectly honest, I this Rust's approach is far better suited to BASIC than raw C-like pointers. It's very much in line with BASIC's tendencies towards being a safe language.

[xiaoyao]

talk about:twinbasic

INDEPENDENTCANDAULES'S EXPERIENCE
I was able to convert 250,000 line RED program over to TwinBasic with no problem. The code runs about 4 times faster than in RED. And when I upgrade to the Commercial version which will have optimized code it will run even faster. Compiles to .exe are lightning fast too, Less than a second in TwinBasic versus 20 minutes to compile in RED.

TwinBasic is turning into VB6.next. the development process is insane, with new features and bug fixes appearing daily. Best of all it aims to be 100% compatible with VB6...

[VB6 Programming]

talk about:twinbasic

INDEPENDENTCANDAULES'S EXPERIENCE
I was able to convert 250,000 line RED program over to TwinBasic with no problem. The code runs about 4 times faster than in RED. And when I upgrade to the Commercial version which will have optimized code it will run even faster. Compiles to .exe are lightning fast too, Less than a second in TwinBasic versus 20 minutes to compile in RED.

That is a quote from https://www.slant.co/topics/9807/~ba...g-languages#15 of user 'INDEPENDENTCANDAULES' experience with twinBASIC, compared to the RED programming language.

and from user 'EXCEPTIONALHOTHR' this quote...

TwinBasic is turning into VB6.next. the development process is insane, with new features and bug fixes appearing daily. Best of all it aims to be 100% compatible with VB6...

Well spotted xiaoyao, two very nice quotes about twinBASIC programming.