-
Mar 1st, 2014, 08:41 AM
#81
Re: VB Classic (A True VB 7.0)
 Originally Posted by axisdj
/ Schmidt finds time and money to complete his project
If Olaf felt like setting up a kickstarter to fund the first stage of the project we could use it gauge the actual level of support. It would need a site and some publicity though. Not pushing you toward this - just stating that I feel that it is a valid direction to go in if you needed something to push you to complete the work you have already started.
-
Mar 1st, 2014, 12:46 PM
#82
Re: VB Classic (A True VB 7.0)
 Originally Posted by yogiyang
As the project is still on drawing board I would suggest to have look as a similar compiler B++. It is on sourceforge web site.
It seems to be abounded but it can be a starting point for this new project. It is basically an emitter which will generate C++ code in back end and compile it with either MingW or BorlandC++ (free compiler).
In my plan to accomplish platform-independence (as well as 64Bit-support),
I wanted to incorporate a "plain C"-emitter. That's mainly because I see
the (InProcess working) tinycc-compiler-library playing the main-role in a
PCode-like engine, which is working behind the scenes within the new IDE
(to allow for easy debugging, and Edit&Continue).
The "real compilation" would then allow to target either MingW for faster
and optimized "native-compiled binaries" - but alternatively also the tinycc again,
which allows for slower executing, but smaller "PCode-like" binaries then.
So the new IDE will have (as before) two different compilers - a very fast compiling
one (tinycc, about factor 10 faster than GCC), and MingW which has not the same
throughput in "processed lines of C-Code per second" as the tinyCC, but will end
up with higher-optimized, faster executing binaries.
Neither tinycc nor MingW-dependencies will be required to "ship" with
your compiled binaries finally - but I assume this is clear.
 Originally Posted by yogiyang
While we are at it.
I would like to know if it would possible to use LLVM for targeting multiple OSs?
It is certainly possible - mjohnlq already suggested that here in this thread - and there's
also already the beginning of an LLVM-based compiler as mentioned in the posting here:
http://www.vbforums.com/showthread.p...=1#post4492531
So, it is doable - but at the moment I'd like to stick with my plan for a plain-C emitter
(the same emitted sources usable by both, the tinycc-engine as well as the MingW-C-compiler).
Since this would mean a very lean deployment of the new IDE-project (when in the first
implementations only the tinycc is acting as the compiler for both: IDE-Debug-runs as well
as final Binary-compilation).
The MingW-compiler (which has quite a large deployment-size > 10MB) could be installed as
an optional engine (to be shelled from within the IDE whereas tinycc supports both - a nearly
GCC-compatible commandline-interface - but also the already mentioned libtcc.dll).
tinycc is really impressive and comes since release 0.9.26 in both, a 64Bit- and a 32Bit-version
(able to compile the appropriate 32bit or 64bit binaries also for windows). Deployment-size -
about factor 30! smaller than MingW (only about 386KByte).
For those who want to play around with the little engine - here's the main-page:
http://bellard.org/tcc/
And here the Download-page (version 0.9.26 for Windows is what you want).
http://download.savannah.gnu.org/releases/tinycc/
Olaf
Last edited by Schmidt; Mar 1st, 2014 at 10:04 PM.
-
Mar 3rd, 2014, 06:19 AM
#83
Addicted Member
Re: VB Classic (A True VB 7.0)
 Originally Posted by Schmidt
