-
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 :rolleyes:
http://www.vbforums.com/showthread.p...ht=lightfusion
-
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
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
-
Re: VB Classic (A True VB 7.0)
Thankfully someone stepped up to the plate. :bigyello:
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++).
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
Jacob Roman
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
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
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
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
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
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
-
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
-
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.
-
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.
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
Jacob Roman
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
-
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? ;)
-
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)?
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
Schmidt
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
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
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..
-
Re: VB Classic (A True VB 7.0)
Quote:
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
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
SuperDre
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
*.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
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
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
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
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
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
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
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
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
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
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
-
Re: VB Classic (A True VB 7.0)
Hi Olaf,
I don't read SuperDre's comment
Quote:
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
Quote:
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.
.
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
sten2005
[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
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
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
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
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
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
-
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.
-
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?
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
sten2005
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
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
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
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
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
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
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
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
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
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
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
jpbro
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
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
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
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
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
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
-
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
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
techgnome
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
"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
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
-
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.
-
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.
-
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.
-
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
-
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.
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
sten2005
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
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
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
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
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
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
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
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
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
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
-
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
-
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
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
techgnome
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
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
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
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
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
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
-
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.
-
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
Quote:
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
Quote:
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
Quote:
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
Quote:
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.
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
sten2005
[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
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
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
WhyWontIEdieAlready
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
-
Re: VB Classic (A True VB 7.0)
When are you guys going to end the discussions and start working on this?
-
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.
-
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
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
WhyWontIEdieAlready
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.
-
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.
Quote:
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. :(
-
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.
-
Re: VB Classic (A True VB 7.0)
As for me, I hope:
step 1. develop the vb7 compiler that can compile the old vb6 .cls and .bas to a console .exe file, as possible as VB6 language compatible. the compiler can run on linux and windows, maybe can based on llvm. this step no need support ui controls files such as .frm or .ctl files. but need develop the file and network and other no-ui class library that needed by the ui-controls, all these library file are .cls and .bas file.
step 2. develop the vb7 controls with the same names as the old vb6, the vb7 controls can based on vbRichClient or wxWidgets or qt or others. the controls need can compiled use the compiler developed in step 1.
step 3. develop the vb7 compiler that can compiler the old vb6 .frm and .ctl and .res files use the controls developed on step2, after this step, all the vb6 projects that didn't use the activex controls can be compilered and run on linux and windows.
step 4. develop the vb7 compiler that can support activex control on windows, to do as possible as VB6-compatible on windows.
step 5. develop the vb7 IDE that only use the controls develop in step2, then the vb7 ide can run on windows and compile old vb6 project, and the ide can open the vb6 projects on linux.
Then, all my vb6 project can opened on the new vb7 ide and can compiled and run on window. And on linux need do some modify to compiled and run on linux, so can move all my vb6 projects slowly from windows to linux.
-
Re: VB Classic (A True VB 7.0)
Whoaa, too many replies to answer them all "as carefully" as I did before - so please forgive me, when in the following I will "brush over it"
in a fast (and rough) way - please don't take anything personally - I just want to make my position more clear, even if it "hurts" somebody.
So here my "staccato answers" to the postings in the order they came up:
@dee-u:
> "When are you guys going to end the discussions and start working on this?"
Good point - let's stop talking - either you help - or you don't (well - and I note from your wording above, that you don't count yourself among the helpers)
@sten2005:
> "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."
To make it short - I don't care who is "persuaded to move to it later when its finished" (since that doesn't help me much with the problems at hand) ...
VB6 is still entirely sufficient for many things - and so there's apparently not much real pressure on the VB6-devs - later if that pressure increases in the future,
then those developers will start looking for alternatives - and I hope that (among the different choices, which are then available in 5-10 years time),
that VB7 stands out with a compiler which is the most compatible to the VB6-language - and with an IDE which is also very familiar, and with native Widget-Controls
which look and feel familiar too.
@WhyWontIEdieAlready (Dominik)
> if it does not turn up, could you at least post the essence of your thoughts?
I've explained my plans, how to achieve component-model-libs which offer selfdescribing classes -
and that I think I can manage this in a way which is rather compatible to COM - though still remains platform-portable.
So, for COM-Dlls there is a high probability that access to COM-classes will be available - though OCXes are interface- and
also siting-wise an absolutely over-engineered and complex thing MS cooked up there - and I'm not willing to support this
clumsy approach directly in the new language-runtime and the compiler - the new Widget-concept is based on just two
interfaces - "just a normal class", and siting-wise also totally easy to handle (and will be fully platform-portable).
That was basically the essence of the technical background.
> "Contrary to dee-u I think this is an important discussion - event though it's a topic that got heated rather quickly."
It is - those who are about to invest time (which apparently is not dee-u's intention) deserve a little bit of a "roadmap-explanation"
and where the whole thing is supposed to end up.
> "Also, for the record, I think that even a VB7 without support for OCX-Controls and Active-X-Dlls would be a good thing, "
Yep, the full *.cls and *.bas support alone should everybody "make dancing with joy" here (at least, so I thought) -
and as said, ActiveX-Dlls will very likely be supported - because that's not really difficult - when the Class-concept of the
new compiler is pretty compatible to the COM-base interfaces and appropriate VTable-structures and -behaviours.
> "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."
As said, your current situation is not really "dire" - you have a well enough working VB6 still.
The question I was asking you in my lost posting (and also sten2005, but he didn't care to answer it) was:
"What do you expect from a VB7, which VB6 cannot offer to you these days too."
And for my part I answered it with:
First and foremost: platform-independence, a community-based source-base nobody can take away "from us" in the future - and VB6-code-compatibility.
(and a few other things of course, but those are secondary).
VB7 shall be (in my thinking) a tool which "nobody is able to break anymore" - but if it ties itself (with its runtime-roots) too deeply to MS-approaches one can find only on the
Win-platform, then we loose that strongest of its features - that's why OCX-support is entirely secondary in my thinking - if there's enough contributors for that, then it
will come later in a sideward-docking approach, which is offered in addition to the Runtime-supported NativeWidgets (nothing is impossible to accomplish, binding-wise - with a C-compiler in the backend).
> "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."
Those projects would (after conversion) break in the same way as when you'd have left the OCXes in your VB6-project - I still don't understand, why nobody sees the logic behind that.
If you port something, then port it decently (in a way that will not break in the next 10 years at least).
A tool which will offer both: platform-independence over its native Widget-concept, but also full compatibility to OCXes and older VB6-Controls -
that's asking too much from a community-project with (yet) limited man-power.
Let's finish the first round - see where we end up (and how large the team is at that point in time) - then move further and decide which
additional features go up or down on the priority-list.
> "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."
Well, you forgot: VB6 offers full support for OCXes/AXDlls and is fully compatible to VB6
> "Both is a big problem for me. "
And why is that - please ask yourself truly, why it comes, that you consider that a big problem.
Is it not the fear, that MS will break something in the future, which will render VB6-Apps useless?
I can only tell you again - if that your fear was well-founded and MS will break something that renders VB6-apps useless,
then a highly compatible designed VB7-compiler, which offered fulll OCX-support will be broken too.
What you could think about instead is: what tools can make such a potential future breakage more bearable (with the least over-all-efforts)?
And when there's something out there, which has "we will be unbreakable" written in bold letters all-over its flag -
and is nearly fully VB6-code-compatible - wouldn't that project worth a thought from your end - would it be worthy of your support?
> "So, yeah I think VB7 is a good idead - event without OCX/ActiveX support.
Thanks - thought so too. :)
> "But wihtout that support it would sadly be not an option for me (and I think for a significant number of other developers).
Currently, yes - but I explained just that a few lines above - so let's wait for the VB6-breakage.
> "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 "
Exactly, an "open source IDE/Framework/compiler for a language one is familiar with is a good thing"...
though somehow I have the feeling - that you still consider the whole idea as "a product" - and yourself "a customer" - and that
"announcing to not buy the product" (in a kind of "customer is always king"-fashion) will achieve something ... IMO this is not the case.
In a community-project which lives from the efforts of contributors - the only thing what counts is the input those people give.
If you are among them, then your opinions have more weight - you could show (per code-contribution) if an idea of yours is worthwhile.
> "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
No - nothing would happen then (without having a kind of soft-pressure, which will encourage the writing of Widgets instead of OCXes) .
Olaf
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
mjohnlq
As for me, I hope:
step 1. develop the vb7 compiler that can compile the old vb6 .cls and .bas to a console .exe file, as possible as VB6 language compatible. the compiler can run on linux and windows, maybe can based on llvm. this step no need support ui controls files such as .frm or .ctl files. but need develop the file and network and other no-ui class library that needed by the ui-controls, all these library file are .cls and .bas file.
step 2. develop the vb7 controls with the same names as the old vb6, the vb7 controls can based on vbRichClient or wxWidgets or qt or others. the controls need can compiled use the compiler developed in step 1.
step 3. develop the vb7 compiler that can compiler the old vb6 .frm and .ctl and .res files use the controls developed on step2, after this step, all the vb6 projects that didn't use the activex controls can be compilered and run on linux and windows.
step 4. develop the vb7 compiler that can support activex control on windows, to do as possible as VB6-compatible on windows.
step 5. develop the vb7 IDE that only use the controls develop in step2, then the vb7 ide can run on windows and compile old vb6 project, and the ide can open the vb6 projects on linux.
Then, all my vb6 project can opened on the new vb7 ide and can compiled and run on window. And on linux need do some modify to compiled and run on linux, so can move all my vb6 projects slowly from windows to linux.
Your list above favours a "compiler first, then everything else"-approach.
I've already explained why I don't think that to be a good idea in my very first post in this thread.
There exist already well-working basic-compilers (developed in a non-integrated, standalone-fashion) as FreeBasic and OxygenBasic.
Especially FreeBasic does exist now for a few years already - and so far there is no well-integrated IDE-concept in sight,
which offer something like VBs UserControl-designer (so that you can design your own Controls/Widgets).
Also Edit&Continue is not addressed in any way (Debugging support in the existing IDEs for FreeBasic is very limited).
So there you can study already "a case" where a "standalone-compiler-first, IDE and GUI-bindings later" approach was failing
(despite a relatively large community).
If we want to come up with a tightly integrated, "Visual Environment" - then we will have to build this thing around
an IDE - and integrate the compiler there in a way, which interacts in the same fashion as VB6 with the Editor-Window
(pre-compiling the current line after you move the cursor away from it in the Editor) ... we will need to try already in the
very basic first compilation-tests an integration of the Debugger-Handling and an Edit&Continue concept which interacts
visually with the Editor-Pane and the watched variables.
We need to do that early, as long as things in the compiler and Editor are still simple - if we start an attempt later when
the compiler is already in an advanced state - I foresee larger problems to integrate something like that successfully and
as deeply as we have it available in the VB6-IDE currently.
That said - in case you are the author of the llvm-based approach here:
https://code.google.com/p/extended-b...extended-basic
I'd like it really much, when you would join the team. :)
Olaf
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
Schmidt
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).
I've started contributing to the vbWidgets project on GitHub. While I use Git for my own projects, I'm the only developer which makes it easy to have my own "protocol" for submissions. I hope I've followed the proper protocol for your project, but please let me know if you would like things done differently.
Regarding the controversy as to whether to support OCXs, it has become a polarizing issue.
Do you see a path where the IDE can be developed to support a plugin extension that could offer some kind of OCX support (perhaps in a container widget that bubbles events up to the new form engine). This would allow a second group of interested parties to spend effort developing OCX support, while the rest of the team that doesn't really care for it can ignore those efforts and work on the rest of the IDE.
This would also help to entice VB6 developers over who think they need OCX support, and introduce them to the new IDE and new features of framework. While they get comfortable with the new environment, over time they could migrate their apps completely off the OCXs and gain full cross platform, 64-bit, unicode, etc... functionality.
-
Re: VB Classic (A True VB 7.0)
@Schmidt
First of all: Thanks for taking the time to answer my post again!
I for one are not put off by your tone or take this personal because I think it is quite natural that a discussion about a topic several people have strong opionions about get's a little heated. A controverse discussion does not mean that I cannot respect other peoples views. Quite the oppisite: I really want to understand the different approaches and opinions, because I think it's a topic that deserves some real effort.
To clarify: I do have some knowledge about the component object model and TLBs and stuff, but I am by far no expert. I am able to query COM interface in source, call functions, use properties by name in code and stuff but I did not know that OCX Controls and ActiveX Dlls are from a technical standby a big difference in complexity. Thanks for putting it into some kind of perspective.
The support of ActiveX DLLs would make the proposed system a lot more interesting. I know this sounds again like a customers perspective. But I absolutly respect that this project - if it would be realized - would only be possible through hard work of a small team of very invested developers and that it would be crazy to "demand" anything from them. But I also think that it would be very good to have a broader base of support right from the start so that there are a lot of devs who - event if they cannot contribute directly - could help test the IDE, find bugs, promote the new system to other developers etc.
And like myself I am sure a lot of them need to see a viable approach for existing projects. You are kind of right when you write that the best VB6-compatible language today is VB6. But my point ist the following: I do have the fear that Microsoft may be one day stupid enough to break VB6 support and I do want to port our applications to another system before this happens. But this conversion also has to be affordable in terms of time and money. The support ActiveX-DLLs you said could be an possible without too much hassle would help a great deal: With something like this (source compatible + ability to use ActiveX-DLLs) I for one would be willing to port our software. Without OCX support this would still cost for our main application alone something around 750 hours of developer time (raw estimate of course), but at least that would be affordable (compared to around 2.500 hours). But this is just us. Other developers might have a different situation where they simply cannot afford to port without OCX support. I am sure most if not all of them would LIKE to though. I know that if Microsoft breaks support eventually I would still have to port the rest, but at least I would not need to do this all at once (which I cannot afford) but step-by-step (which I could afford).
If there was ActiveX-DLL support, that would really help out a lot of developers.
If there would be OCX support that would attract a whole lot of other developers to support the project (in some way or another)
This is why I am so interested in this aspect and persistent to "fight" for it ;-)
Regarding myself I would love to help out a project like this in any way I can - I do not think of this as a product and understand very well how much effort this thing would cost. However I do not know of how much help I could be given that I am mostly an application developer with some basic knowledge about compilers. What I AM good in would be: Helping develop a good framework library, developing and fine-tuning the IDE, helping to achieve a good user-experience, coming up with creative solutions, write widgets, help with translation, deliver graphics and contribute to language features (in my career I have developed about a dozen or so scripting languages for various plattforms and target groups).
Regarding the road map: I agree with you that the IDE and especially Debugging and Edit & Continue are essential key elements and need to be addressed right from the start. E&C in VB6 is still today one of the best regarding ease of use and performance.
Dominik
-
Re: VB Classic (A True VB 7.0)
@schmidt
Here are some suggestions for a compromise for OCX controls based on your suggestion for a VB7:
When opening a VB6 project the IDE will have to do some sort of conversion (to transfer intrinsic VB forms & controls to the new widget system), right?. A good approach could be to program the converter to use conversion manifests for different control types so that a developer could add their own conversion manifests to convert other controls as well. That would help with all OCX Controls that only add optical value (like better looking buttons etc.) and already have a replacement that offers the same functionality but in incompatible form. The conversion file would include mappings for properties, events, etc. and should have the ability to contain VB code in itself to help with more complicated stuff.
Here is an example:
MyCrazyCustomButton.occ:
Code:
Public PropertyMappings as new cMap = (
Text => Caption
TextColor => ForeColor
)
Public EventMappings as new cMap = (
DoubleClick => DblClick
)
Sub HandleProperty(Byval pPropertyName As String, Byval pAssignedValue, Byval pWidgetContext AS cWidgetContext)
Select Case pPropertyName
Case "Theme"
If pAssignedValue = "iThemeWarning" Then
pWidgetContext.SetProperty("BackColor", Rgb(255,0,0))
pWidgetContext.SetProperty("ForeColor", Rgb(255,255,255))
pWidgetContext.SetProperty("Icon", "Icons\wa
Else
[...]
End If
End Select
End Sub
[...]
Another helpful conversion tool would be the ability to auto-generate widget templates based on used OCX controls that do not have a conversion manifest: If the import assistant stumbles upon a control it checks the availability of a conversion manifest (which could even be used for intrinsic VB controls to minimize hard coded conversion routines). If none is found it queries the controls' interface and generates a dummy widget with all the needed properties, methods, functions and events to start writing a replacement. This "dummy" would ensure that the conversion can be completed and can be used as a temporary placeholder or a good starting point to write a custom replacement.
Dominik
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
Schmidt
The question I was asking you in my lost posting (and also sten2005, but he didn't care to answer it) was:
"What do you expect from a VB7, which VB6 cannot offer to you these days too."
And for my part I answered it with:
First and foremost: platform-independence, a community-based source-base nobody can take away "from us" in the future - and VB6-code-compatibility.
(and a few other things of course, but those are secondary).
Sorry, I posted a whole lot of stuff and DID forget to answer the question ;-)
So here it comes:
I would love to see the following features in a VB7 today:
- I like the open-source aspect very much, but would -to be honest- also settle for a commercial product if they would still respect their customers and would offer a good support
- The ability to attract younger developers that currently do not want to invest time in a "dead language"
- A bug-fixed IDE with some new comfort features (but not a bloated one like VS is offering - I rather like it fast & slick!)
- Some enhancements regarding the language itself to help dealing with larger projects: Better inheritance, easier syntax for optional parameters, small stuff like that - but it would make a big difference in terms of efficiency
- Platform independence (because in my humble opinion and strictly professional speaking Windows 8 Modern UI plain s*cks)
Dominik
-
Re: VB Classic (A True VB 7.0)
@schmidt
Sorry for posting so much, but I think I just found a simple solution to provide an OCX bridge widget based on your vbRichClient framework:
It's pretty simple: We could develop a tool to automatically create a widget-wrapper for any given OCX Control. This tool could even be integrated in the import assistant, so that importing a VB6 form would work like this:
- Check if there is a conversion manifest (for intrinsic controls and other controls that already have a valid replacement)
- YES: => Convert to new widget
- NO: => Create wrapper widget and compile it automatically using the old VB6 compiler (that is needed for the wrapper creation, not for the later runtime) and use the wrapper
How the OCX wrapper widgets works and why it will work with your system as long as Windows supports the VB6 runtime including thunderforms:
- It's simply a widget in your format, it's just an ActiveX DLL component
- Compiling the wrapper will require VB6.exe / C2.exe since it uses a thunderform as a host for the wrapped OCX control
- In runtime it does only require VB6 runtime support of the target operating system (Wine + Windows up until Microsoft pulls the plug)
- When connecting to the parent by the "AddedToHierachy" event it will dynamically create a thunderform and dynamically add the control
- The Win32 API command "SetParent" is used to make the form a child of the parent form (accessing it's hwnd over your widget architecture)
- If the base widget is moved, shown, hidden, resized so is the form and the wrapped control
- If the widget is removed the Form will be removed with SetParent Form.hwnd, 0 and the hosted OCX control will be destroyed
- All events, properties and methods of the hosted OCX control will be mapped and be made accessible without direct access to the wrapped object and therefore there is no need to support the VBExtenderObject on the side of your framework - just Events, Methods, Properties
We could event write a universal OCXWrapper that can basically add every OCX dynamically to a form based on the vbRichClient framework by creating it via Form.controls.add("Server.Control", "Name", Form), accessing it's events dynamically by using the VBExtenderObject and making it's properties and methods available by using the "InvokeHookArray" method of the TypeLibe Information Library (TLBINF32.dll).
Here is a proof-of-concept (without properties and methods, but that is guaranteed to work because I already tried this in another project of me where my own scripting language can bind ActiveX-Dlls and create the COM-objects located within):
fOCX.frm
Code:
VERSION 5.00
Begin VB.Form fOCX
BackColor = &H0080C0FF&
BorderStyle = 0 'Kein
Caption = "Form1"
ClientHeight = 3150
ClientLeft = 0
ClientTop = 0
ClientWidth = 4680
LinkTopic = "Form1"
ScaleHeight = 3150
ScaleWidth = 4680
ShowInTaskbar = 0 'False
StartUpPosition = 3 'Windows-Standard
Begin VB.CommandButton but_SelfDestruct
Caption = "Destroy"
Height = 315
Left = 0
TabIndex = 0
Top = 0
Width = 1275
End
End
Attribute VB_Name = "fOCX"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = False
Option Explicit
cwOCX.cls
Code:
Option Explicit
Public Event OCXEvent(pEventInfo As EventInfo)
Private Declare Function SetParent Lib "user32" (ByVal hWndChild As Long, ByVal hWndNewParent As Long) As Long
Private WithEvents but_SelfDestruct As CommandButton
Private WithEvents HostedControl As VBControlExtender
Private WithEvents Form As Form
Private WithEvents W As cWidgetBase
Public Property Get Widget() As cWidgetBase: Set Widget = W: End Property
Public Property Get Widgets() As cWidgets: Set Widgets = W.Widgets: End Property
Private Sub Class_Initialize(): Set W = Cairo.WidgetBase: End Sub
Private Sub Class_Terminate(): Destroy: End Sub
Private Sub but_SelfDestruct_Click(): Destroy: End Sub
Sub Destroy()
If Not Form Is Nothing Then
Set but_SelfDestruct = Nothing
SetParent Form.hWnd, 0
Unload Form
Set Form = Nothing
End If
End Sub
Private Sub HostedControl_ObjectEvent(Info As EventInfo)
RaiseEvent OCXEvent(Info)
End Sub
Private Sub W_AddedToHierarchy()
Set Form = New fOCX
Set but_SelfDestruct = Form.but_SelfDestruct
SetParent Form.hWnd, hParentHWND
Licenses.Add "MSComctlLib.TreeCtrl"
Set HostedControl = Form.Controls.Add("MSComctlLib.TreeCtrl", "myctl", Form)
Dim I As Long
For I = 1 To 10
HostedControl.object.nodes.Add Key:="Test" & Str(I), Text:="Test" & Str(I)
HostedControl.object.nodes.Add Relative:="Test" & Str(I), Relationship:=4, Text:="TestChild" & Str(I)
Next I
End Sub
Private Sub W_Hide()
If Not Form Is Nothing Then Form.Hide
End Sub
Private Sub W_Show()
If Not Form Is Nothing Then Form.Show
End Sub
Private Sub W_Paint(CC As cCairoContext, ByVal xAbs As Single, ByVal yAbs As Single, ByVal dx_Aligned As Single, ByVal dy_Aligned As Single, UserObj As Object)
If Not Form Is Nothing Then
Form.Show
Form.Move xAbs, yAbs, W.Width * Screen.TwipsPerPixelX, W.Height * Screen.TwipsPerPixelY
Static vFirstResizeDone As Boolean
If vFirstResizeDone = False Then
vFirstResizeDone = True
W_Resize
End If
HostedControl.Visible = True
End If
End Sub
Private Sub W_Resize()
If Not Form Is Nothing Then
Form.Move Form.Left, Form.Top, W.Width * Screen.TwipsPerPixelX, W.Height * Screen.TwipsPerPixelY
HostedControl.Move 0, but_SelfDestruct.Height, Form.ScaleWidth, Form.ScaleHeight - but_SelfDestruct.Height
End If
End Sub
Private Property Get hParentHWND() As Long
Dim vP As cWidgetBase
Set vP = W.Parent
If vP.hWnd > 0 Then
hParentHWND = vP.hWnd
Exit Property
End If
While Not vP.Parent Is Nothing
If vP.hWnd > 0 Then
hParentHWND = vP.hWnd
Exit Property
End If
Set vP = vP.Parent
Wend
End Property
Attention: Before unloading the containing form you have to click "Self destruct" otherwise the app will crash. That is because the base widget has no "RemoveFromHierachy" event and we need to call SetParent and restore the original parent handle (0=Desktop) before unloading the form.
Some other things regarding vbRichClient that came up during testing this (I only first used vbRichClient two hours ago, so maybe the following points are not valid, so feel free to correct me):
- First of all: Great work! Looks very promising and I like the use of Cairo for Windows (my own UI framework just uses GDI+ and has a wrapper for that, but of course it uses OCX for the controls)
- Resize should be called after AddedToHierachy
- There should be a RemoveFromHierachy Event that is triggered before the widget is removed (also called during unloading of the parent form)
I know that there still would be some issues - especially if a control searches it's environment to access another control and there are still some things. Another issue is of course that you cannot z-order a wrapped OCX control below a vbRichClient based widget because the widget is drawn to the form while the OCX control is an overlay. So it's far from perfect, but it still could provide support for some 3rd party controls that cannot be converted otherwise because we do not have the controls source code.
I know that this would allow me to port my applications completely: I would convert my own controls (hopefully using an mostly automatic converter) to the new widget format while accessing the unconvertable 3rd party controls through wrapper widgets.
It definetly isn't a solution for everybody but it would allow at least some degree of OCX use without the need for VB7 itself to support OCX controls.
I am very interested to hear your opinion about this.
Dominik
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
WhyWontIEdieAlready
@schmidt
Sorry for posting so much, but I think I just found a simple solution to provide an OCX bridge widget based on your vbRichClient framework:
It's pretty simple: We could develop a tool to automatically create a widget-wrapper for any given OCX Control.
...
Thanks Dominik, for the proof of concept - and of course, as long as we produce 32bit-Binaries with VB7 - and the Vb6-Runtime is still available and working -
we could use something like that in conjunction with the VB6-Form-engine (encapsulated in a VB6-COM-Dll), to perform the Form.Controls.Add-Call ...
(which is the critical point in the whole exercise and does quite a lot of hidden and complex stuff under the hood with regards to the IOlexxx- UserControl-interfaces and siting).
For those who want to "merge" vbRichClient5-Widgets and normal VB-Controls on the same Form in *VB6*, including correct Tab-Key support and stuff,
there's the ucPanel.ctl approach - so one doesn't have to use a cWidgetForm as the only available GroundLayer for Widgets in VB6 - ucPanels can be used alternatively.
Though for VB7-proper I'd like to have (if we do such a thing as your proposed OCX-bridging) a small Helper-Dll, written in MS-VC++ (with some help from ATL,
which offers something similar as the VB6-Controls.Add-call with regards to easier siting-support for OCXes - so VC++ offers an easy way, to produce also a 64Bit-variant of such a helper).
So, if that OCX-topic is dear to you (even when still unfamiliar with VC++), something like that would be a worthwhile addition (when encapsulated in a Dll,
which in its first incarnation should play together and be tested with VB6 - just something which is able to "externalize" the VB6-Forms-Add-functionality -
and is then usable independently from the VB6-runtime by the VB7-compiled-binaries in both, 32Bit and 64Bit mode).
In case you never worked with VC++ - it's not all that "alien" - and "siting of an OCX per ATL" should be well-covered in online-articles and forums,
where one can take a look how it's done.
You will have a lot of time for that too, since I don't expect the compiler to produce something useful before at least 9-months or so are gone by.
Regards,
Olaf
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
jpbro
I've started contributing to the vbWidgets project on GitHub. While I use Git for my own projects, I'm the only developer which makes it easy to have my own "protocol" for submissions. I hope I've followed the proper protocol for your project, but please let me know if you would like things done differently.
No, all fine - thanks - will respond (and merge your first additions) soon.
Quote:
Originally Posted by
jpbro
Regarding the controversy as to whether to support OCXs, it has become a polarizing issue.
Do you see a path where the IDE can be developed to support a plugin extension that could offer some kind of OCX support (perhaps in a container widget that bubbles events up to the new form engine).
Yes - something like the "fast shot from the hip" Dominik came up with as a first proof of concept is always doable (sidewards - and later on) -
And "making an OCX visible somewhere on a Form" (the "basic siting", so to say) is not *that* difficult to achieve -
neither over a small external VB6-Dll - nor over an (ATL-based) C++-siting-Dll-wrapper.
The bigger problem is, to integrate those hWnd-based Controls with other Widgets on the same TopLevel-Form (layering-issues will happen because of Windowless vs hWNd-based) -
and then we would need to support correct tabbing-integration - and finally (what you already hinted at) - a proper Event-integration into the WidgetForm-Event-Bubbling-mechanism.
That's all solvable of course (in one way or another) - but "a distraction" nonetheless in the early stages of the project - because we already have a fully working "UserControl-Engine"
(which is more powerful than the MS-one and should therefore be preferred).
Quote:
Originally Posted by
jpbro
This would allow a second group of interested parties to spend effort developing OCX support, while the rest of the team that doesn't really care for it can ignore those efforts and work on the rest of the IDE.
Sure, I'm not hostile against such efforts - anything which broadens the user-base is a good thing in the end - and should be integrated when tests show, that it plays well with the existing engine...
I'm just trying to steer a straight course to platform-independence, which currently seems not that important to many VB6-Devs - but it will become so in a few years- I'm deeply convinced of that.
That's why I labeled the OCX-support (somewhat undeserved maybe) "a distraction" - (from the Widget-Engine)... you will not be able to "take OCXes with you", in case of a platform-switch.
The Widget-Engine (along with more and more well-written additions to the free available Widget-stack) should be the preferred kind of GUI-approach.
Quote:
Originally Posted by
jpbro
This would also help to entice VB6 developers over who think they need OCX support, and introduce them to the new IDE and new features of framework. While they get comfortable with the new environment, over time they could migrate their apps completely off the OCXs and gain full cross platform, 64-bit, unicode, etc... functionality.
As said, if there's a group of interested Users who come up with a nicely sidewards-bindable OCX-Bridging-approach - we should integrate it into VB7 (even if I'm not a fan of OCXes <g>).
Regards,
Olaf
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
Schmidt
I'd try to mimick the old IDE (maybe just introduce some nicer Icons) as far as possible (the non-SDI-version I mean).
Olaf
i do hope the SDI version is also taken into account, as that's how I use the IDE, don't like the mdi. Also extensibillityis very important, the current vb6 ide has some nasty shortcomings,which are very noticable under windows 7 (using source safe 5).
We use MZ-tools for extending the ide, and our own addins (no i don't suggest the ide should be compatible with those, far from it, it's pretty crap, a lot of our add-in code consists of working around the crappy extensibility, not on actually the functionss themselves.)
One of the reasons why i would want my current vb6 projects to be able to just convert and continue in vb7 is due to some stupid limitations of the vb6 ide/project size. sadly there is some sort of limitation on the ammount of differently named variables in one project (yep, i'm hitting that limit, which results in 'out of memory' errors in the ide.. also one of the most annoying things of the ide/intellisense of vb6 is that it doesn't limit the name of a method/property/parameter/variable to the specified scope, but on the whole project, which is especuially annoying if you are using something like sourcesafe, for example take a property 'X' (uppercase X)on a class, but if you use an ocx or some default api declaration where a variable is called 'x' (lowercase x), the ide changes the name of the class property to 'x' or if you add the class after the api-declarating, it will change the parameter 'x' to 'X'... VERY ANNOYING, so i do hope something like that is fixed.
the reason i want everything in one project is due to not wanting to have to worry about dll-hell, that way i know the specified project always uses the versions of the controls it needs to have, and i don't have to worry about my ocx-es/dll's don't have to be s 'backwardcompatible'. so i hope the new ide will fix the limitations/annoyances..
Also the advantage of having 100% compatibility is you can immediatly start using new functionalities for new parts, and replace/upgrade older parts when needed...
I also mentioned sorcesafe for a moment, good sourcecontrol integration is also ver needed in the new ide..
ps. i still haven't had time to checkout the framework.
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
Schmidt
No, all fine - thanks - will respond (and merge your first additions) soon.
Great! No rush to merge of course, and criticism of my code is always welcome if it is not up to snuff. I just wanted to "fly the flag" a bit about contributing to the effort.
Quote:
Originally Posted by
Schmidt
Yes - something like the "fast shot from the hip" Dominik came up with as a first proof of concept is always doable (sidewards - and later on) -
And "making an OCX visible somewhere on a Form" (the "basic siting", so to say) is not *that* difficult to achieve -
neither over a small external VB6-Dll - nor over an (ATL-based) C++-siting-Dll-wrapper.
The bigger problem is, to integrate those hWnd-based Controls with other Widgets on the same TopLevel-Form (layering-issues will happen because of Windowless vs hWNd-based)...
Frankly, I'm not too concerned about the details "today" because I think that if it is technically feasible, and can be done in such a way that it is not a major distraction to the core project (that is to say that another group of programmers who otherwise wouldn't want to get involved, but are willing to work on OCX compatibility without taking too much effort away from the core programming group), then why not?
Quote:
Originally Posted by
Schmidt
Sure, I'm not hostile against such efforts - anything which broadens the user-base is a good thing in the end
I agree.
Quote:
Originally Posted by
Schmidt
I'm just trying to steer a straight course to platform-independence, which currently seems not that important to many VB6-Devs - but it will become so in a few years- I'm deeply convinced of that.
I 100% agree that platform independence is a primary goal. I only see OCX support as a temporary bridge.
A personal anectode: I initially fought against legacy support when developing the latest version of our software, even though my boss thought that it was critical. I fought because it was going to be a lot of painful work to understand some ancient proprietary binary formats (circa 1993, for which there was no documentation), and to deal with non-normalized Access databases that didn't even store the data needed to be used with some of the new features of the software. At first I "won", but over time it was evident that many of our "old" customers needed to see something that they were familiar with in the new program to really understand the fundamental shifts in the approach that we were taking with the new version. So in that sense, I was wrong, and I eventually took the time to create a migration path for them. When new features were impossible to use (because the data didn't exist from the legacy software for example), then it at least gave the users an understanding of what they were gaining by starting from scratch with the new program. Because of this experience, I think that OCX support (or at least the ability for interested developers to easily integrate some kind of OCX support in "VB7") would be useful.
Quote:
Originally Posted by
Schmidt
The Widget-Engine (along with more and more well-written additions to the free available Widget-stack) should be the preferred kind of GUI-approach.
I agree.
Quote:
Originally Posted by
Schmidt
As said, if there's a group of interested Users who come up with a nicely sidewards-bindable OCX-Bridging-approach - we should integrate it into VB7 (even if I'm not a fan of OCXes <g>).
I agree, for reasons stated above. I think the only concern of the core IDE dev team regarding OCX support should be that it is relatively easy for an OCX-compatibility dev team to integrate their work into the main project (what I don't know is how this will be done - I would prefer an extension/plugin framework, as opposed to a different build of the IDE.)
-
Re: VB Classic (A True VB 7.0)
@SuperDre & Olaf
Maybe a new thread should be started to discuss the complaints about the old IDE and what features we would all like in the new IDE?
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
jpbro
@SuperDre & Olaf
Maybe a new thread should be started to discuss the complaints about the old IDE and what features we would all like in the new IDE?
I'd find that not necessary at the moment - in my initial GIT-Repo-Opener-Step (just give me a few more weeks, to bundle something up),
I will upload a wireframed and widgetbased-Version, which in its "Panel-Areas" tries to mimic the current VB6-MDI-version (most of the PanelAreas still empty,
only filled with mockups or stubs). Also the Menu-Stripes and ToolBar-Stripes I will only provide with the first entries - and the modal-dialogues
I will replace with a generic "Todo-MessageBox".
From that Wireframe it should be easier then, to "spread the work-load" without causing team-efforts to overlap.
I'd like it when we could use *this* Forum here for the rough overview, where the project currently is, reflecting the current
state in a kind of "still open, ...already worked on by PersonX, ...already finished"-List where developers can "check themselves in"
for a certain Todo-task, to fill the "still blank spots" in the wireframe-model - and make it clear for others, who's currently working on what -
which are the Todo-Tasks which are still "open" - and what tasks are already done ...
Maybe *that* should then go into a new, separate Todo-Thread, where the initial post is used to reflect the current state.
Basically I'd like to treat the GUI in the same way as the initial requirement for *.bas and *.cls compatibility - let's discuss enhanced features
(much) later - first let's try to come up with something which resembles the original as closely as possible - only if there are
"cheap and obvious enhancements possible already in the first throw"- then of course let's apply them - but those topics will
then come up along the way in the GIT-repo-Pull-Requests - and we could discuss implementation-details there then.
Edit: Forgot to comment on the SDI-capabilities of the old VB6-IDE - and how to achieve that in the VB7-IDE...
This feature would (if there's enough contributors who'd be willing to approach this) not that difficult to implement,
since in the new Form-engine (which offers the hosting-areas for the new Widget-Framework) there's no difference between
"Client-Panels" or "TopLevel-Forms" - both are of type cWidgetForm.
So, Code (and Widgets) on a certain Panel (interacting with such a cWidgetForm-Base), which in the first throw will be implemented as Docking-Areas -
can later on easily be hosted also in a TopLevel-cWidgetForm-instance (ToolWindows etc.), by just switching the instantiation-line of the cWidgetForm-variable -
so SDI-mode will not be a real problem if that is wanted - but it can be achieved later on, without "wreaking havoc" in the original CodeBase - and so I'd like to
delay this step until we came clear with the MDI-version initially (which I think is the mode, the VB6-IDE is currently used by most Devs).
Olaf
-
Re: VB Classic (A True VB 7.0)
Most of the discussion here has been above my head but I am really excited by this project.
I'd be happy to help out if there was work within my capabilities available though.
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
Schmidt
Edit: Forgot to comment on the SDI-capabilities of the old VB6-IDE - and how to achieve that in the VB7-IDE...
This feature would (if there's enough contributors who'd be willing to approach this) not that difficult to implement,
since in the new Form-engine (which offers the hosting-areas for the new Widget-Framework) there's no difference between
"Client-Panels" or "TopLevel-Forms" - both are of type cWidgetForm.
So, Code (and Widgets) on a certain Panel (interacting with such a cWidgetForm-Base), which in the first throw will be implemented as Docking-Areas -
can later on easily be hosted also in a TopLevel-cWidgetForm-instance (ToolWindows etc.), by just switching the instantiation-line of the cWidgetForm-variable -
so SDI-mode will not be a real problem if that is wanted - but it can be achieved later on, without "wreaking havoc" in the original CodeBase - and so I'd like to
delay this step until we came clear with the MDI-version initially (which I think is the mode, the VB6-IDE is currently used by most Devs).
But implementing it from the start makes sure you won't have any problems later on.. Also with modern MDI you can just drag a window out of the MDI-parent (at least in VS.NET) so in some way you do have SDI..
But personally I'm not that fond on MDI, the only thing I like about MDI is the fact if you maximize a child-window it will position itself within the MDI-clientarea, but we 'fixed' that for SDI in our add-in so you can 'one of the options of our addin we created is that a code window will position itself under the VB6-main-toolbar and is limited to the project-window (or whatever you want).. It works a bit like the old Delphi IDE (and it's best addon G-Expert).
But are 'you' gonna use the vb6 IDE as the example IDE or are 'you' also looking at other IDE's?
-
Re: VB Classic (A True VB 7.0)
Please read this: http://www.codeproject.com/Articles/...rful-than-ever :thumb:
Quote:
Originally Posted by
Jacob Roman
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 :rolleyes:
http://www.vbforums.com/showthread.p...ht=lightfusion
-
Re: VB Classic (A True VB 7.0)
-
Re: VB Classic (A True VB 7.0)
Here has vb.net's compiler source code:
in the sub dir DotNetReferenceSource.zip\Source\vb of the below package
http://referencesource-beta.microsoft.com/download.html
-
Re: VB Classic (A True VB 7.0)
Quote:
Originally Posted by
mjohnlq
:) is this legal ? hmmmmm VB .NET compiler source code :)
VB6 compiler source codes ? :)
