dcsimg
Page 3 of 4 FirstFirst 1234 LastLast
Results 81 to 120 of 121
  1. #81
    Junior Member
    Join Date
    Feb 2014
    Posts
    26

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by axisdj View Post
    / 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.

  2. #82
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,638

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by yogiyang View Post
    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.

    Quote Originally Posted by yogiyang View Post
    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 09:04 PM.

  3. #83
    Addicted Member
    Join Date
    Mar 2007
    Location
    India
    Posts
    227

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post
    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.

  4. #84
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,638

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by yogiyang View Post
    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".


    Quote Originally Posted by yogiyang View Post
    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.

    Quote Originally Posted by yogiyang View Post
    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

  5. #85
    Addicted Member
    Join Date
    Mar 2007
    Location
    India
    Posts
    227

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post
    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?

  6. #86
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,638

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by yogiyang View Post
    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"...

    Quote Originally Posted by yogiyang View Post
    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 05:13 AM.

  7. #87
    Addicted Member
    Join Date
    Mar 2007
    Location
    India
    Posts
    227

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post
    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

  8. #88
    Lively Member
    Join Date
    Aug 2013
    Posts
    73

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post
    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

  9. #89
    Junior Member
    Join Date
    Feb 2014
    Posts
    26

    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 06:37 AM. Reason: completion

  10. #90
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,638

    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 11:10 AM.

  11. #91
    Junior Member
    Join Date
    Feb 2014
    Posts
    26

    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.

  12. #92
    Junior Member
    Join Date
    Feb 2014
    Posts
    26

    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.

  13. #93
    Junior Member
    Join Date
    Feb 2014
    Posts
    26

    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.

  14. #94
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    4,282

    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.

  15. #95
    Member ScriptBASIC's Avatar
    Join Date
    Oct 2014
    Posts
    33

    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)

  16. #96
    Addicted Member
    Join Date
    Mar 2007
    Location
    India
    Posts
    227

    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

  17. #97
    New Member indika.online.lk's Avatar
    Join Date
    Nov 2013
    Posts
    7

    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

  18. #98
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,638

    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

  19. #99
    New Member indika.online.lk's Avatar
    Join Date
    Nov 2013
    Posts
    7

    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

  20. #100
    New Member indika.online.lk's Avatar
    Join Date
    Nov 2013
    Posts
    7

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post
    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.

  21. #101
    New Member indika.online.lk's Avatar
    Join Date
    Nov 2013
    Posts
    7

    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

  22. #102
    Member ScriptBASIC's Avatar
    Join Date
    Oct 2014
    Posts
    33

    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.

  23. #103
    New Member indika.online.lk's Avatar
    Join Date
    Nov 2013
    Posts
    7

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by ScriptBASIC View Post
    Nice work!

    Can you use the same label names within structures in the same program? (FUNCTION/SUB/MAIN)
    Within in same function NO , why ?

  24. #104
    Member ScriptBASIC's Avatar
    Join Date
    Oct 2014
    Posts
    33

    Re: VB Classic (A True VB 7.0)

    Not within the same function or sub but in the same program. Sorry for the confusion.

  25. #105
    PowerPoster
    Join Date
    Jun 2013
    Posts
    3,638

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by indika.online.lk View Post
    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 12:35 PM.

  26. #106
    New Member indika.online.lk's Avatar
    Join Date
    Nov 2013
    Posts
    7

    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

  27. #107
    New Member indika.online.lk's Avatar
    Join Date
    Nov 2013
    Posts
    7

    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.

  28. #108
    Addicted Member
    Join Date
    Mar 2007
    Location
    India
    Posts
    227

    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

  29. #109
    Banned
    Join Date
    Nov 2014
    Posts
    4

    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/

  30. #110
    Member ScriptBASIC's Avatar
    Join Date
    Oct 2014
    Posts
    33

    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.

  31. #111
    Member ScriptBASIC's Avatar
    Join Date
    Oct 2014
    Posts
    33

    Re: VB Classic (A True VB 7.0)

    * Deleted *
    Last edited by ScriptBASIC; Feb 10th, 2018 at 05:34 PM.

  32. #112
    Banned
    Join Date
    Jan 2014
    Posts
    50

    Re: VB Classic (A True VB 7.0)

    Name:  Visual%u00252BBasic%2B6.0%2Bincandescent%2Bbulb%2Banimation%2B3.jpg
Views: 2357
Size:  12.5 KB

    Source: ANIMATION of the Visual Basic 6.0 incandescent bulb (simple GIF images): http://vb6awards.blogspot.com/2014/1...nt-bulb_8.html

  33. #113
    Banned
    Join Date
    Jan 2014
    Posts
    50

  34. #114
    Banned
    Join Date
    Nov 2014
    Posts
    4

    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

  35. #115
    Addicted Member
    Join Date
    Mar 2009
    Posts
    186

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by rizalmartin View Post
    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..

  36. #116
    Banned
    Join Date
    Nov 2014
    Posts
    4

    Re: VB Classic (A True VB 7.0)

    Prove it SupreDre. Show the links please.

  37. #117
    Addicted Member
    Join Date
    Mar 2009
    Posts
    186

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by rizalmartin View Post
    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...

  38. #118
    Banned
    Join Date
    Nov 2014
    Posts
    4

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by SuperDre View Post
    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.

  39. #119
    Addicted Member
    Join Date
    Mar 2007
    Location
    India
    Posts
    227

    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

  40. #120
    New Member
    Join Date
    Aug 2017
    Posts
    6

    Re: VB Classic (A True VB 7.0)

    How is vb7, have you made any progress?

    Sorry to resurrect the topic

Page 3 of 4 FirstFirst 1234 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width


×
We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.