In my plan to accomplish platform-independence (as well as 64Bit-support),
I wanted to incorporate a "plain C"-emitter. That's mainly because I see
the (InProcess working) tinycc-compiler-library playing the main-role in a
PCode-like engine, which is working behind the scenes within the new IDE
(to allow for easy debugging, and Edit&Continue).
This would mean that we will not be able to debug code interactively like is currently possible in VB6.
Would it be possible to implement an interpreter and well as code emitter?
Say if possible adopt Gold Parser (again this project is 100% in VB) to interpreting and related stuff. (http://goldparser.org/)
Just my thoughts.
-
Mar 3rd, 2014, 03:09 PM
#84
Re: VB Classic (A True VB 7.0)
 Originally Posted by yogiyang
This would mean that we will not be able to debug code interactively like is currently possible in VB6.
Quite the opposite - the tinycc-Compiler will *allow* (due to its InProcess-availability as a Dll and its superfast compile-speed) fast Upstart-Times and a "true Interpreter-like debugging" (as well as Edit&Continue), all due to the ability of the tinyCC-dll, to add new compiled functions "on the fly" into an "already running scenario".
Just imagine the emitted C-Code as something like .NETs "intermediate code" - and the tinycc-Dll as a kind of "VM".
 Originally Posted by yogiyang
Would it be possible to implement an interpreter and well as code emitter?
The very same "emitted C-Code" will feed both - the Debugging-Process (then with the tinycc-dll as the C-Code-to-Binary-translator) - and in a true "binary-compile-run", the same C-Code gets translated into Windows PE-format (Exes or Dlls) by either the commandline-version of the tinyCC or the MingW-C-Compiler.
 Originally Posted by yogiyang
Say if possible adopt Gold Parser (again this project is 100% in VB) to interpreting and related stuff. ( http://goldparser.org/)
I know the page and the tool - but it's not needed.
A dedicated (handwritten) Parser is to about 90% complete (and speed-optimized) already.
Olaf
-
Mar 4th, 2014, 11:31 PM
#85
Addicted Member
Re: VB Classic (A True VB 7.0)
 Originally Posted by Schmidt
Quite the opposite - the tinycc-Compiler will *allow* (due to its InProcess-availability as a Dll and its superfast compile-speed) fast Upstart-Times and a "true Interpreter-like debugging" (as well as Edit&Continue), all due to the ability of the tinyCC-dll, to add new compiled functions "on the fly" into an "already running scenario".
Just imagine the emitted C-Code as something like .NETs "intermediate code" - and the tinycc-Dll as a kind of "VM".
But the debugging part will be in C language and not in Basic language right?
The possibilities of having TinyCC as a dll and using it is really great concept!
Just curious...
Will TinyCC be able to compile and run new unsaved project directly from memory as is currently possible in case VB6?
-
Mar 5th, 2014, 06:06 AM
#86
Re: VB Classic (A True VB 7.0)
 Originally Posted by yogiyang
But the debugging part will be in C language and not in Basic language right?
The problem that (after Binary-compilation) one can only attach normal Debuggers
(which in case of the GCC-Debugger would report only the somewhat renamed
C-Symbols then - and have no real relation anymore to the underlying line of
VB-Code, which produced a certain "C-Block"), is known.
But in VB we don't debug stuff in this fashion (with dedicated OutOfProcess-Debuggers)
... we do it directly in the same IDE-Process against "InMemory-VB(A)-PCode"...
 Originally Posted by yogiyang
The possibilities of having TinyCC as a dll and using it is really great concept!
Just curious...
Will TinyCC be able to compile and run new unsaved project directly from memory as is currently possible in case VB6?
Well, look at that here: 
Code:
Private Enum tccOutPutType
TCC_OUTPUT_MEMORY
TCC_OUTPUT_EXE
TCC_OUTPUT_DLL
TCC_OUTPUT_OBJ
TCC_OUTPUT_PREPROCESS
End Enum
So the latter one is True - and will be the base for a real "InIDE-Debugging" as we are
wont to - I can exchange Symbols and add (newly compiled) functions into a given
TCC-InMemory-State (whilst being in an IDE-DebugSession).
That, paired with a self-implemented Stack-Area-allocation will ensure "Interpreter-
like flexibility" - but will run faster than VBs current PCode.
I've compiled a VB-friendly stdcall-variant of the tcc-lib and (next few days) will
post a CodeBank- example for InMem-usage of this "Mini-VM" from within VB (at the
moment only acting as a kind of "C-Scripting-language" from within a VB-application then).
Olaf
Last edited by Schmidt; Mar 5th, 2014 at 06:13 AM.
-
Mar 5th, 2014, 08:45 AM
#87
Addicted Member
Re: VB Classic (A True VB 7.0)
 Originally Posted by Schmidt
I've compiled a VB-friendly stdcall-variant of the tcc-lib and (next few days) will
post a CodeBank- example for InMem-usage of this "Mini-VM" from within VB (at the
moment only acting as a kind of "C-Scripting-language" from within a VB-application then).
Wow that would be great! You are at it again!
Please don't get me wrong. But personally I have observed that we VB6 developers have been spoiled by VB6 IDE and are used to, you know setting a breakpoint and then running the code and when the IDE halts at the breakpoint we can manipulate/check values of variables, skip execution of a code lines, add new code lines, etc.
Lack of such interactive debugging feature will probably put off a conventional VB6 developer from adopting this new alternative.
Yogi Yang
-
Mar 6th, 2014, 04:20 PM
#88
Lively Member
Re: VB Classic (A True VB 7.0)
 Originally Posted by Schmidt
Cor Ligthert "terrorized" (toghether with a few cronies) the VBClassic mpvbgd-usenet-group for years.
And he's not at all good at the kind of "marketeering" he did then and there (although it's
much better than trying to talk with him about programming-topics, been there - done that).
Cor easily raises (involuntarily for the most part) ignorance to an art-form (to be fair, that's
partly because of his bad english skills)
So, in short: you can as well have a nice conversation with a brick-wall - at least the responses
you'll get then, will be consistent and non-contradictory.
Just forget about it.
Olaf
Megan has now been 'Unbanned'
Visual Studio team (Product Team, Microsoft) commented · March 06, 2014 18:59 · Flag as inappropriate
@MeganWinter, we looked into why you were banned on Forums and you should not have been. We have unbanned you and will further investigate internally as to why this ban took place. We are tremendously sorry and apologize for any inconvenience in which this has caused.
http://visualstudio.uservoice.com/fo...improved-versi
-
Mar 8th, 2014, 07:34 AM
#89
Re: VB Classic (A True VB 7.0)
Do you know I am quite astonished by the "head of steam" that seems to have been generated recently behind vb6 and by its loyal users. It seems that people (even windows users) are realising that the "Microsoft way" is not the only way and that there are actually other ways of doing things. I've been keeping my eyes open for a long while now and the "driving wind" behind alternatives is greater than it has ever been. Microsoft doesn't seem to be aware of it or perhaps it is blind to the outside world. Reversion to VB6 as a potential development platform for the future is one thing that I see emerging from Microsoft's Windows 8 car crash.
I reckon that if there is a chance for a VB6 alternative and a compatible and familiar IDE, then the time for it is has arrived or is arriving. There seems to be a lot of disillusionment from users with Microsoft's new NT6 GUI and also from Developers across the board regardless of which Microsoft technology they are familiar with. People are still loathe to drop the Windows environment they are familiar and productive with - but no longer expect Microsoft to provide it.
Last edited by yereverluvinuncleber; Mar 8th, 2014 at 07:37 AM.
Reason: completion
-
Mar 8th, 2014, 12:00 PM
#90
Re: VB Classic (A True VB 7.0)
Very well put, all of the above - and as for the "Steam" - I think the recent initiaitves coincide
with Steve Ballmers resignation (roughly from the time of its announcement) - but were
perhaps encouraged also due to MS's-backpaddling to the COM-environment, which is now
(again) the technical base for all those "new, clean and tiled" (ARM-capable) WinRT-developments.
Best tool for the WinRT-job? -> C++, using those new COM-interfaces in an unmanaged way.
So why not re-incarnate the classic C++/COM companion (VBClassic) again?
I think the above two reasons are the driving force behind these latest efforts of the VBClassic-
community - if there ever was a (slight) chance for a kind of resurrection - then now is the time
to make oneself heard, to possibly make it into the "my-strategic-decisions-to-make"-list of the
new CEO - there was always "strong forces behind VBA" (in the MS-Office-Group) which in the
meantime are perhaps aware again, that "VBAs big brother" wants to get back on board.
I personally see the chances for that as only 3-5% or so - but you never know -
and even if those numbers are quite small, the chances now are a bit better than they
were e.g. 3 years ago.
Olaf
Last edited by Schmidt; Mar 8th, 2014 at 12:10 PM.
-
Apr 2nd, 2014, 07:19 AM
#91
Re: VB Classic (A True VB 7.0)
What news? Is there any? A lack of information is always teasing...
Any news about this project would be gratefully accepted.
-
Apr 13th, 2014, 08:11 AM
#92
Re: VB Classic (A True VB 7.0)
Not directly related to this thread but interesting nonetheless, getting VB5/6 working on ReactOS (windows clone).
https://www.reactos.org/forum/viewtopic.php?f=4&t=13090
I will be posting there shortly when I have more time to test VB6 on ReactOS myself.
-
Jul 8th, 2014, 04:53 PM
#93
Re: VB Classic (A True VB 7.0)
Olaf,
Have you made any progress on your idea for a true VB7? We would all support you in your efforts, all projects need a driving force with the capability to actually do it.
-
Jul 17th, 2014, 02:30 PM
#94
Re: VB Classic (A True VB 7.0)
Admittedly, I didn't read through every entry above, but I did read through quite a few of them. This is a very interesting project, and it's something I've thought of myself, but there are a few problems here (possibly already discussed). First and foremost, this is a monumental project. It's certainly a bigger project than one or two people can carry off on their own. For it to have any chance at all, it'd have to compile my existing code with a minimum of effort. I thought I read that you were only going to do .bas and .cls modules. However, if you get .cls modules going, you're 99% of the way to getting .frm modules going as well. I can understand how .ctl modules may be a bit tricky, but you'd really need to get those going as well. However, I don't even see that as the major complexity you'll have to deal with. First and foremost, you'll need to be drop-dead compatible with the internal storage structure. This includes all the intrinsic variable types as well as the variant, objects, and collections. You'll have to handle both static and dynamic arrays. That includes strings being handled in Unicode but converted to ANSI when calling an API, writing to PropertyBag, or writing to disk. Arrays will have to be handled in precisely the same way too, as I have code that figures out whether a dynamic array is dimensioned or not withoiut error trapping. And variable length string garbage collectors are a rough chore for ANY language.
Bottom line, it's a HUGE job. I suppose you're doing it in some form of C with the hopes of going 64 bit. The problem is, anyone who's quite fluent in C is not going to be highly motivated to help you. Any chance you might have of getting this done would be to do it in VB6. That way, the hoard of extant VB6 programmers might come running to help. Yeah, you're boxing yourself in, but not that badly. New features could still be added and a 32bit program can write 64bit op-codes just fine. But it's just too big a job, and the existing VB6-IDE works just fine. In fact, it works so well that that's the reason we're having this discussion in the first place. Our only true hope is to try and pressure Microsoft to re-releasing VB6 (possibly with an upgrade) Here's a comment I posted elsewhere:
I've posted a list of recommendations for a VB7-COM product in many places through the years (64bit, easier unicode support, a Double-Long type variable, new Block/EndBlock keywords to reduce variable scope, ability to wrap OCX dependencies into the EXE along with manifest, and a few others). But I'd actually be happy with just a re-release of the VB6-IDE. Heck, they can put an "as is, no support" disclaimer on it if they like. Not only do they discontinue the product, but they've done everything in their power to kill backwards compatible licensing, declaring that a copy of .NET does not satisfy the VB6-IDE licensing requirements. It's as if publishers quit publishing the Harry Potter books (adamantly refusing to print more copies), but declared that they'd aggressively sue anyone who tried to make their own copies. I'm not talking about open-sourcing it, supporting it, or even providing any warranty of suitability for anything. Just sell my clients copies of it. I have several projects I've opened sourced in VB6 code and charge for consulting, adaptation, and customization. My clients would like the VB6-IDE so they can go forward with their own development teams, but they have to pay $2000+ for occasional copies of the VB6-IDE that appear on eBay. It's disrespectful, it's shameful, and it should be illegal. Heck, in my opinion, Microsoft would have been MUCH better off if they'd incorporated the VB6-IDE into their Windows OS (harking back to the days of their BASIC-OS). Imagine how addicted the world would be if they had a smart, easy-to-use programming language at their fingertips in Windows. They'd have half the world using it, and also clamoring for their OS to be ported onto every new platform (Tablets, Phones, etc) so that people could quickly write their own little VB6 style applications. Personally, I think that strategy could still work toward recovering their lost ground in the handheld markets if they would quit disrespecting the very people who have hung with them through thick and thin.
-
Nov 1st, 2014, 09:58 PM
#95
Lively Member
Re: VB Classic (A True VB 7.0)
Now that Linux isn't viewed as an enemy of Microsoft, you may want to give Gambas a look. (3.6.1 released today)
-
Nov 4th, 2014, 11:44 PM
#96
Addicted Member
Re: VB Classic (A True VB 7.0)
For those who may be interested there is another open source project called BCX that does just what is being planned here.
The compile it ready and in production since many years. The visual IDE similar to VB6 IDE is still missing though!
The official web site is: http://www.bcxbasic.com/
There is Yahoo Group here: https://groups.yahoo.com/neo/groups/BCX/info
BCX was programmed entirely using BCX BASIC, making it a self-translating translator. And translating is FAST! BCX translates its own source code, over 24,500 lines of code, in just 1.2 seconds on a P4 laptop running XP Pro.
BCX BASIC to C/C++ Translator by Kevin Diggins (c) 2012
[Lines In: 24524] [Lines Out: 29246] [Statements: 22106] [Time: 1.22 sec's]
BCX translated BC.BAS to BC.C For a C Compiler
The C/C++ source code produced by BCX is highly portable and has been
successfully compiled using these seven popular C/C++ compilers:
Microsoft VC++
Borland Free Compiler
Pelles C Compiler
Mingw32
Digital Mars
Open Watcom
Lcc-Win32 Compiler
HTH
Yogi Yang
-
Nov 7th, 2014, 01:17 AM
#97
New Member
Re: VB Classic (A True VB 7.0)
I am working on vb6 compiler that emit c++ that can generate object code using clang at the moment i am adding the namespace support to it after that i plan to add the class and inheritance stuff.currently it handles all vb native types (integer,long,string,byte,double,single and varient) and supports
on error *** statements
function definitions with optional byval ,byref ("optional byref" is not supported atm)
Arrays
Types
all conditional and loops statements
Generated code outputs line number information so source debuggin is possible
I intend to start an open source project once i get the compiler to be able to compile itself (for that i need to add the class support)
Thing that troubles me is that whether i should make a vb6 (COM) compatible class or a c++ class . if its a vb6 compatible class it can be exported as class library in vb6 but that makes it impossible (to my knowledge) for this new *vb7* to support inheritance since COM only support interface inheritance.hope to add implementation inheritance (or multiple inheritance if i could figure out a way out of "The diamond problem"
Also i plan to add a garbage collector instead of reference counting for objects management
more coming soon. hope to see your involvement with the project once i host the project
-
Nov 7th, 2014, 01:26 PM
#98
Re: VB Classic (A True VB 7.0)
How far along are you at the moment?
If currently you have something working which compiles and emits VB-procedure-Code only,
maybe it's not too late to switch to "plain C-Code-emitting"?
The reason I ask is, because I've done tests already, which show promising results with real
"In-IDE-Edit&Continue-Debugging" (using the tinyC-Compiler as a kind of dynamically re-compilable
InIde-PCode-engine - but this nice and fast little compiler, which can compile directly into memory -
only understands plain C-Code).
I'd see no problem to implement COM-compatible Classes using plain C - and also no problem with
Inheritance using those C-implemented Classes.
You can send a regular E-Mail over my Forum-account to me, in case you have an interest in
discussing these things - maybe we can join forces.
Olaf
-
Nov 7th, 2014, 08:18 PM
#99
New Member
Re: VB Classic (A True VB 7.0)
I havent checked tiny cc but Cling seems promising in the edit and continue part http://root.cern.ch/drupal/content/cling (always exited about higgs boson :P) which undestands c++ 11 .
problem is, its the limitation of COM,COM classes cannot handle implementation inheritance
-
Nov 7th, 2014, 08:22 PM
#100
New Member
Re: VB Classic (A True VB 7.0)
 Originally Posted by Schmidt
How far along are you at the moment?
Most vb6 language constructs are done including Types, in the middle of adding class support, ( also need to verify on the actual c++ output )
In using Boost for handling higher level data structures like arrays and variants.
-
Nov 7th, 2014, 08:28 PM
#101
New Member
Re: VB Classic (A True VB 7.0)
Compiler can handle this atm , (note that i intentionally added some syntax errors for error detection, its not a blind converter it verifies every statements down to each sub statement including types)
Code:
Namespace System
Namespace Core
Public Function tFu_nction(Optional ByVal x as Long , _
Optional ByVal y as Integer="fgfg", _
Optional ByVal z as Long) as Integer
Dim xd As Integer, yc As Double, xu As Integer
x = yc = 123
Dim s As String
x = "123"
s=444
Exit Function
End Function
End Namespace
End Namespace
Public Type TestType
var1 As Long
var2 As String
var3() As String
End Type
Public Type TestType2
var1 As Long
var2 As String
var3() As TestType
End Type
Function Arraytest(g() As String) As String()
On Error Resume Next
Dim ff(1 to 9, 9 to 67) as String
Dim MyStruct as TestType
Dim MyStruct2 as TestType2
MyStruct2.var2=MyStruct.var1
ff(1, 9) = "its"
ff(2, 55) = "working"
Arraytest = ff
End Function
Function booltest() As Boolean
Dim Arr(4, 4) As String
Dim Arr2(1 to 9, 9 to 67) as String
Dim s As String
Dim ffft() As String
ffft = Arraytest(Arr)
s = Arr2(1, 9) '="its"
s = Arr2(2, 55) '="working"
Arr2(1, 9) = "***"
Arr(4, 4) = "its my life"
ReDim Preserve Arr(10, 67)
s = Arr(4, 4)
s = "12" + "99"
s = Arr2(1, 9)
booltest = 0
Dim x As Long
On Error Resume Next
While x < 7
x = x + 1
Wend
For x = 10 To 150 Step 10
If x = 100 Then Exit For
Next x
Dim Y As Long
factorial(x = 8)
Do While x < 8
x = x + 1
Loop
Do
Y = x
Exit Do
Loop
Do
Loop Until x < 8
End Function
Function factorial(ByVal n As Long) As Long
If (n <= 0) Then
factorial = 1
Else
factorial = n * factorial(n - 1)
End If
End Function
Public Function ffftFunction(ByVal x as Long,Optional xg as Integer=0,Optional z as Long) AS String
x = 5 + 7 * 8
On Error GoTo LastLine
x = System.Core.tFunction(7, xg, 0)
ffftFunction = "hello world"
On Error GoTo LastLine
If x > 0 Then x = x + "dd"
GoTo LastLine
LastLine:
911:
Resume Next
End Function
Private Function fact()
Dim TokPrec As Integer, ExprPrec As Double, xu As Integer
If TokPrec <> ExprPrec Then
fact = (System.Core.tFunction() = ".")
ElseIf TokPrec <= ExprPrec Then
Else
fact = 0
End If
fact = 5 + 7 * 8
End Function
-
Nov 8th, 2014, 02:44 PM
#102
Lively Member
Re: VB Classic (A True VB 7.0)
Nice work!
Can you use the same label names within structures in the same program? (FUNCTION/SUB/MAIN)
You may want to have a peek at CERN ROOT as a development environment. (Interpretive C/C++) that uses cling for the compiler.
-
Nov 8th, 2014, 08:50 PM
#103
New Member
Re: VB Classic (A True VB 7.0)
 Originally Posted by ScriptBASIC
Nice work!
Can you use the same label names within structures in the same program? (FUNCTION/SUB/MAIN)
Within in same function NO , why ?
-
Nov 9th, 2014, 10:55 AM
#104
Lively Member
Re: VB Classic (A True VB 7.0)
Not within the same function or sub but in the same program. Sorry for the confusion.
-
Nov 9th, 2014, 01:31 PM
#105
Re: VB Classic (A True VB 7.0)
 Originally Posted by indika.online.lk
Most vb6 language constructs are done including Types, in the middle of adding class support, ( also need to verify on the actual c++ output )
In using Boost for handling higher level data structures like arrays and variants.
I'd strongly suggest, that you use the original type-defs and structs which are used under
the covers of VB6 also (meaning the safearray and variant-structs here).
There's a lot of VB6-code out there which is accessing those structs at a lower level
(safearrays are accessed in VB e.g. for fast DIB-Handling - or fast String-Parsing - and
Variant-structs are accessed in quite some scenarios in the same way - e.g. with an
Offset of 8 Bytes, to reach the underlying Value or StrPtr or ArrPtr/ObjPtr which sits there.)
It's important to care about that in this early state, before (much) more things are packed
onto this groundwork - not easy to introduce such breaking changes as "safearray-compatibility"
at a later time.
Also the String-Type should be compatible with BSTR (since a lot of VB-Code is expecting
such an allocation to have 4 Extra-Bytes "to the left of the StringPointer" which describe the
allocated length in Bytes. Also the trailing Double-ZeroBytes should be ensured on that String-Type.
As for COM only supporting interface-inheritance (and not implementation inheritance)...
With a compiler one can juggle and re-arrange the VTable-entries as needed -
as well as defining extra-space in the Private-Vars-struct of the *inheriting* class
for the members of the Private-Vars-struct of the *inherited* Class.
That's how it could work at a lower level for the Compilers "own" generated classes.
In the simplest case - even with how VB6 actually works - we could accomplish
inheritance, when the compiler in case of our current interface-inheritance-scheme
just ensures also the *implementation* of those interface-methods, by drawing an
instance of the Class it inherited from - and delegating to the VTable-entries of that Class.
Expressed in VB-Code (all written by hand instead of a compiler-emitting-automatism):
If you define a BaseClass like this:
TypeName: cBaseClass
Code:
Public Sub SayHello()
MsgBox "I'm a cBaseClass-instance"
End Sub
Public Function AddTwoLongs(L1 As Long, L2 As Long)
AddTwoLongs = L1 + L2
End Sub
The above Class is not defining a "plain virtual interface" only, it also contains
the implementation behind the methods already.
Now, another class which plans to inherit that interface *and* that base-implementation
would be written this way in VB6:
TypeName: cDerivedClass
Code:
'***** inheritance-by-delegation follows ******
Implements cBaseClass 'defines the VTable-entries we need to implement in addition
Private cBaseClass As New cBaseClass
Private Sub cBaseClass_SayHello()
cBaseClass.SayHello
End Sub
Private Function cBaseClass_AddTwoLongs(L1 As Long, L2 As Long)
cBaseClass_AddTwoLongs = cBaseClass.AddTwoLongs(L1, L2)
End Sub
'***** end of inheritance-by-delegation ******
'the cDerivedClass's own public Methods follow
Public Sub DoinMyOwnThang()
'...
End Sub
So - to support inheritance the compiler would do the delegation-code to the BaseClass
in above interface-signatures (the part within the asterisks) for us automatically by default.
As it is currently, a VB-developer is *enforced* to fill out any implemented (interface-inherited)
method-signature "by hand" (then in any single method being free, to either delegate to
the BaseInstance - or to "override" and putting his own stuff into the method-stub, which
can get quite straining when we talk about of 30 or more Public entries in the VTable,
although one planned to override only one or two members of the BaseClass).
So in the easiest case the compiler could be doing something like the above,
which is neither hard to understand nor to accomplish (at the code-emitter-level).
Olaf
Last edited by Schmidt; Nov 9th, 2014 at 01:35 PM.
-
Nov 9th, 2014, 09:14 PM
#106
New Member
Re: VB Classic (A True VB 7.0)
It's important to care about that in this early state, before (much) more things are packed
onto this groundwork - not easy to introduce such breaking changes as "safearray-compatibility"
at a later time.
Also the String-Type should be compatible with BSTR (since a lot of VB-Code is expecting
such an allocation to have 4 Extra-Bytes "to the left of the StringPointer" which describe the
allocated length in Bytes. Also the trailing Double-ZeroBytes should be ensured on that String-Type.
This is why the namespace support was added to the compiler from the beginning cos runtime can expose different implementations of String,Varient by using namespaces
say if you add
Code:
using Classic.Types
or
Code:
using Classic.Types.String
the compiler uses the vb6 implementation, and use the vb6 project loader to automatically add this to source files when it converts the vb6 prj to new version.
As for COM only supporting interface-inheritance (and not implementation inheritance)...
With a compiler one can juggle and re-arrange the VTable-entries as needed -
as well as defining extra-space in the Private-Vars-struct of the *inheriting* class
for the members of the Private-Vars-struct of the *inherited* Class.
That's how it could work at a lower level for the Compilers "own" generated classes.
In the simplest case - even with how VB6 actually works - we could accomplish
inheritance, when the compiler in case of our current interface-inheritance-scheme
just ensures also the *implementation* of those interface-methods, by drawing an
instance of the Class it inherited from - and delegating to the VTable-entries of that Class.
This "Wrapping" is easy for single inheritance, but gets complected when handling multiple inheritance or polymorphism
How about doing it this way
Only COM classes are needed when you need to expose them outside the project, so what if we set the default classes to be c++ classes and public exposed classes to inherit from a class that support COM
something like
Code:
Class ExposedClass Implements Classic.COM
End Class
again this modification of the source can be added automatically by the project loader by looking whether it is a public or private class.So its transparent to the user.
since C++ already has the groundwork for inheritance , polymorphism , why reinvent the wheel,
thats one of the reason i choose c++ over c also to OOP to work propely we need runtime type infomation. for casting etc. so it get completed to implement it manually.
Olaf you are right we do need to talk about this now than later. so we can deduce the best implementation
ill post some c++ output of the compiler later on so i can be certain that im on the right track
-
Nov 10th, 2014, 01:04 PM
#107
New Member
Re: VB Classic (A True VB 7.0)
Current compiler binary and vs2010 project of runtime can be seen at https://code.google.com/p/v7basic/
Runtime is really ugly atm, not to mention buggy , at this stage i only used it to check c++ code validity , but you can run it and single step the basic code 
feel free to interrogate OpenBasic.exe by changing the test.bas
I didnt want to upload the boost library but i had to cos i modified some headers of boost multi_array.
-
Nov 13th, 2014, 12:06 AM
#108
Addicted Member
Re: VB Classic (A True VB 7.0)
I just ran into this framework for VB developers in C++ on sf.net.
Thought I will share it here it may be useful who knows.
http://ezbasic.sourceforge.net/index.php
HTH
Yogi Yang
-
Nov 14th, 2014, 12:54 AM
#109
Banned
Re: VB Classic (A True VB 7.0)
@Schmidt you may consider the Chameleon Basic as a guide on the new Visual Basic 6.0 compiler.
http://sourceforge.net/projects/chameleonbasic/
-
Nov 19th, 2014, 12:36 AM
#110
Lively Member
Re: VB Classic (A True VB 7.0)
@Schmidt you may consider the Chameleon Basic as a guide on the new Visual Basic 6.0 compiler.
Thanks for the link! I gave it a try and was surprised how far along this BASIC to ASM compiler has come. I hope the author continues with its development.
-
Nov 22nd, 2014, 01:28 PM
#111
Lively Member
Re: VB Classic (A True VB 7.0)
Last edited by ScriptBASIC; Feb 10th, 2018 at 06:34 PM.
-
Nov 23rd, 2014, 08:37 AM
#112
Banned
Re: VB Classic (A True VB 7.0)

Source: ANIMATION of the Visual Basic 6.0 incandescent bulb (simple GIF images): http://vb6awards.blogspot.com/2014/1...nt-bulb_8.html
-
Nov 23rd, 2014, 08:37 AM
#113
Banned
Re: VB Classic (A True VB 7.0)
-
Feb 10th, 2015, 10:17 PM
#114
Banned
Re: VB Classic (A True VB 7.0)
Someone has successfully converted C code to VB6. What if doing the conversion in reverse. VB6 to C code then compile it. That behaviour is similar to Basic4Android. It uses VB.NET style syntax as frontend but java code at backend. Upon compilation, it transalates the VB.NET like code to java and compile it.
Because of that, then its possible to write a VB6 code, convert it to C++ code and compile it.
http://www.planetsourcecode.com/vb/s...12483&lngWId=1
-
Feb 11th, 2015, 04:21 AM
#115
Addicted Member
Re: VB Classic (A True VB 7.0)
 Originally Posted by rizalmartin
Someone has successfully converted C code to VB6. What if doing the conversion in reverse. VB6 to C code then compile it.
Because of that, then its possible to write a VB6 code, convert it to C++ code and compile it.
It's already been tried on many previous incarnations, and all have stopped development (propably due to losing interest themselves).. You'll find some opensource versions already on github or some other public sites..
-
Feb 11th, 2015, 10:32 AM
#116
Banned
Re: VB Classic (A True VB 7.0)
Prove it SupreDre. Show the links please.
-
Feb 11th, 2015, 01:07 PM
#117
Addicted Member
Re: VB Classic (A True VB 7.0)
 Originally Posted by rizalmartin
Prove it SupreDre. Show the links please.
sigh.... take your pick: http://basic.mindteq.com/ and be sure to check out the 'discontinued' section.....
but hee, maybe you can use one of those which made their source available and continue the work yourself...
-
Feb 12th, 2015, 09:45 PM
#118
Banned
Re: VB Classic (A True VB 7.0)
 Originally Posted by SuperDre
sigh.... take your pick: http://basic.mindteq.com/ and be sure to check out the 'discontinued' section.....
but hee, maybe you can use one of those which made their source available and continue the work yourself...
Thank you for this link. This will help on developing a true VB7 compiler.
-
Feb 12th, 2015, 11:34 PM
#119
Addicted Member
Re: VB Classic (A True VB 7.0)
Hi SuperDre,
I think you need to check this one: http://www.bcxbasic.com/
It is alive and updated regularly.
HTH
-
Feb 10th, 2018, 05:12 PM
#120
Lively Member
Re: VB Classic (A True VB 7.0)
How is vb7, have you made any progress?
Sorry to resurrect the topic
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|