VB Classic (A True VB 7.0)-VBForums
Page 1 of 3 123 LastLast
Results 1 to 40 of 113

Thread: VB Classic (A True VB 7.0)

  1. #1

    Thread Starter
    The DirectXpert Jacob Roman's Avatar
    Join Date
    Aug 2004
    Location
    Miami Beach, FL
    Posts
    5,075

    VB Classic (A True VB 7.0)

    Introduction:
    Its been many years since MS dropped support for VB6, yet people continue to use it to this very day. Many users have switched over to VB.Net due to how powerful it is, and the fact that its truly object oriented. But some find the runtime too large, and their apps are too dependent on the .NET Framework. The on going battle between VB6 lovers and VB.Net nuts must come to an end. Its time we developers unite to create the ultimate VB language that's fast and easy to use. A language that is extremely RAD (Rapid Application Development). Its time for VB Classic.

    Why VB Classic?
    VB Classic if done right will be the solution to every VB developers problems. People as well as businesses continue to use VB6 for a reason. Either its too expensive and time consuming to switch to VB.Net and port all that code, or some people find VB6 easier to code for than VB.Net. Some people also find VB.Net lingering away from the BASIC syntax that we all once recognized. But people use VB.Net for a reason too. Its powerful, the latest technology, and actually object oriented. Some find VB.Net easier to code for than VB6. But what draws you in to stick with your favorite VB language regardless of version you use? What do you not like about it? If we all iron out the flaws of VB, we can create an improved VB language, and make it easy to migrate to from both sides of the fence without overwhelming you with a completely new syntax. A lot of people find both languages have very slow functions they would like to see execute faster for example. VB Classic will have very familiar commands execute as fast as humanly as possible so you will have no worries of slowdown in time sensitive projects such as games!

    Can I be a part of the Team?
    I will need a team of people to help me put this together. You can PM me or say you want in here in this thread, but you must be serious about joining. Before we even begin to jump into syntax, I would like help in putting together the IDE. Once we have an IDE to work with, then we can discuss syntax. The reason is because if we talk about syntax, we can go on and on until theres about 20 pages of a super thread going, but.... no IDE was made. I don't want to make the same mistake that happened with LightFusion, and its a must that progress must be made. The IDE will be designed in C++ starting with the basic window, the menu items, and the code window within the window. As we progress, then we can add special things such as a toolbox and such. The IDE is a must before a syntax can be formed.

    IMO I think eyeRmonkey did a better job in creating an intro for developing a new programming language
    http://www.vbforums.com/showthread.p...ht=lightfusion

  2. #2
    Frenzied Member
    Join Date
    Jun 2013
    Posts
    1,404

    Re: VB Classic (A True VB 7.0)

    I like your approach, to come up with an IDE first (before tackling the compiler itself) because that's my opinion as well -
    though I think I reached that point due to different reasons than the one you listed above (avoiding lengthy discussions).

    My reasons, that a compiler needs to come last are:

    - it's not the most complex part in the project (if the language and especially the environment shall be a "visual one")
    - RADishness comes mostly from libraries (and a good, accompanying "visual IDE" is only the candy on top of a good GUI-framework)
    - community-projects who followed the other approach (compiler first, then "everything else") mostly remain with the compiler and don't achieve a tight integration with a "RADish, visual IDE" anymore
    (-> because there never was an: "agreed upon, officially and tightly integrated GUI-framework to saddle on from the very beginning"...
    (-> just see the already well-working Basic-compilers www.FreeBasic.net and www.OxygenBasic.org as an example, which are both badly in need of a "unified GUI-framework, ideally written in the language itself")

    Flying over the thread you linked to, I discovered the contributions of CornedBee and I couldn't agree more - e.g. he wrote:
    Quote Originally Posted by CornedBee View Post
    Oh, once again we're at the language/library boundary. Making a language platform-independent is easy. The only problem is that you need more than compiler - but if you, for example, write the compiler as a GCC front-end, you get that for free.

    The libraries, however, need to interface with the OS to do anything meaningful, so yes, there platform-independence would be a lot of work.
    On the other hand, it's not necessarily you who must do the work. If you simply design the libraries so that they don't clearly favour one OS, you can then implement them for the OS you're using and leave the porting to other people.

    Take a look at C#, for example. Porting C# itself was simple and done in the Mono project within a few weeks, I think. Writing the CLR wasn't too hard either. The real issue is porting the .Net framework, especially the System.Windows.Forms namespace, which is extremely clearly modeled after the Win32 model, thus making implementation on top of X Windows all but impossible - the Mono project uses the WINE WinAPI implementation for this namespace.
    So, I'm interested - because "writing an IDE" was also on my own personal agenda next (on my way to a new VB6-compatible compiler) - though I reached this point after doing
    "a whole lot of additional groundwork over the last years" - in analogy to the statements of CornedBee above, I focused on a "rich, accompanying framework" first (www.vbRichClient.com).

    Meaning, I've now brought the necessary and modern class-framework (a class-based runtime) for the new language into shape, which not only
    - covers a modern vector-based GUI-approach (already platformindependent, due to a cairo-binding)
    - but also all kind of List-classes are integrated (ArrayList, Collection, SortingDictionaries)
    - Filesystem- and Stream-support is encapsulated behind classes too
    - XML, StringBuilder, as well as all kind of other "StringCodecs" (Base64, Hashing, Compression, Crypto-Algos etc.) are contained
    - basic Networking-classes (cTCPServer, cTCPClient, cUDP) are integrated
    - higher-level Networking too (cRPC-Classes as a DCOM-replacement, cWebServer for InProcess http-Serving)
    - and ADO-like Classes (cConnection, cCommand, cRecordset) are there as well, wrapping SQLite as a well-working alternative to ADO/JET

    So that's what would be available (and IMO necessary to consider and integrate early on) for the new language, IDE and compiler... each and every Class above is implemented in VB6 -
    and thus would become immediately "recompilable in the new language" as soon as the new compiler reaches its selfhosting-state and is basically compatible to VB6.

    I don't understand, why you would want to develop the new IDE in C++.
    - if the new compiler will be nearly compatible to VB6 in the end - then why on earth not develop in the VB6-IDE?
    (-> any code we write in VB6 - especially when we restrict ourselves to use only *.cls and *.bas modules, should become recompilable with the new language and thus selfhosting).

    - second point: *any* GUI-development for the new IDE should go through a class-abstraction-layer for the GUI, to be able to port the new IDE later on also to other OS-platforms much easier.

    So yeah - I'd join the efforts, when we would base the whole IDE- and Runtime/Compiler-idea on the already existing (VB6-based) class-abstraction-layer which comes with the RichClient-framework.

    Such a "rich runtime-environment" is necessary for a modern RAD-language - not thinking about it beforehand will doom any attempts in
    "writing a True Visual Environment, which integrates also a UserControl- or Widget-concept tightly".


    Olaf
    Last edited by Schmidt; Jul 30th, 2013 at 11:16 PM.

  3. #3

    Thread Starter
    The DirectXpert Jacob Roman's Avatar
    Join Date
    Aug 2004
    Location
    Miami Beach, FL
    Posts
    5,075

    Re: VB Classic (A True VB 7.0)

    Thankfully someone stepped up to the plate.

    I am doing the IDE in C++ because of a couple reasons:

    1) I want the IDE to not be dependent on the .NET Framework or the VB6 runtime library. I understand that the compiler can be in C++ and the IDE can be some other language while we work with the files in between such as the .bas, .cls, and .frm files which will contain the source code. Word has it that Microsoft will supposedly be dropping support for the .NET Framework in the near future (keyword supposedly, nothing is official) and target Windows RT based apps which are compatible with tablets, smartphones as well as PCs and laptops. If I was to design the IDE in lets say VB.Net, then what if my IDE no longer works in future OS's? Same holds true for C#. And VB6 programs are already getting harder and harder to run for every new OS due to the minor tweaks you must do such as registering obsolete dlls your program is dependent on.

    2) C++ is extremely powerful and very very fast in execution. You have so much more control in everything you do. Yes its harder to code in, but the payoff in the end is what matters the most. You also can code low level inline assembly to speed up routines where they are needed. You have full control when you do multithreading. There are so many reasons why.

    I do have a possible good idea though. We could design the IDE with VB.Net first and build upon that until we have a basic foundation. And once its finally complete (the IDE) we can convert it to C++. It may seem double the work, but well have something to work off of. Sort of a blue print rather than play by ear. The compiler and linker is gonna be a separate program anyways (obviously written in C++).

  4. #4
    Frenzied Member
    Join Date
    Jun 2013
    Posts
    1,404

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Jacob Roman View Post
    1) I want the IDE to not be dependent on the .NET Framework or the VB6 runtime library.
    That will be automatically the case, as soon as the new compiler is finished (and not emitting MSIL, but C-code instead) - and we recompile everything with it.

    To be able to write a true selfhosting environment (which I would prefer - please google for the term if not yet entirely clear),
    we would need to program in the same language we write the new compiler for.
    Sounds ambiguous a bit, but in our special case (since we don't want to design an "entirely new thing", but only a mostly compatible one) -
    that becomes easy, since we can write "good old VB6-code" in the well-known and RADish "VB6-IDE as Initiator-platform".

    Sure, you could write the new IDE in C++ (and the compiler too) - but this is not necessary at all.
    VB6 offers more than enough to cover everything what's needed (for the new IDE as well as for a new C-emitting compiler) - and as said,
    the code-base we would generate (the IDE-sources as well as the Sources for the C-emitter) would remain in the realm of the target-language
    (VB6-compatible) - and thus much better maintainable by VB-coders.

    I would like to say (when everything is done in some years):
    - Our new IDE is written in VB7 itself
    - Our new (tightly integrated into the new IDE) VB7-compiler is written in VB7 itself
    - Our new class-based Runtime/Minframework is written in VB7 itself

    I mean, you propose in your opener-posting, that "the new language will be fast and does everything you always wanted from a VB7".
    So why eaxctly do you prefer, to write the IDE and Compiler in C++, if the new target-language is "as fast and powerful as C++" (which is perfectly doable with a C-Emitter BTW).

    Quote Originally Posted by Jacob Roman View Post
    I understand that the compiler can be in C++ and the IDE can be some other language while we work with the files in between such as the .bas, .cls, and .frm files which will contain the source code.
    As said, the compiler can be written in VB6 easily too - that's not rocket-science - only string-concats, If-condtitions and loops... ;-)
    And as for *.frm files - those wouldn't be needed with my proposed approach (when we use the VB6-based class-framework for the GUI).

    Quote Originally Posted by Jacob Roman View Post
    2) C++ is extremely powerful and very very fast in execution.
    Believe me, for that task (IDE and new Compiler) the VC6++ compiler (C2.exe) which comes with VB6 offers more than enough performance.

    Quote Originally Posted by Jacob Roman View Post
    I do have a possible good idea though. We could design the IDE with VB.Net first and build upon that until we have a basic foundation. And once its finally complete (the IDE) we can convert it to C++.
    Nope - that would not be the way to go for me.
    VB.NET is not necessary at all (VB6 is more than enough) - and especially the final porting to C++ is entirely absurd for me -
    as already explained above - it is desirable to have the IDE, the compiler (the whole environment) available in the final target-language.
    And if this target-language is a VB7 - and this new VB7 shall be "as compatible as it gets" to VB6 - then by all means, let's write the
    first version of the IDE and the new compiler in VB6.

    Quote Originally Posted by Jacob Roman View Post
    It may seem double the work, but well have something to work off of.
    That would be "triple work" from my point of view, since the ideal code-base "to have", would be neither VB.NET, nor C++ but the new language VB7 itself.

    Quote Originally Posted by Jacob Roman View Post
    The compiler and linker is gonna be a separate program anyways (obviously written in C++).
    Not necessarily - the compilation and linking-step can also be performed by a Dll (in case of a C-emitter this could be libTCC.dll for example).
    And as said, the C-emitter (as the Compiler-frontend for GCC/MingW or TCC) can and should be written in the new language.

    Olaf

  5. #5
    New Member
    Join Date
    Jul 2013
    Posts
    8

    Re: VB Classic (A True VB 7.0)

    I would love to participate in this project!

    I am already aware of the work done by Olaf in the vbRichClient Framework (I am using it in my projects with excellent results!) and I am already contributing to Olaf's vbWidgets project. I really recommend you to read the About section of the vbRichClient site, the whole story is summarized there. I think it's the way to go...

    Kbre

  6. #6

    Thread Starter
    The DirectXpert Jacob Roman's Avatar
    Join Date
    Aug 2004
    Location
    Miami Beach, FL
    Posts
    5,075

    Re: VB Classic (A True VB 7.0)

    Yes I'm aware of C2.exe but I don't think its possible for us to create our own low level assembler commands through it. For example. Lets say I want VB Classic to have a super fast Square Root thats a lot faster than the current square root function:

    Code:
        float inline __declspec (naked) __fastcall sqrt2(float n)
        {
            _asm
            {
                fld dword ptr [esp+4]
                fsqrt
                ret 4
            }
        }
    This alone is even faster than C++'s sqrt() function from the math.h library! Practically the fastest square root in existance Although its the float version, the double version is in this link and you can compare the different ones here: http://www.codeproject.com/Articles/...nction-Precisi

    If C2.exe would accept this, I will go along with it. Because I want VB Classic to be very fast and efficient.

  7. #7
    New Member
    Join Date
    Jul 2013
    Posts
    8

    Re: VB Classic (A True VB 7.0)

    I think that further in the future of this project, we could certainly add inline asm to our VB-written VB compiler. I don't see the need of super fast speed to develop the (initial) IDE. We simply need one place to start from until we get the thing seft-working, and after that we could do anything!

    In the meantime, possibly you could use something like this.

  8. #8
    Frenzied Member
    Join Date
    Jun 2013
    Posts
    1,404

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Jacob Roman View Post
    Yes I'm aware of C2.exe but I don't think its possible for us to create our own low level assembler commands through it. For example. Lets say I want VB Classic to have a super fast Square Root thats a lot faster than the current square root function...
    Maybe to make things more obvious - let's introduce a new name-definition for the working compiler-binary we would end up with (currently it's not really clear what is meant with 'VB Classic' or VB7 when we use the terms).

    Say, the new compiler which is producing the "new, small and fast" VB6-compatible-binaries is called cb7.exe.
    Just to introduce a term, we can associate with "an action" (a compiler-run which produces a binary).

    Now you have for example some code-input in "mySuperFastSqrtDemo.bas" and you call on the commandline:

    > cb7.exe mySuperFastSqrtDemo.bas -o mySuperFastSqrtDemo.exe

    The produced mySuperFastSqrtDemo.exe is now not dependent on msvbvm60.dll anymore (no matter if the cb7.exe-binary itself is still compiled with VB6) because:

    - cb7.exe has parsed the contents of the passed file "mySuperFastSqrtDemo.bas" into Tokens and build a tree-like structure internally
    - the treelike Token-Structure can be parsed lexically (already in the tokenizing-run, but also in additional runs), to be refined and in parts restructured (throwing out syntax- and compile-errors, if there are any)
    - if after the Lexer-run we have a validated Tree-Structure, we traverse the tree and start firing out matching C-Code-snippets, according to the Tree-elements - all accumulated in a StringBuilder-Object (or a similar structure)
    - now cb7.exe can start putting temporary files out (one per parsed and tokenized src-module) as e.g.: mySuperFastSqrtDemo.c
    - then cb7.exe fires a C-compiler up under the hood (could be GCC or TCC) - to produce the final binary from the temporary c-Files (incorporating a few "environmental and runtime things" from cb7_runtime.h and cb7_runtime.c and a few static libs).

    In all of the above actions which cb7.exe performs I see no heavy usage of "squareroot-functions, which need to be superfast".

    cb7.exe could be programmed in VBScript for the tasks it performs (Ok, when the total amount of Lines-Of-Code in a larger project goes above 100000, we would need a fast parsing - but you get my point).

    So it doesn't really matter, if cb7.exe itself is based on VB6 still - or was already compiled "with itself" (so that cb7.exe will not depend on msvbvm60.dll anymore).

    When you talk about: "I want the best performing Square-Root-function there is" - then you want to place a runtime-function-inline-snippet for that in cb7_runtime.h or cb7_runtime.c ( in case we are not satisfied with what math.h has to offer)

    That's where it counts - and where the final C-compiler-run can find and apply it (because you want it in the end-result: mySuperFastSqrtDemo.exe and not in cb7.exe).

    So in all the following postings I'd like when you keep the above in mind - and not intermingle the "binaries we want to produce with the new compiler" - and "the compiler-binary itself" anymore.

    I was arguing to use VB6 as the initiator-platform to produce the first version of cb7.exe.
    With the goal, to be finally able (after refining cb7.exe more and more), to do at the commandline:

    > cb7.exe cb7.vbp -o cb7_selfhosted.exe

    And until we are able to do (and celebrate!) the above compiler-run, I'd like to encapsulate within cb7.exe also a well-working IDE, with an Editor and Form-Designer in analogy to VB6.exe.

    I hope you see the similarities:
    VB6.exe is hosting both - an IDE as well as the (higher-level) commandline-interface (which under the hood in native mode fires up a C-compiler -> C2.exe)
    cb7.exe will too host both - an IDE as well as the (higher-level) commandline-interface (which under the hood in native mode fires up a C-compiler -> gcc.exe or tcc.exe)

    And as long as cb7.exe is not yet capable to "produce itself" (because our tokenizer is still lacking - or the C-Code-Emitter has still bugs) we will have to resort with our sources to do:
    > VB6.exe cb7.vbp -o cb7.exe

    I hope this clears things up a bit more on your end.

    We don't need C++ to write a fast parser, a fast tokenizer/lexer/emitter.
    We don't need C++ to write a nice IDE and a nice Form-Designer.
    We can bundle and code everything, what ends up within cb7.exe with VB6.exe and whilst doing so...
    we can save us a whole lot of additional work, and make our new visual-environment more platform-independent, when we avoid using platform-APIs (the WinAPI) whereever possible
    and therefore work through a modern and timesaving VB6-based Class-Framework which offers a platform-independent GUI-approach for "all the visuals" and is later on recompilable with cb7.exe too (selfhosting-wise).


    Olaf
    Last edited by Schmidt; Jul 31st, 2013 at 04:21 PM.

  9. #9
    Hyperactive Member
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    369

    Re: VB Classic (A True VB 7.0)

    Count me in on this project as well if you need more contributors. I don't know if I could help too much with the compiler (might be too advanced for me to really contribute), but IDE programming, UI, and "regular" application logic are within my skillset. I can also do documentation. When do we start?

  10. #10
    Hyperactive Member
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    369

    Re: VB Classic (A True VB 7.0)

    I'm also curious about what you think about extending the language. Obviously we want to be able to compile standard VB6 code, but what about new language constructs (say, try..catch blocks for example)?

  11. #11
    Addicted Member
    Join Date
    Mar 2009
    Posts
    159

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by Schmidt View Post
    any code we write in VB6 - especially when we restrict ourselves to use only *.cls and *.bas modules, should become recompilable with the new language and thus selfhosting
    Why restrict to only *.cls and *.bas, VB6 is more than those alone.. *.frm (and the usercontrol ones) are just as important.. I know *.cls and *.bas are the easiest to do, but one of the reasons people tend to stick with their vb6 instead of opting to go for vb.net is due to the investment in created forms and usercontrols (which normally don't port so well to .NET).. A lot of people have just stuck to using the stock components and commoncontrols, so making sure those are at least available in the visual basic classic is almost a must (for people to want to use this 'community' driven language, instead of MS's visual studio .net). Also a lot of projects are using WINAPI for doing a lot of stuff so it also must be able to 'mimic' those..

    Just creating a new version of VB without supporting the already available 'commonly used' options for vb6 isn't a smart thing, as it still will keep a lot of developers of this new version as it will cost almost just as much time to port it to the new version as it is to porting it to VB.NET or C# (VS2013 even has a paste VB.NET code to C# code and vicaversa).


    Quote Originally Posted by Schmidt View Post
    So yeah - I'd join the efforts, when we would base the whole IDE- and Runtime/Compiler-idea on the already existing (VB6-based) class-abstraction-layer which comes with the RichClient-framework.
    Such a "rich runtime-environment" is necessary for a modern RAD-language - not thinking about it beforehand will doom any attempts in
    "writing a True Visual Environment, which integrates also a UserControl- or Widget-concept tightly".
    Don't take this as an attack on your work as I only glanced over your site and I'm in the process of reinstalling vb6 on my home computer just to check it all out, but just speaking as the devil's advocate:
    But you state yourself you're only interested in it if it's already using your RichClient-framework, whereas I think it should be (almost, at least like vb5=>vb6) 100% compatible so one can at least start with a large project they already have and port it to this RichClient-framework at their own pace after they're already using the new advantages of the new version.. Otherwise people could just as well use RealBasic/studio which as I heard also has all the advantages of modern OSses..

    Quote Originally Posted by jpbro View Post
    I'm also curious about what you think about extending the language. Obviously we want to be able to compile standard VB6 code, but what about new language constructs (say, try..catch blocks for example)?
    that ofcourse is also a must, being able to keep the old style of doing stuff, but also being able to do stuff in a more modern way.. Also stuff like shortcircuit IF's is something that would be high on my list, NOT by using stuff like 'AndAlso' or 'OrElse', but just letting the original 'And' and 'Or' do the same shortcircuit (by means of stuff like 'Option ShortCircuit' or something like that (we already have 'Option explicit' and some other).. Also support for unsigned integers is a must IMHO.. And Inheritance/function overloading/etc.. real multitasking etc.. All on top of the original VB6 language.. hehe..

    But why even create your own IDE? there are already excellent (free) IDE's out there for use with any language, like Eclipse.. Creating your own IDE is great ofcourse, but you still have the big problems of Debug-and-Run of your code, that's the hardest part to creating the IDE, and it's one of the BIGGEST reason why a lot of people used VB. Having an IDE for only Intellisense/writing/refactoring/whatever code and being able to compile it, isn't an interesting IDE, it took MS a long time to get VS.NET up to the same level of userfriendlyness as the VB6 IDE (VC++ developers were jealouse at the vb6 IDE back then)..

    Being able to use the current vb6 IDE and recompile to a new target would be a great thing already, there are already some examples of using that (vbthunder is a good one)..

    Yes, I would want a real new VB7, but if it means having to invest just as much time as I have to when I go to another language, then it just isn't worth the time/effort profesionally speaking..
    Don't get me wrong, IMHO there still isn't a language syntaxwise that I like better than vb6 (just needs a few extra's). But then again, I have my own views on what a language should be, and it does not seem to fit with the ideas a lot of other people..

    I was also thinking about doing a real vb6 clone, so I'm definitly gonna keep my eye open for this project, and I'll certainly will speak my mind So please don't take it as an assault on your work, it's just my opinion..

  12. #12
    PowerPoster
    Join Date
    May 2002
    Posts
    25,984

    Re: VB Classic (A True VB 7.0)

    NOT by using stuff like 'AndAlso' or 'OrElse', but just letting the original 'And' and 'Or' do the same shortcircuit (by means of stuff like 'Option ShortCircuit' or something like that (we already have 'Option explicit' and some other)
    Oddly... there's a reason why AndAlso and OrElse were added rather than shortcircuiting the original And and Or ... there is a great deal of code out there that (believe it or not) RELIES on that lack of shortcircuiting to work properly (bleh) ... personally I think thats bad architecting... but since you brought up the point of old code still needing to work the way it has, short circuiting And and Or wouldn't work... even with an appropriate Option... the Option wouldn't be fine enough... I might it in one spot in my code and not in another of the same code file.

    I'm just saying.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  13. #13
    Frenzied Member
    Join Date
    Jun 2013
    Posts
    1,404

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by SuperDre View Post
    Why restrict to only *.cls and *.bas, VB6 is more than those alone..
    To bring up a very clearly defined and somewhat easier to reach first goal which the new IDE/compiler-environment should accomplish only.

    I'd very much like when everybody could delay "dreaming about new features" (and also their implementations, if they are not "cheap" as e.g. unsigned integer-types and other, easier stuff which could go in already in a first throw)
    until this clearly defined first goal is reached.
    Jacob is absolutely right with his attempt to "put the whole thing to the test, just by starting somewhere"...
    I was trying (in what could be seen as a hijacking-attempt) to give the whole thing a reasonable "frame".


    0. Start an IDE-Project in VB6, which consists only of *.bas and *.cls modules and relies on a new, modern (already VB6-based) GUI-framework which is easily portable to Linux and other OS later on.
    (I numbered it as Step 0, because that would be the condition under which I would be willing to tackle that - everything else just does not make any sense, because there's already alternatives)

    1. Make *.bas and *.cls modules compile with this new IDE in a way as compatible to old VB6 as possible!
    Nothing more - but also nothing less ... recompile everything with the new compiler (selfhosting-state is reached).

    2. Discuss everything else after step 1 is finished ... (*.fm and *.ctl Import-Tools, enhanced ErrorHandling- and Stack-Reporting-functionality, Inheritance, ... )


    So, point 1 alone is challenging enough as a first step - but if it is reached, we could already compile the whole new GUI-framework,
    the whole new IDE (relying on that framework) and the new Compiler itself with what we produced so far (compiler-wise).

    The decoupling from the VB6-mothership would be reached.

    Quote Originally Posted by SuperDre View Post
    *.frm (and the usercontrol ones) are just as important..
    For those who see value in that and want to write VB6-compatible Widget-Control-Classes for at least the intrinsic (vbRuntime-contained) Base-Controls -
    this task should not be *that* difficult - this could be accompanied by Form-Designer-enhancements which understand (can parse and import) the older *.frm format.

    Quote Originally Posted by SuperDre View Post
    I know *.cls and *.bas are the easiest to do, but one of the reasons people tend to stick with their vb6 instead of opting to go for vb.net is due to the investment in created forms and usercontrols (which normally don't port so well to .NET).. A lot of people have just stuck to using the stock components and commoncontrols, so making sure those are at least available in the visual basic classic is almost a must (for people to want to use this 'community' driven language, instead of MS's visual studio .net). Also a lot of projects are using WINAPI for doing a lot of stuff so it also must be able to 'mimic' those..
    If we support *.bas and *.cls in a VB6-compatible way, then we offer already more than VB.NET, since a whole lot of VB6-code-investments would run without change ...
    Also (automatically) a given (with VB6-compatible *.bas and *.cls support) would be full Win32-API- or more generally spoken "Dynamic-Link-Library-Calling-support per Declare-Statement".
    (here one of the "cheap things, which could be newly introduced already in the first throw of the compiler" would be e.g. support for the __cdecl-calling-convention).

    As for "CommonControls-support" - this is a platform-dependent API, available per Win32-Dll-calls - and thus entirely possible to use, since "Dll-calls are supported".
    However, my vision of a new VB7 is "as much independence from MS or any other vendor as possible" - and I'd like to ask, what's wrong with "community-driven" languages or developer-platforms?
    Only those can avoid "further surprises with suddenly deprecated things" - or "new unwanted stuff, though forced down anybodys throat anyways".

    Quote Originally Posted by SuperDre View Post
    Just creating a new version of VB without supporting the already available 'commonly used' options for vb6 isn't a smart thing, as it still will keep a lot of developers of this new version as it will cost almost just as much time to port it to the new version as it is to porting it to VB.NET or C# (VS2013 even has a paste VB.NET code to C# code and vicaversa).
    I don't see much value in a roughly VB6-compatible new platform, when it is "Windows-only".
    I want to be able to move with a "VB6 compatible new IDE-and-compiler" to other platforms, should "Steve" decide, that Win10 will come with "Nose-Touch-only" (or some such thing).

    And in case we would base our new IDE and the whole GUI-concept of the new VB7-runtime on GDI/GDI+ and MS-CommonControls, then this platform-move would be extremely difficult (nearly impossible).

    So, what would you suggest instead of my (later on also opened and community-maintained) GUI-framework (which is already based on only VB6 *.cls and *.bas modules)?

    RealBasic is already platform-independent, True - but not community-driven - (and a bit bloated - we can do better in my opinion).

    Quote Originally Posted by SuperDre View Post
    Don't take this as an attack on your work as I only glanced over your site and I'm in the process of reinstalling vb6 on my home computer just to check it all out,
    Please do so - I can assure you, that the Framework is as powerful as GTK but (as said) already based on VB6 - and with a third of the binary-size of GTK.

    Quote Originally Posted by SuperDre View Post
    but just speaking as the devil's advocate: But you state yourself you're only interested in it if it's already using your RichClient-framework, whereas I think it should be (almost, at least like vb5=>vb6) 100% compatible
    As said - "True 100% compatible" it could be made in a second step - in the first step I'd be happy with a 99%-compatibility with regards to *.bas and *.cls.
    This simpler task will be something like a "touchstone" - and if we cannot even accomplish that as a community (gathering enough experienced Developers who really invest time and implement that),
    then everything else is just "cheap talk".

    Quote Originally Posted by SuperDre View Post
    But why even create your own IDE?
    Because I'm convinced that we can achieve a very *tightly* integrated IDE, which interacts in the same nice and raddish way with the compiler *and* the visual editor, as the old VB6-IDE does -
    only by implementing the whole thing ourselves.

    Quote Originally Posted by SuperDre View Post
    there are already excellent (free) IDE's out there for use with any language, like Eclipse..
    If you think, that it would be easier to write appropriate plugins for a (Java-driven and huge) IDE,
    which then achieves the same tight integration as the current (old) VB6-IDE, then you're mistaken (IMO).

    I'm absolutely convinced, that we can accomplish the same task in VB6! (not in Java) much easier (and in a final deployment-volume of under 5MB).

    Quote Originally Posted by SuperDre View Post
    Creating your own IDE is great ofcourse, but you still have the big problems of Debug-and-Run of your code, that's the hardest part to creating the IDE, and it's one of the BIGGEST reason why a lot of people used VB. Having an IDE for only Intellisense/writing/refactoring/whatever code and being able to compile it, isn't an interesting IDE, it took MS a long time to get VS.NET up to the same level of userfriendlyness as the VB6 IDE (VC++ developers were jealouse at the vb6 IDE back then)..
    I have a very clear notion (and done appropriate tests already) for Edit&Continue (based on Co-Routines and the tinycc-library, which will offer something like the current InIDE-PCode-Compiler, though C-based).
    But before we go into detail with regards to stuff like *that* I'd like to see, if the whole thing lifts off at all.

    Quote Originally Posted by SuperDre View Post
    Being able to use the current vb6 IDE and recompile to a new target would be a great thing already, there are already some examples of using that (vbthunder is a good one)..
    I'm not aware, that vbthunder ever accomplished a "recompilation to a new target" - in my opinion it was always the VB6-compiler (finally producing a x86-PE-binary only).
    Care to explain what you meant?

    Quote Originally Posted by SuperDre View Post
    Yes, I would want a real new VB7, but if it means having to invest just as much time as I have to when I go to another language, then it just isn't worth the time/effort profesionally speaking..
    If that is a somewhat blurred "but why not just use VB.NET and be done with it" statement - I think this cake is already eaten.
    Those who want to (or have to) use .NET, have switched already.

    Quote Originally Posted by SuperDre View Post
    I was also thinking about doing a real vb6 clone, so I'm definitly gonna keep my eye open for this project, and I'll certainly will speak my mind
    Not much to speak or "criticise" then, since all I would like to do at the moment is absolutely compatible with your wish to achieve "a real clone":
    Come as near to 100% VB6-compatibility as possible (and to ease things a bit, let's start with *.bas and *.cls only in a first step - then let's talk further).


    Olaf
    Last edited by Schmidt; Aug 21st, 2013 at 08:34 PM.

  14. #14
    Member
    Join Date
    Aug 2013
    Posts
    53

    Re: VB Classic (A True VB 7.0)

    Hi Olaf,

    I don't read SuperDre's comment

    Posted by SuperDre
    Yes, I would want a real new VB7, but if it means having to invest just as much time as I have to when I go to another language, then it just isn't worth the time/effort profesionally speaking..
    as

    If that is a somewhat blurred "but why not just use VB.NET and be done with it" statement
    It is more of a plea not to make the same mistake that Microsoft did with VB.Net (and the same mistake that RealBasic/Xojo, Basic for QT and the rest make). If you can't take a VB6 application and compile it it the new language without any significant coding changes (a migration tool or wizard would be acceptable) then it simply isn't going to attract VB6 developers.

    If you can't attract VB6 developers then this project will fail.

    Microsoft couldn't attract VB6 programmers to VB.Net despite 10 years of trying. Any language (no matter how much "better" than VB6 you tell us it is) needs to be upward compatible with VB6.

    That doesn't mean it needs to be able to compile for other platforms without change (developers accept that changes will be needed for different platforms) but it must be able to compile for Windows 32 bit as a minimum requirement. And it must be able to support ActiveXs/OCXs on Windows 32 bit.

    I agree with your plan of writing the IDE in VB6 then recompiling in VB7 as soon as possible (points 0 and 1 on your list). But point 2 should be a 100% upward compatible Windows 32 bit version.

    I, for one, wouldn't be interested in a product that offered me the ability to upgrade my VB6 programs with 'just a few months development work to get them running' - VB.Net has already made me that offer and I turned them down.





    .

  15. #15
    Frenzied Member
    Join Date
    Jun 2013
    Posts
    1,404

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by sten2005 View Post

    [SuperDre's comment and my reply]

    It is more of a plea not to make the same mistake that Microsoft did with VB.Net (and the same mistake that RealBasic/Xojo, Basic for QT and the rest make). If you can't take a VB6 application and compile it it the new language without any significant coding changes (a migration tool or wizard would be acceptable) then it simply isn't going to attract VB6 developers.
    Maybe I misread his statement (interpreting too much into it - sorry if that was the case) -
    but I wanted to make entirely clear, that I see this project as an entirely non-commercial community-effort -
    with open sources throughout - most of the open sources based on "upwards-compatible" VB6-code -
    later on "impossible to take that away" from the developers who engage themselves in this project
    (or will just use it as "consumers" and base their own code-investments on the compiler and new IDE).

    So what we have here (or should attempt here) is more comparable to FreeBasic/FreePascal-Lazarus than to VB.NET or RealBasic.

    Quote Originally Posted by sten2005 View Post
    If you can't attract VB6 developers then this project will fail.
    I'm not that sure about that, because the larger part of the project is already completed and was done without any help -
    if there's no people who will start working on "the rest of it", then I will drive it further on my own again.

    Quote Originally Posted by sten2005 View Post
    Microsoft couldn't attract VB6 programmers to VB.Net despite 10 years of trying. Any language (no matter how much "better" than VB6 you tell us it is) needs to be upward compatible with VB6.
    The reasons why MS couldn't attract *me* to .NET was less the obvious compatibility-issues than the loss of trust in the vendor.
    For example I found Silverlight (with its "reduced runtime-concept") very appealing technologically - but forbade myself to use it - because of the just mentioned "trust-issue" -
    and good thing that I did so, since it is just another deprecated thing now - code-investment and learning-efforts would have been "blown away just like that" for a second time...

    That said, please let's not drag this thread into a .NET debate ...

    As mentioned above, it will certainly help, when the new language is as compatible as possible to VB6 -
    and this will be automatically the case, when *.bas and *.cls will compile without larger changes.

    The rest you're talking about is "calling-compatible libraries" - and in this regard at least the basic runtime-functions (String-functions,
    math-functions, format- and convert-functions, etc.) will and have to be certainly compatible, to achieve the goal of *.cls and *.bas compatibility ...

    But then there's the whole topic of especially GUI-Components - and here I would like to use the
    occasion and provide and "upgrade" the "new VB" with a modern GUI-framework (which, as said, - is already finished and completely wrapped behind VB6-Code and -Classes).

    Now it would depend on the community - how compatible to the "existing and often used" GUI-components
    these new Widgets (as I call them) will be implemented.
    This project (vbWidgets) is already "started and in progress" on GitHub


    Quote Originally Posted by sten2005 View Post
    That doesn't mean it needs to be able to compile for other platforms without change (developers accept that changes will be needed for different platforms) but it must be able to compile for Windows 32 bit as a minimum requirement. And it must be able to support ActiveXs/OCXs on Windows 32 bit.
    I'd like when we would end up with a lot of (roughly) compatible GUI-Widgets which don't require CommonControls.ocx or FlexGrid.ocx anymore.
    The new Widgets will be portable to other platforms - we can take the new (Widget-based) IDE and make it work without larger problems on other platforms -
    and we can take "entirely Widget-based Apps" and those will run on other platforms (when the classbased runtime is ported) too.

    Sure - COM-support will be interesting for the Win-platform - and I'd like to support it not only for Win32 but also for Win64 (since compilation of true 64Bit-
    binaries is not really difficult, when we work over a C-Emitter).


    Quote Originally Posted by sten2005 View Post
    I agree with your plan of writing the IDE in VB6 then recompiling in VB7 as soon as possible (points 0 and 1 on your list). But point 2 should be a 100% upward compatible Windows 32 bit version.
    No problem - after all we start this whole project already on Win32 and not on Linux - so Windows will be the "first covered platform" in either case -
    but let's talk about details of point 2 after point 1 is finished.

    I for my part would not want a new VB7 which doesn't offer a new and modern GUI-concept (vector-based, antialiased Drawing, zoomable Controls) -
    those who want to use OCXes further (on Win32 only) could use VB6 further without problems.

    Quote Originally Posted by sten2005 View Post
    I, for one, wouldn't be interested in a product that offered me the ability to upgrade my VB6 programs with 'just a few months development work to get them running' - VB.Net has already made me that offer and I turned them down.
    The "driving force" behind my efforts is, to decouple from MS and 3rd-party dependencies as much as possible -
    to avoid anything like the "VB6-code-investments-disaster" in future projects.

    I take a "very long-term view" here - and want to achieve a really modern VB7, which is as backward-compatible as it gets -
    starting with full *.bas and *.cls compatibility - but already in this step using the new GUI-concept (which only requires *.bas and *.cls-support).

    And if "along the way" there's enough Developers who write 100% compatible Widgets for a lot of the "bread and butter-VB6-Controls" which are used
    and referenced in existing *.frm and *.ctl Files - then it shouldn't be that difficult, to parse those infos out of those File-Types and map the
    properties to the existing Widget-companions more or less 1:1.

    Existing VB6-projects will work as "existing and compiled VB6-projects" further (using the old compiler and IDE), as long as MS supports COM and the Win32-API.

    But in a new VB7 - I for my part would love to be able to apply my gathered VB6-skills further in *new* projects, which are behaving exactly
    as the old VB6-project - deterministic freeing of refcounted Class-instances - a Long being a signed 32Bit and an Integer 16Bit wide, etc. -
    API-Declares defined exactly as they were - absolute compatible BSTR- and Variant-Types... and so on.

    And I would like to compile those new projects to 64Bit - would like to run them also on different platforms - and would like
    to produce a modern an nice looking GUI with only a few lines of code, using the new capabilities of the cairo-based framework
    all bundled in a new, modern IDE.


    Olaf
    Last edited by Schmidt; Aug 22nd, 2013 at 09:11 AM.

  16. #16
    Member
    Join Date
    Aug 2013
    Posts
    53

    Re: VB Classic (A True VB 7.0)

    When I said "If you can't attract VB6 developers then this project will fail." I didn't mean you wouldn't get people to help develop a "VB7".
    I meant that when you have a finished and working VB7, you won't get VB6 developers to use it if it isn't truly upward compatible.
    That means taking an existing VB6 application and re-compiling it under "VB7" with little or no (manually coded) changes.

    I'm all for replacing Microsoft's common controls, but you can't replace every ActiveX that is still in use. In each and every VB6 application there may be specialist third party ActiveXs that it is not practical to replace, there may be widely used ActiveXs that no one has written a replacement for. And you need to support ADO and DAO too.

    Your "market" is those (tens of thousands ?) of VB6 users who want an updated language but require the update to be painless. Those developers have legacy VB6 applications to support and extend.
    If a VB6 developer can't compile the application they will (as you say) stick with VB6 on Win32. Most simply don't have the time or resources to do otherwise. What would be the point of a VB7 used by only a handful of developers whilst most VB6 developers stay with VB6 ?
    You need to offer a step-by-step approach, first show that all existing VB6 applications will work on VB7/Win32. Then add extra features. Then let us move forward to other platforms.
    "VB7" needs to (on 32 bit Windows) be able to use existing VB6 code as it is now (and if the 64 bit version could run 32 bit ActiveXs that would be even better).

    I note what you said about "loss of trust" in Microsoft. For the same reason I haven't used SilverLight or any other Microsoft developer tools since they dropped VB6. But the main reason I and many others didn't move to VB.Net was the lack of upward compatibility.
    If Microsoft launched their own VB7 tomorrow I would buy it.


    I haven't looked at your https://github.com/vbRichClient/vbWidgets but I will do.

    I have tried the http://www.vbforums.com/showthread.p...mmon-controls)
    and been very impressed.

  17. #17
    Hyperactive Member
    Join Date
    Aug 2010
    Location
    Canada
    Posts
    369

    Re: VB Classic (A True VB 7.0)

    I agree with Olaf's assessment of the steps to take to move forward. Based on Olaf's talents and vision for the project, I also propose that he should be the project "leader", insofar as we need someone to keep the project on task, and to have a final say in terms of controversial decisions and what gets committed to the main branch. Or are we looking to employ a more democratic approach?

    That said, I still have more questions at this point.

    Is the plan then to get started with a Git repository for the new VB6 programmed IDE project?

    What methodology should we have for accepting code modifications to the main branch? Should any particular developer interested in contributing create their own branch for making their own changes, which can then be merged into the main branch if accepted?

    Do we need some kind of coding standards document? We need to agree on naming conventions, how many space characters a tab should represent, etc...?

    What is the vision for the look of the IDE? Are we trying to replicate the old VB6 IDE, or create something new?

    Is the plan to use vbWidgets for the UI? If so do we need more widgets developed first before we have everything we would need to create an IDE?

  18. #18
    Frenzied Member
    Join Date
    Jun 2013
    Posts
    1,404

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by sten2005 View Post
    When I said "If you can't attract VB6 developers then this project will fail." I didn't mean you wouldn't get people to help develop a "VB7".
    I meant that when you have a finished and working VB7, you won't get VB6 developers to use it if it isn't truly upward compatible.
    I don't see it as extreme as you - please - just ask yourself: when there'd exist a "VB7" today, which is nearly 100% VB6-compatible in *.bas and *.cls .-
    completely "free and opensourced" - and totally easy to install and use (smaller 5MB download) - comes with a modern IDE/compiler which can create 32 and 64Bit Binaries
    and offers a new GUI-concept + a nice overhauled (but still small) Class-Runtime as well as a principle which promises true platform-independence -
    how many VB6-devs (even those who didn't help creating it) would not start experimenting with it?

    And if it indeed "delivers" (without crashes or otherwise "funny behaviour") how many would keep using it?
    Enough to establish a small (but growing) community I think (as e.g. Python which becomes more and more
    popular the more years "go by"...).


    Quote Originally Posted by sten2005 View Post
    That means taking an existing VB6 application and re-compiling it under "VB7" with little or no (manually coded) changes.
    Why would anybody want to recompile such a complex and fully working VB6 application?
    If you want to add a few modern GUI-gimmicks, then you can use appropriate COM-libs for that.

    Quote Originally Posted by sten2005 View Post
    I'm all for replacing Microsoft's common controls, but you can't replace every ActiveX that is still in use.
    I agree - and that's the reason why there will never be a 100% compatible "coverage" at the GUI- and Control-level.
    That's something one has to accept and swallow - maybe a good thing, when the alternatives to "established controls"
    are either (more or less) compatible - or offer other advantages (as: saving lines of code) which makes it "a snap or a relief to change over to them".

    Quote Originally Posted by sten2005 View Post
    In each and every VB6 application there may be specialist third party ActiveXs that it is not practical to replace, there may be widely used ActiveXs that no one has written a replacement for. And you need to support ADO and DAO too.
    But where do you see a problem there exactly?
    Maybe best, to bring a small and very concrete scenario, which explains where you see larger problems
    (as said, the new VB7 should support "external COM" at least for non-visual COM-Interfaces and -Classes).

    Quote Originally Posted by sten2005 View Post
    Your "market" is those (tens of thousands ?) of VB6 users who want an updated language but require the update to be painless.
    Those developers have legacy VB6 applications to support and extend.
    Best done further in VB6 then - if MS breaks something - then also the new (COM-supporting) VB7 would break for the same reasons.

    Quote Originally Posted by sten2005 View Post
    If a VB6 developer can't compile the application they will (as you say) stick with VB6 on Win32. Most simply don't have the time or resources to do otherwise.
    What would be the point of a VB7 used by only a handful of developers whilst most VB6 developers stay with VB6 ?
    I brought reasons, why VB7 could be attractive "nonetheless" already in my first statement (formulated as a question) at the top of this posting here.

    Quote Originally Posted by sten2005 View Post
    You need to offer a step-by-step approach, first show that all existing VB6 applications will work on VB7/Win32.
    No - that's not why I'd try to write (and later on use) a new VB7.

    How long do you think e.g. OLE/COM is still supported?
    Wouldn't you agree, that a Class-concept, which is roughly compatible with COM (and can use COM-classes, but is not dependent on COM)
    would be nice to have?

    Wouldn't you agree, that (in case OLE/COM-support vanishes from the OS) that it would be nice, to have roughly compatible Widget-Controls in
    a COM-independent (and also CommonControls or GDI-independent) encapsulation available?

    And wouldn't it be nice, when we could glue "all this new but roughly compatible GUI-stuff" together in the same way as we currently glue things together
    in the original VB6-IDE - and with nearly full compatibility in *.bas and *.cls modules?

    I'd be happy to have this option.

    One also doesn't know, how long the Win-platform will remain "open" for "other compilers or IDEs" at all -
    if it will be allowed in the future to compile your own "Standard-Executable" and run it ... or if "AppStore-Uploads"
    are the only way in future Win-Versions, to express ones creativity (with "MS-Tools only" then of course).

    If that is the case, then I want a VB7, which I can use with only smaller changes in the Class-Runtime-also on
    other platforms which don't have those restrictions.


    Quote Originally Posted by sten2005 View Post
    I note what you said about "loss of trust" in Microsoft. For the same reason I haven't used SilverLight or any other Microsoft developer tools since they dropped VB6. But the main reason I and many others didn't move to VB.Net was the lack of upward compatibility.
    If Microsoft launched their own VB7 tomorrow I would buy it.
    Well, I'd do the same perhaps...
    But I doubt that they come up with a new VB7 "after all those years".

    Quote Originally Posted by sten2005 View Post
    I haven't looked at your https://github.com/vbRichClient/vbWidgets but I will do.
    To check a few Demos out, you will need to download the BaseDlls first, followed by installing the latest vbWidgets.dll (from the GitHub-Repo).
    http://www.vbrichclient.com/#/en/Downloads.htm
    The above URL has the appropriate Links and hints for installation.

    Then you can check out a few of the higher-level Demos (to see what I mean with *.cls and *.bas only GUI).
    http://www.vbrichclient.com/#/en/Demos/GUI/

    Quote Originally Posted by sten2005 View Post
    I have tried the http://www.vbforums.com/showthread.p...mmon-controls)
    and been very impressed.
    That's a lot of (decent and well-done) work by Krool there...

    But as good as it is for existing VB6-Apps - in the new VB7 I would really like to stay away from deeper dependencies to MS-GUI-libs,
    to keep the platform-portability-option alive and "doable with not that much effort".


    Olaf

  19. #19
    Frenzied Member
    Join Date
    Jun 2013
    Posts
    1,404

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by jpbro View Post

    That said, I still have more questions at this point.

    Is the plan then to get started with a Git repository for the new VB6 programmed IDE project?
    Yes, will set an appropriate Repo up the next weeks.

    Quote Originally Posted by jpbro View Post
    What methodology should we have for accepting code modifications to the main branch? Should any particular developer interested in contributing create their own branch for making their own changes, which can then be merged into the main branch if accepted?
    Yes, that's easy enough with "forking a GitHub-Repo online" (into your own. previously created GitHub-account, which you can maintain and change against your local HardDisk independently).
    If you have "nice changes to contribute", then start a "Pull-Request" - (such Requests become visible on the GitHub-WebPage of the originator-Repo - and can be commented on - and later on
    merged into the main-branch ... thereby fulfilling this "Pull-Request" of the contributor with a "Merge-Response", so to say).

    Quote Originally Posted by jpbro View Post
    Do we need some kind of coding standards document? We need to agree on naming conventions, how many space characters a tab should represent, etc...?
    Yep, perhaps good to explain those things on the Main-Repo-page in a small "how-to-become a contributor" article (the GitHub-pages offer a Wiki for such things).

    Quote Originally Posted by jpbro View Post
    What is the vision for the look of the IDE? Are we trying to replicate the old VB6 IDE, or create something new?
    I'd try to mimick the old IDE (maybe just introduce some nicer Icons) as far as possible (the non-SDI-version I mean).

    Quote Originally Posted by jpbro View Post
    Is the plan to use vbWidgets for the UI? If so do we need more widgets developed first before we have everything we would need to create an IDE?
    [/QUOTE]

    From my point of view: Yes definitely - just look at other OpenSource IDEs as e.g. SharpDevelop -
    that's quite a code-volume which was accumulated there over the years - and if such a code-base is (overly) dependent on platform-libs and does
    not work through a GUI-Class-Layer (which offers a level of abstraction), then it becomes very difficult to port to other platforms (as Linux for example).

    Quote Originally Posted by jpbro View Post
    If so do we need more widgets developed first before we have everything we would need to create an IDE?
    The only two things which are missing in this regard is a cwPropertyGrid- and a cwEditor-Widget.
    The cwPropertyGrid is not that difficult - and the cwEditor-Widget could be wrapped by a simple Mockup first (based on a cwTextBox) for the first weeks -
    later on then replaced by a real Editor-Implementation, which interacts more tightly with the Tokenizer-result-structures.

    Olaf

  20. #20
    PowerPoster
    Join Date
    May 2002
    Posts
    25,984

    Re: VB Classic (A True VB 7.0)

    I'm largely trying to stay out of this .... heated discussion... but I'd like to just quickly address one question ... at least from my own perspective as a spectator in section 212....
    "Why would anybody want to recompile such a complex and fully working VB6 application?"
    Let me pose it like this... Why WOULDN'T I want to? Let's say I've got this grand application... it's been carefully maintained over the years... along comes VB7... I like it... it does what I need it to do... I want to port that application over to it... to help ease maintenance in the future... wouldn't it behoove me to first compile the existing app to make sure it can handle it? I'd be plenty ticked (maybe even fleaed) if I go to make some code changes only to find out that it won't compile now in the new and improved VB7.... no?

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  21. #21
    Frenzied Member
    Join Date
    Jun 2013
    Posts
    1,404

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by techgnome View Post
    I'm largely trying to stay out of this .... heated discussion...
    Is it really heated already ... so far I thought not.

    Quote Originally Posted by techgnome View Post
    "Why would anybody want to recompile such a complex and fully working VB6 application?"
    Let me pose it like this... Why WOULDN'T I want to?
    Because you shouldn't ... because VB6 is enough with regards to maintenance and the only thing which will ever be really "bug for bug-compatible".

    And if VB6-compiled Apps ever break, then they will break because MS changed something with regards to OLE/COM - or switched to 64Bit-only OSes.

    A "new VB7" which would support: "the whole ton of complex 32Bit-OCX-controls from 3rd party-vendors" fully (with all bells and whistles, bug for bug).
    would break too in this case.

    So let me ask you again, why would you force the "VB7-team" to come up with "full OCX support",
    when in the outlined case above (MS breaks OLE/COM) all those efforts would be for naught.

    Wouldn't it be better, to promote the other approach - and let the "VB7-team" state very clearly early on:

    - Look guys, we have achieved nearly 100% compatibility in *.cls and *.bas. ... that should help a great deal whilst you write and type code and copy&paste old routines or re-use whole modules and classes.
    - With regards to GUI-compatibility we recommend to use the *.frm-importer, which currently understands (and maps to) all intrinsic VbRuntime-Controls ... +
    - plus the following CommonControls: TreeView, ListView, ... also supported in the meantime is the MS-FlexGrid... more to come, please help us with other Control-Mappings...

    ... or something along those lines.

    If such a mapping-approach would be used, then one cannot guarantee a 100% compatibility anymore, because only the very basic Controls would behave in a similar way as the originals
    e.g. the VB-intrinsic controls like CommandButton, Label, PictureBox, List- and Combobox, TextBox shouldn't make larger problems ...
    But more complex controls - especially when those "got tuned" (sending Win-Messages to the hWnd of the underlying MS-Control-Class), then things get tricky and very messy, because the vbWidgets are Windowless Controls.

    Still this approach would be more "desirable over all" (IMO), because it cannot get broken by MS that easily.
    I can only repeat, if MS doesn't break anything - then VB6-compiler-output runs just fine with the old OCXes.

    I'm just trying to be realistic here - I have no interest in a heavily MS-dependent VB7, which will break along with VB6 (at the same time, when MS pulls the plug on a certain dependency).

    I'd like to invest the limited developer-resources we have into something which "remains", and can survive also on other platforms.

    If that means, that I cannot re-use "old OCXes" - then so be it - and as said, there will be options to map some OCXes against existing WidgetControl-classes -
    which could be enough for many smaller or midsized Applications, to make a potential porting-effort easier.

    Quote Originally Posted by techgnome View Post
    I'd be plenty ticked (maybe even fleaed) if I go to make some code changes only to find out that it won't compile now in the new and improved VB7.... no?
    As I tried to explain above - for me "a new VB7" is apparently something different from what you expect from such an effort (we are not MS and
    have much less developer-resources and will not be able to work full-time on something like that - so we have to choose carefully where we invest time).

    So again, to make it more clear for potential helpers too - this project (when finished) will not be able to read and import large and complex
    VB6-projects when those contain "a ton of 3rd-party-OCXes on 100dreds of Forms"...
    There will be mappings, which will sufficiently support simpler *.frm and *.ctl imports, especially when those contain intrinsic controls only -
    but everything else will get tricky and would cause larger efforts.

    Though it shouldn't be *that* difficult to e.g. fork the project at a certain point in time - and then use the MS-VC++ compiler
    (in conjunction with ATL and other COM-helpers) as the final backend which produces the binaries.
    In this case you could achieve a much higher OCX- compatibility in a new "VB7WinOnly" - but as said - this would then break along with VB6-produced binaries.


    Olaf
    Last edited by Schmidt; Aug 22nd, 2013 at 02:02 PM.

  22. #22
    Junior Member
    Join Date
    Aug 2011
    Posts
    28

    Re: VB Classic (A True VB 7.0)

    I think move our vb6 project slowly to linux and mac is more important than 100% VB6-compatible.
    Because vb6 is enought before 2022, vb6 can run in win8, maybe can run in win9.
    But microsoft will downfall and even die before 2022.
    So we need move our vb6 to vb7 to other platform slowly, better before 2022.
    Microsoft can die, this is he deserved, because he has abandoned so many developers.
    But our vb6 projects should not die, because we have invested so much time in it.

    But I think a command line vb7 compiler is important too.
    Last edited by mjohnlq; Aug 22nd, 2013 at 02:50 PM.

  23. #23
    Fanatic Member
    Join Date
    Apr 2012
    Posts
    631

    Re: VB Classic (A True VB 7.0)

    I haven't posted in this thread as yet but I am happy and willing to contribute to the VB7 IDE development effort. I am already a vbRichClient user and contributor to the vbWidgets repository on GitHub.
    If you don't know where you're going, any road will take you there...

    My VB6 love-children: Vee-Hive and Vee-Launcher

  24. #24
    New Member
    Join Date
    Jul 2013
    Posts
    8

    Re: VB Classic (A True VB 7.0)

    I am personally far more interested in having a good open source multi-platform VB7 to start new projects with, that in having a full upward-compatible one that relies in MS and other third-party OCX dependencies.

  25. #25
    New Member
    Join Date
    Aug 2013
    Posts
    8

    Re: VB Classic (A True VB 7.0)

    This is a really interesting topic and discussion.

    As a long-time VB6 developer who maintains several strong business applications with a small dev team I would like to tell you my thoughts on all of this:

    Compatiblity
    Of course a 100% compatiblity (binary+source) would be ideal. But of course that will be extremly hard to achieve without having access to the soruce code of the internal compiler and C2. All VB6 developers could be GLAD if a project like this would work and even if it only had 80% compatiblity - because it would mean that the language (and all the knowledge and invested time) would not be wasted. What I would think is a realistic goal is this:
    Let the plain source code be as compatible as possible, add a good converter for forms and try to add OCX support (even if not 100% compatible).
    OCX (not only controls but also libraries) is still heavily used to interact with 3rd party libraries and a lot of applications are simply depended on those libraries because they are either closed-source or the dev team just cannot afford to re-implement those features themselves. But, that being said, I for one would be absolutly willing to go bug hunting for a month and have some smaller incompatiblities to fix in the long run if that means I would gain longlivity and independence from Micrsoft for my applications, code base and. But without at least a solid OCX support a lot of apps can simply not be ported to VB7 and it can only be used for small-scale projects or new projects. Of course, event then I would prefer it to .NET.

    IDE
    I love the VB6 IDE because it's lightweight and extremly fast. So I would go for simple & fast first and later add support for 3rd party addons which could deliver all those nice features other monolithic IDEs have accumulated over the years. Fast is good!

    Framework
    A fast and good framework which would implement basic functions would completly suffice. Do not overdo this! More features can easily be added by 3rd party libraries. And if the component model allows for statically linked libraries that would be even easier to use 3rd party frameworks without a lot of hassle when it comes to redistribution.

    Language evolution
    I think this should be handeld very carefully - what we all DO NOT want is another .NET clone which is a clone but a tool that is easy to pick up for Beginners and powerful enough for real developers.

    Funding
    I am absolutly sure that there are a LOT of VB6 developers that would donate good money to bring a project like this on the road. I for one would gladly donate several hundred euros to a project like this if it seems to be a realistic and feasible solution to Microsoft horrible treatment of one of their strongest languages ever.

    Legal
    Do not forget about MS long arm. Try to check at least the most basic legal issues before starting a project like this. It would be devastiting if a project like this would be completed only to be shattered by Microsoft.

    I would love to see this project being a success.

    Dominik

  26. #26
    Member
    Join Date
    Aug 2013
    Posts
    53

    Re: VB Classic (A True VB 7.0)

    I'm going to look at http://www.vbrichclient.com/#/en/Demos/GUI/ and reply more fully when I have done so.

    But at this stage my thoughts are:

    If you are telling me that to convert my applications (with many forms and some third party OCXs) I am going to have to spend a long time rewriting them for VB7 then it isn't likely to happen. Microsoft suggested the same 10 years ago with VB.Net.

    If you are telling me I have to keep VB6 and keep my source code in VB6 that is just what I will do. I certainly won't keep one version in VB6 and another version in VB7. That would mean I would have to do every modification twice, once in VB6 and again in VB7. Don't forget that maintaining legacy applications doesn't mean just keeping them running. It means modifying and enhancing them, adding in the latest features (including nose-touch support if that's what the user wants) and giving them the look and feel of modern applications.

    I don't really see what you are offering that I can't do now using NSBasic AppStudio. With this you code using VB source code and it converts this to JavaScript. The approach seems to be similar to what you are advocating. You create forms and place controls on them (in a VB6 like IDE), then cut and paste VB code from VB forms into them. It has the usual controls, such as a TextBox (enhanced to let you specify if the input is numerical, text, dates, etc). You do modifications and enhancements in VB, it isn't a one-time convert and you don't need to know JavaScript. It doesn't support OCXs either. It targets iPad, iPhone and Android.

    My concern is you are making the same mistake that Microsoft did with Vb.Net. Deciding that language 'improvements' justify breaking upward compatibility. It didn't work for Microsoft. RealBasic put themselves forward as a VB6 replacement, PowerBasic tried the same. But again they weren't compatible. So we still use a 15 year old product - VB6.
    We aren't short of Basic languages, there are dozens to choose from. I want VB7 to be one we can use, not just another on the long list of incompatible languages.
    I believe that without offering a truly compatible (it doesn't need to be identical, you can use a migration tool & convert to your inbuilt widgets) upgrade so that existing VB6 source code (including forms, OCXs, DAO, ADO, calls to the Windows API, and so on) can be compiled on VB7 (for at least 32 bit Windows) you will lose the bulk of VB6 developers.
    I note you suggest a VB7 Win only fork using the C++ compiler to support OCXs. This may be the way forward. But I wouldn't have any real interest in VB7 until this was available.

    You ask if I would experiment with VB7.
    Yes of course I would.
    And after a day or so I would put it to one side, just like I did with VB.Net, with RealBasic, with Jabaco, with Basic for QT, with Gambas and the rest.

    If it ain't upward compatible it ain't VB.

  27. #27
    Frenzied Member
    Join Date
    Jun 2013
    Posts
    1,404

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by sten2005 View Post
    I'm going to look at http://www.vbrichclient.com/#/en/Demos/GUI/ and reply more fully when I have done so.

    But at this stage my thoughts are:

    If you are telling me that to convert my applications (with many forms and some third party OCXs)
    I am going to have to spend a long time rewriting them for VB7 then it isn't likely to happen. Microsoft suggested the same 10 years ago with VB.Net.
    If you are telling me I have to keep VB6 and keep my source code in VB6 that is just what I will do. I certainly won't keep one version in VB6 and another version in VB7.
    I was suggesting that, when you have a big fat VB6-application to maintain - then it is best to keep it in VB6.

    In addition you can program in VB7 all your "new Apps for the Desktop" with much better performance, more comfort than in e.g. NSBasic -
    and at the source-level fully compatible to old VB6-code.
    But if NSBasic is your tool of choice, because you only need "Buttons and TextBoxes and Labels" - and if JS-performance is entirely sufficient for you,
    then you surely don't need a native (optimizing) Compiler and also no modern GUI-framework.

    Quote Originally Posted by sten2005 View Post
    That would mean I would have to do every modification twice, once in VB6 and again in VB7.
    No, not if you use VB7 for new stuff and VB6 for old stuff.

    Quote Originally Posted by sten2005 View Post
    Don't forget that maintaining legacy applications doesn't mean just keeping them running. It means modifying and enhancing them,
    I know this scenario well enough - and so far cannot imagine where the problems are with that.
    Could you describe exactly (assuming a new VB7 took over your old project without problems), what you
    would do differently now (coding-wise) with regards to maintenance (modifying and enhancing existing code).
    In what way exactly would your VB7-based maintenance differ from VB6-based maintenance.

    Quote Originally Posted by sten2005 View Post
    adding in the latest features (including nose-touch support if that's what the user wants) and giving them the look and feel of modern applications.
    Sorry when it gets unnerving - but I'd really like to know, what kind of "latest feature" you are badly in need of - and would expect a new VB7 to offer to you.
    If it's only the "look and feel of modern applications" - then choose OCXes or other COMponents which offer that - sometimes just a manifest is enough.
    And the current vbRichClient5.dll is (in its current incarnation) a COM-lib - so you can use this new GUI-framework in good old VB6 too.

    Quote Originally Posted by sten2005 View Post
    I don't really see what you are offering that I can't do now using NSBasic AppStudio.
    ...
    You do modifications and enhancements in VB, it isn't a one-time convert and you don't need to know JavaScript. It doesn't support OCXs either. It targets iPad, iPhone and Android.
    As already said above, when this is entirely sufficient for you (with iPad, iPhone and Android-targets) then you're a happy guy - not much to say anymore.
    For me it would not be sufficient, I need e.g. a fast compiler and I want to write full-blown Desktop-Apps for Notebooks and PCs.

    Quote Originally Posted by sten2005 View Post
    My concern is you are making the same mistake that Microsoft did with Vb.Net. Deciding that language 'improvements' justify breaking upward compatibility.
    I think you overlooked (although already mentioned a few dozen times), that the new language will be nearly 100% compatible to VB6.
    And that language-improvements are not on the Todo-list currently - the compatibility in *.bas and *.cls (and coding-wise therefore also in Forms) is priority #1.

    Quote Originally Posted by sten2005 View Post
    It didn't work for Microsoft. RealBasic put themselves forward as a VB6 replacement, PowerBasic tried the same. But again they weren't compatible. So we still use a 15 year old product - VB6.
    We aren't short of Basic languages, there are dozens to choose from. I want VB7 to be one we can use, not just another on the long list of incompatible languages.
    As just mentioned above - the language itself will not be incompatible.

    Quote Originally Posted by sten2005 View Post
    I believe that without offering a truly compatible (it doesn't need to be identical, you can use a migration tool & convert to your inbuilt widgets)
    upgrade so that existing VB6 source code (including forms, OCXs, DAO, ADO, calls to the Windows API, and so on) can be compiled on VB7 (for at least 32 bit Windows) you will lose the bulk of VB6 developers.
    I can only state that again ... your list here:
    " (including forms, OCXs, DAO, ADO, calls to the Windows API, and so on) can be compiled ... (for at least 32 bit Windows)"
    is exactly what VB6 currently supports until MS decides to pull the plug.

    I don't really get, what is so difficult to understand in, that *if* a VB7 supports the above list in exactly the same way as VB6, that it is exactly as vulnerable (breakable) as VB6.

    An new VB7 should be source-compatible (and it will be that) - and "working in the IDE" should feel like working in VB6 -
    but otherwise it should encourage VB6-users, to decouple from MS-dependencies - and to also decouple from overboarding Win32-API-usage -
    to make it easier to shift to another OS-platform in case that becomes necessary.

    Quote Originally Posted by sten2005 View Post
    I note you suggest a VB7 Win only fork using the C++ compiler to support OCXs. This may be the way forward. But I wouldn't have any real interest in VB7 until this was available.
    I mentioned this "just for completeness" - if there's enough developers who support such a fork and bring it to an end successfully - why not.
    I for my part would consider that a waste - because you will end up with not much more than VB6 currently offers. It is not "the way forward" -
    it is the opposite in my opinion - it binds you to MS and it will make a platform-move much more difficult.

    Quote Originally Posted by sten2005 View Post
    You ask if I would experiment with VB7.
    Yes of course I would.
    And after a day or so I would put it to one side, just like I did with VB.Net, with RealBasic, with Jabaco, with Basic for QT, with Gambas and the rest.
    See, I don't even understand you in *that* regard (or behaviour) - if I don't have the intention to change to another development-tool,
    if I know already beforehand that it will be put aside finally, then I wouldn't even start experimenting with it.

    Olaf

  28. #28
    PowerPoster
    Join Date
    May 2002
    Posts
    25,984

    Re: VB Classic (A True VB 7.0)

    Olaf - I think the point that sten has been trying to make... and maybe I have this wrong... is that you're motivation for doing this (and let me add that I tip my hat off to you on this as I think you're probably the first most-level headed person to take something like this on in a sane and reasonable manner and is actually doing something about it... props to you...) is on the predication of when (I think we can all agree there is no if about it, it's a matter of when) MS drops VB6 run time support ... you're VB7 will still continue to run... right? Which is fine... so why should I (as a theoretical VB6 developer) wait until then? Why not go ahead and port over the existing VB6 code base to VB7 and get it over with, then it'll continue to run.

    Not only that, but then one could also take advantage of any additional features added to it.

    I think the biggest thing that I hear people complain about is that their VB6 wasn't able to run, with no changes ... much like when we moved from VB4 to VB6 (with a side trip through VB5 for some)... And that seems to be what Sten is looking for here... just take existing VB6 code run it through VB7 just as it is w/o having to change a darn thing.... geezes....VB developers a re a lazy bunch aren't we?


    This next bit isn't directed at anyone specifically, but meant as an attempt at putting some myths into proper context...
    I've been following VB.NET almost right from the get-go... I was at a Wrox Conference back in... well... just prior to the .NET release.. and attended a Q&A session with the team that built .NET... it was an eye opener and gave some insight into the why things are the way they are. In the years since, I keep seeing things like "MS dumped VB6" or "MS threw us [VB6ers] under the bus" or "they didn't care about the VB6 developers" ... I can say that those kinds of statements are false. It's not like someone woke up one day and said "hey, let's f* with VB6 developer and create this all new platform that will cause them to re-write everything and all existing code won't work... muwhahahaha!" ... There was a major effort o get VB6 rolled into .NET PROPERLY... problem was with the compiler... the end result was something that would have been so complex that stability of not only the compiler but also the IDE and the apps would have been compromised. It wasn't an easy decision, and there were many months and countless hours trying to hash it out... they just couldn't get it to work in a reasonable manner.

    Ok, I'll slink back into the shadows now...

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  29. #29
    Member
    Join Date
    Jul 2013
    Posts
    47

    Re: VB Classic (A True VB 7.0)

    This is to anyone in special, but I think one shouldn't be too radical at this stage.


    In my opinion, Olaf's project is a good project and started with the right foot, and - maybe the most important part - is very useful already. By using his "framework" within VB6 one have access to things A LOT better than the equivalent provided by VB6, and it adds lots a modern/new stuff right out-of-the-box: SQLite usage in a similar way to ADO, Cairo drawing (Forms, Widgets, PDF, SVG, among others), Physics engine, TCP, RDP, Reg Free Dll ActiveX, Touching Screen (Gesture), MM Device, OpenOffice/LibreOffice usage, Browse control (WebKit), and a lot more. Being a "one man work" so far, he deserves already the respect of all of us, and the faith that he will get the job done.


    I use his SQLite wrapper for a few years, and I'm now starting with the Cairo stuff, and all my future development will depend on the rest of the provided stuff whenever possible, and (again in my opinion) using his stuff is the right way to get in touch with the full project and to "have a say" about it.


    Personally, I'm not interested in the VB compatibility by itself (thought I understand who is), but the feeling of a possible Windows independence is good, pretty good. I think, however, that it's more important to make sure that programs based on VB7 will work in Linux with Wine. This way one could still use OCXs, SxS, and many good things that we only have with Windows (being able to use 3rd party libraries like TX TextControl, FarPoint Spread, ComponentOne, and the like, it's probably very important for many of us). Anyway, the reduced Windows dependencies is a step forward for this to happen. Even for who needs .NET I think it's easier to use Wine than Mono.


    Just my 2c

  30. #30
    Frenzied Member
    Join Date
    Jun 2013
    Posts
    1,404

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by techgnome View Post
    I think the point that sten has been trying to make... and maybe I have this wrong... is that your motivation for doing this
    ... is on the predication of when ... MS drops VB6 run time support ... your VB7 will still continue to run... right?
    Basically right *). But only in case your: "MS drops support for the vb6Runtime" is meant as: "VB6-apps will stop working, no matter what one will try,
    because MS removed (or just blocked) critical dependencies deliberately - or is forcing a '64bit only' - or 'WinRT-only' onto the new OSes.

    *)(I'm just trying to be precise here, because technically: "dropping support for the vb6Runtime" is in no way dangerous for VB6-apps ...
    ...one can install-and-deploy the vb6Runtime then in the same way as in the days of Win95, when it didn't come preinstalled on the OS).


    Quote Originally Posted by techgnome View Post
    Which is fine... so why should I (as a theoretical VB6 developer) wait until then? Why not go ahead and port over the existing VB6 code base to VB7 and get it over with, then it'll continue to run.
    Not only that, but then one could also take advantage of any additional features added to it.
    I'm all for it - please port to the new VB7 as soon as it becomes available and stable.
    But then do it in a "healthy way" - or just leave it be (meaning: stick with VB6).

    Maybe an example can help (a somewhat simplified one, to keep things straight):

    You have a VB6-application which utilizes (and here our simplification kicks in) *only* the MSHFlexGrid.ocx -
    (on some Forms) - all the rest on your Forms is made out of intrinsic Std-Controls (Labels, TextBoxes, Combos).

    Now assume, we are in 2018 - and MS announces, that the next OS-version will only support 64Bit-Apps -
    and will dismiss the SYSWOW64-stuff (the 32Bit-library-layer) all-together.

    That means, that neither the vb6Runtime will work on those new OS - nor will any other 32Bit-binary
    (neither your MyFlexApp.exe nor the MSHFlexGrid.ocx) work anymore on such a 64Bit-only platform.

    It was announced that the new OS will come out in 2 years, so you have some time still ...
    also announced was (from the "happy and thriving VB7-community" <g>) that the 64bit-binaries it produces,
    as well as the 64Bit-vb7Runtime-classes will work further on the new OS) ... but Ok, what will you do?

    Your Application needs to be ported to one of the languages/compilers which can produce binaries
    which will continue to run on this new Win-OS.

    You call your friend Fred, who was constantly pointing out to you, how good he fared with .NET,
    since it even supported the usage of MSHFlexGrid.ocx in his WinForms-App (he was a fan of the
    Grid as well as you and too lazy to learn "a new one" whilst porting over) ... you hang up disappointed,
    because he was telling you, that he's now in the process to re-write all his FlexGrid-code, since
    his .NET based App would not run on the new OS either, due to this dependency.

    Now you call Bob, who was promoting a VB7-fork "with full support for OCXes" to you some time ago-
    but you discover, that he has the same problems as Fred - his MSHFlex-dependent applications
    will not run on the new OS - he will have to rewrite larger parts.

    Now you remember a discussion you had some 5 years ago (with a guy you didn't like very much,
    because of his: "acts as if he knows everything"-attitude) who told you at that time, that
    it doesn't make any sense to support OCXes in VB7 - that it would be better to work on
    mappings to Widgets which are fully supported by the new GUI-runtime of VB7 instead.

    And that one has to bite the bullet in replacing those OCX-dependencies - writing code,
    to work against alternative Grid-Widgets (the less adaption-code to write, the more interface-
    compatible to existing OCXes those Widgets are).

    Though that sounded like work to you, so you stuck with the "just use VB6-further until it breaks"-
    approach ... but as said - you still have two years - what will you do (since "learning a new Grid" is mandatory now) :

    - use .NET which is less compatible at the SourceCode-Level than "the new VB7"
    - use the VB7-fork which supports OCXes (also 64Bit-versions of them) - but as seen, is pretty dependent on MS-tech (which can break any time)
    - use the "original VB7" which always had platform-independence and decoupling from as much 3rd-party-libs as possible in mind, and in the meantime also runs on Linux.

    Quote Originally Posted by techgnome View Post
    I think the biggest thing that I hear people complain about is that their VB6 wasn't able to run, with no changes ... much like when we moved from VB4 to VB6 (with a side trip through VB5 for some)... And that seems to be what Sten is looking for here... just take existing VB6 code run it through VB7 just as it is w/o having to change a darn thing.... geezes....VB developers a re a lazy bunch aren't we?
    Yep, seems so - can't do much about that - but the example I've just brought, points out some of the issues in that regard (when "reality just sucks").
    <shrug>

    Quote Originally Posted by techgnome View Post
    This next bit isn't directed at anyone specifically, but meant as an attempt at putting some myths into proper context...
    I've been following VB.NET almost right from the get-go... I was at a Wrox Conference back in... well... just prior to the .NET release.. and attended a Q&A session with the team that built .NET... it was an eye opener and gave some insight into the why things are the way they are. In the years since, I keep seeing things like "MS dumped VB6" or "MS threw us [VB6ers] under the bus" or "they didn't care about the VB6 developers" ... I can say that those kinds of statements are false.
    Nope, they are not - definitely not.

    Quote Originally Posted by techgnome View Post
    It's not like someone woke up one day and said "hey, let's f* with VB6 developer and create this all new platform that will cause them to re-write everything and all existing code won't work... muwhahahaha!" ...
    It is still possible, to write (and compile) C++ code without any .NET-dependencies, the continuing VC++ compiler-versions are still well-maintained and able to produce COM-binaries.
    COM, which never was dead as a technology (just another lie from MS at that time) and which with WinRT sees a promotion into the top-tier even now.

    So what exactly do you think made it *impossible* for MS (with those huge developer-resources), to provide the same "continuing C++compiler technology"
    in the same fashion as before (with C2.exe along with VB5 and VB6) in a continued Classic-VB-branch?
    You don't seem to know the story, that a VB7 (the true one) was already semi-finished and at least in Beta-stage - even presented at the german BASTA-Developer-conference (somewhere around 2000, don't know the exact date anymore).


    Quote Originally Posted by techgnome View Post
    There was a major effort o get VB6 rolled into .NET PROPERLY... problem was with the compiler... the end result was something that would have been so complex that stability of not only the compiler but also the IDE and the apps would have been compromised. It wasn't an easy decision, and there were many months and countless hours trying to hash it out... they just couldn't get it to work in a reasonable manner.
    Well, they lied to you - and found a happy believer as it seems.

    Olaf

  31. #31
    New Member
    Join Date
    Aug 2013
    Posts
    8

    Re: VB Classic (A True VB 7.0)

    One word before I start writing: I will simply use "OCX" for controls and ActiveX DLLs because it's convenient ;-)
    I always mean ActiveX Controls (OCX) and ActiveX DLLs since the technology they are based on is virtually identical.

    I do not see your point in arguing that it would be better to move away from OCX now because it's support could be dropped by Microsoft later on.

    As a developer I search replacement for a compiler and an IDE that is not officially supported any more but still want to keep using external libraries that are very well supported. A lot of 3rd party OCX developers offer up-to-date versions of their controls and libraries. It's not like OCX is dead - not by any means.

    If there was a VB7 that would support OCX that would mean I could concentrate on porting the source of my main app to VB7 now and deal with dependencies of 3rd party (or my own for that matter) libraries when the time comes or I have time to spare. If it would not support OCX it's an "all or nothing" gamble that costs a lot more time and money. Also there is no garantuee that all of the external functionality can be added in a reasonable timeframe (if at all).

    Also: If Microsoft would drop OCX support, the developers of said 3rd party libraries would have to move on themselves and would probably provide new versions of their controls and libraries in another form that could by used by developers.

    If you start removing 3rd party functionality from your source just for the hell of it you either have no budget that needs to be held (i.e. academic/hobby developer) or have more than enough money to spend for a project that could consume thousands of dollars/euros worth of developer time (depending on how much 3rd party technology you embed and how critical it is to your project) which is a luxury not many developers can afford.

    Don't get me wrong: If it would be a financially viable solution I would gladly remove all 3rd party dependencies but for the forseeable future that is just not an option for me.

  32. #32
    Member
    Join Date
    Aug 2013
    Posts
    53

    Re: VB Classic (A True VB 7.0)

    Hi Olaf,

    My apologies for the delay in replying, I've been on-site at a large user discussing upgrading their VB6 applications to Windows 8 - work has to come first

    There was probably too much detail in my last post (and therefore in your reply). Let me try again...

    I am very impressed that someone (you) who seems capable of bringing a VB7 project to fruition has stepped forward. I support virtually everything you have put forward for this project.
    My disappointment is that you don't see the importance of maintaining upward compatibility from VB6 to VB7. I believe without this this project will ultimately fail (I don't mean that I think you won't complete the project, I mean that the uptake of VB7 by the VB6 community will be negligible). If a VB6 developer can't take an existing VB6 application and recompile it under VB7 with the minimal amount of work they will not move to VB7.

    When I said
    My concern is you are making the same mistake that Microsoft did with Vb.Net. Deciding that language 'improvements' justify breaking upward compatibility.
    I worded that rather loosely. I didn't mean "language" in the tightly defined meaning which you obviously read it, I meant it to refer to the whole VB7 "package" - that is language, IDE, OCX support, and everything else.
    Please read that line as "My concern is you are making the same mistake that Microsoft did with Vb.Net. Deciding that VB7 package 'improvements' justify breaking upward compatibility."
    Also I am using "OCX support" as shorthand to mean support for ActiveX/OCXs, for Windows API calls, for DAO and ADO support, etc.

    Again when I said
    So we still use a 15 year old product - VB6.
    We aren't short of Basic languages, there are dozens to choose from. I want VB7 to be one we can use, not just another on the long list of incompatible languages.
    I was again referring to the whole "package" not specifically the language.

    My concern is that when you complete VB7 you will have a product to be proud of; but most of us VB6 developers will be using a 20 year old product - VB6.

    You say
    I can only state that again ... your list here:
    " (including forms, OCXs, DAO, ADO, calls to the Windows API, and so on) can be compiled ... (for at least 32 bit Windows)"
    is exactly what VB6 currently supports until MS decides to pull the plug.

    I don't really get, what is so difficult to understand in, that *if* a VB7 supports the above list in exactly the same way as VB6, that it is exactly as vulnerable (breakable) as VB6.
    There is nothing difficult to understand there. But you are proposing a product that breaks this now. Microsoft may or may not break it at sometime in the future.
    It is a concern that Microsoft breaks VB6 support but I note the following points:
    • Moving to VB7 with OCX support would at least replace Microsoft common controls
    • VB7 with OCX support would work on Windows 32bit (& hopefully Windows 64 bit and Linux using WINE ?)
    • We gain time to look at either replacing OCXs or at producing 'Lite' versions of the applications without OCXs to run on tablets etc.
    • Windows (probably) isn't going to go away - even limiting applications to Windows only would still be useful
    • Microsoft's support statement for VB6 promises support until 2023 (on Windows 8) - presumably therefore VB7 with OCX support wouldn't break either.


    You say
    See, I don't even understand you in *that* regard (or behaviour) - if I don't have the intention to change to another development-tool,
    if I know already beforehand that it will be put aside finally, then I wouldn't even start experimenting with it.
    It is far from not having the intention to change to another development tool, it shows the difficulty of finding an acceptable development tool. VB.Net, RealBasic, PowerBasic, Jabaco and the rest don't meet the requirements - for several reasons but mainly the lack of upward compatibility from VB6.

  33. #33
    Frenzied Member
    Join Date
    Jun 2013
    Posts
    1,404

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by sten2005 View Post

    [OCX-support]

    ... you are proposing a product that breaks this now.
    No, a "breakage" would be, when VB7 ("originally") came with OCX-support and when this support
    would be removed in an later upcoming version.

    As I see it, we have a fully OCX-supporting (and still nice) VB6-IDE.

    And if the project lifts off, then we have in one or two years a VB7, which is VB6-code-compatible,
    supports all kind of Declare-definitions - supports Classes and Class-libraries - and a new GUI-concept
    (with a lot of already existing Control-alternatives in form of the new Widget-classes).

    We'd have that in addition to VB6 (and in VB6 one can use the same Widget-Classes in a calling-compatible way too BTW) ...
    so if we (as a community) would use the following years (I assume we still have a decade or so, until MS pulls the plug on VB6 in one way or another)
    if we would use those years to round up a nice package of Widget-classes (all community-maintained, free to use by everybody) -
    then the discrepancy between "commercial OCXes" and "community-based Widgets" would not be that large.

    Quote Originally Posted by sten2005 View Post
    Microsoft may or may not break it at sometime in the future.
    It is a concern that Microsoft breaks VB6 support but I note the following points:
    • Moving to VB7 with OCX support would at least replace Microsoft common controls
    • VB7 with OCX support would work on Windows 32bit (& hopefully Windows 64 bit and Linux using WINE ?)
    • We gain time to look at either replacing OCXs or at producing 'Lite' versions of the applications without OCXs to run on tablets etc.
    • Windows (probably) isn't going to go away - even limiting applications to Windows only would still be useful
    • Microsoft's support statement for VB6 promises support until 2023 (on Windows 8) - presumably therefore VB7 with OCX support wouldn't break either.
    You also didn't answer my previous question (with regards to, that the whole list above is already supported by VB6, and what you expect a VB7 to
    provide you in addition).

    Please see my reply to WhyWontIEdieAlready, where I asked the same thing (but also answered it from my point of view).

    Olaf
    Last edited by Schmidt; Aug 23rd, 2013 at 11:57 PM.

  34. #34
    Frenzied Member
    Join Date
    Jun 2013
    Posts
    1,404

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by WhyWontIEdieAlready View Post
    One word before I start writing: I will simply use "OCX" for controls and ActiveX DLLs because it's convenient ;-)
    ...
    Arrggghhh - just discovered, that my detailed reply to your posting above (about one hour of work) was somehow "lost in transmission" -
    not sure why or what has happened, maybe a moderator has the ability to discover something at the serverside and can restore what I've sent?

    Olaf

  35. #35
    Software Carpenter dee-u's Avatar
    Join Date
    Feb 2005
    Location
    Candon City, Ilocos Sur, Phils.
    Posts
    10,829

    Re: VB Classic (A True VB 7.0)

    When are you guys going to end the discussions and start working on this?
    Regards,


    As a gesture of gratitude please consider rating helpful posts. c",)

    Some stuffs: Mouse Hotkey | Compress file using SQL Server! | WPF - Rounded Combobox | WPF - Notify Icon and Balloon | NetVerser - a WPF chatting system

  36. #36
    Member
    Join Date
    Aug 2013
    Posts
    53

    Re: VB Classic (A True VB 7.0)

    Your view seems to be the same as that of Microsoft when they brought out Vb.Net. "Move to our shiny new language(package) - but your legacy code is your problem". That didn't persuade VB6 developers to move to VB.Net and it won't persuade them to move to VB7 either.

  37. #37
    New Member
    Join Date
    Aug 2013
    Posts
    8

    Re: VB Classic (A True VB 7.0)

    @schmidt

    Oh, that sucks :-(

    If it does not turn up, could you at least post the essence of your thoughts? Contrary to dee-u I think this is an important discussion - event though it's a topic that got heated rather quickly.
    Also, for the record, I think that even a VB7 without support for OCX-Controls and Active-X-Dlls would be a good thing, but it does not seem to be a viable option for a lot of existing projects. But from my standpoint it would not help my current situation that much without said support.

    I am also not sure why you think that OCX/ActiveX support is a bad idea. Yeah, it may break in the future, but it would help with converting projects today.

    Let's compare:

    VB.NET does support OCX/ActiveX DLLs but did not support an easy way to port the source without major code changes.
    The VB7 you suggest would allow easy porting of code but would not allow OCX/ActiveX integration.

    Both is a big problem for me.
    With VB.NET I would need to rewrite about 250k Lines of Code - I just cannot afford that.
    With a VB7 without OCX/ActiveX support I would have to port all of our own components and libraries to another component model or make them static and also I would have to search replacements for several 3rd party libraries that are used for some critical features. That is something I also cannot afford.

    So, yeah I think VB7 is a good idead - event without OCX/ActiveX support. But wihtout that support it would sadly be not an option for me (and I think for a significant number of other developers).
    I still would appreciate it and certainly would have a look and maybe start new projects in VB7 because having an open source IDE/Framework/compiler for a langauge I am more than familiar with is still a good thing - but not for my existing stuff that needs to be maintained for the foreseeable future.

    As I see it: If we had VB7 with OCX/ActiveX support we could port our projects now and hopefully enough 3rd party developers would support that system natively (without ActiveX) so that when and if the time comes and Microsoft pulls the plug on ActiveX we would be ready.

    Dominik
    Last edited by WhyWontIEdieAlready; Aug 24th, 2013 at 05:29 AM. Reason: Added recipient

  38. #38
    Software Carpenter dee-u's Avatar
    Join Date
    Feb 2005
    Location
    Candon City, Ilocos Sur, Phils.
    Posts
    10,829

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by WhyWontIEdieAlready View Post
    Contrary to dee-u I think this is an important discussion - event though it's a topic that got heated rather quickly.
    The thing is, this has rather just became a discussion and it might just end up just a discussion with no result just like LightFusion.
    Regards,


    As a gesture of gratitude please consider rating helpful posts. c",)

    Some stuffs: Mouse Hotkey | Compress file using SQL Server! | WPF - Rounded Combobox | WPF - Notify Icon and Balloon | NetVerser - a WPF chatting system

  39. #39
    Member
    Join Date
    Aug 2013
    Posts
    53

    Re: VB Classic (A True VB 7.0)

    Quote Originally Posted by WhyWontIEdieAlready
    VB.NET does support OCX/ActiveX DLLs but did not support an easy way to port the source without major code changes.
    The VB7 you suggest would allow easy porting of code but would not allow OCX/ActiveX integration.

    Both is a big problem for me.
    With VB.NET I would need to rewrite about 250k Lines of Code - I just cannot afford that.
    With a VB7 without OCX/ActiveX support I would have to port all of our own components and libraries to another component model or make them static and also I would have to search replacements for several 3rd party libraries that are used for some critical features. That is something I also cannot afford.
    Me too ! And I guess this applies to many in the VB6 community.

    So, yeah I think VB7 is a good idead - event without OCX/ActiveX support. But wihtout that support it would sadly be not an option for me (and I think for a significant number of other developers).
    And sadly not an option for me either.

  40. #40
    New Member
    Join Date
    Aug 2013
    Posts
    8

    Re: VB Classic (A True VB 7.0)

    @dee-u

    Yes, that is a risk and I agree that seeing progress and getting a start is very important.

    But I think especially the question of the desired target level of compatiblity is so important, that it needs to be discussed before.
    Otherwise people may invest time and be disappointed afterwards or the project might fail because of not laying some important ground rules/specs before.
    Last edited by WhyWontIEdieAlready; Aug 24th, 2013 at 05:28 AM.

Page 1 of 3 123 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

Survey posted by VBForums.