vb.net compiler source is open source by microsoft, so i think it is legal.Quote:
Originally Posted by Fatina
but vb6 compiler source code is not open sourced by microsoft.
Printable View
vb.net compiler source is open source by microsoft, so i think it is legal.Quote:
Originally Posted by Fatina
but vb6 compiler source code is not open sourced by microsoft.
Visual Basic 6.0 it is not open source because is too important, true ! thanks for the link, I did not know that VB .NET is open sourceQuote:
Originally Posted by mjohnlq
you are welcome.Quote:
Originally Posted by Fatina
I just know it today too. from this link:
http://visualstudio.uservoice.com/fo...t-framework-so
VB.NET-compiler source (non-MS) is out there for years under Mono, written and maintainedQuote:
Originally Posted by Fatina
by Rolf Bjarne Kvinge...
In either case (although I'd think that the Mono-license is a bit more liberal than the MS-
conditions which come with their source), I'd suggest not to look at it (in depth), and
definitely not to copy portions from it, just to be on the safe side.
Olaf
true :)Quote:
Originally Posted by Schmidt
Just to let you know my position, I would definitely contribute toward a kickstarter-like project for a more up-to-date VB6 IDE that was able to be language-aware with language specific functionality being enabled/disabled via configuration/plugins. Personally, I'd like a new IDE to be as much like the old VB6 IDE as possible. That is what made me productive and I'd like it to continue. Jabaco came up with a pretty good first stab at a VB6 IDE look/act-alike but that project is dead in the water. I think a new non Microsoft IDE is an achievable objective that would be just the first step to reinvigorating VB6 and jumping off point for VB7.
For VB7 to succeed it simply needs to do one thing - compile and run our programs.
Any new functionality needs to be in addition to supporting the old. Once again, I would be willing to contribute to a kickstarter-like project that would create a VB7 compiler on windows. Initially, if it was only for windows I would be happy but if later compilers could create code for Android that would complete the picture. Each compiled could be a separate kickstarter project.
The only VB7 enhancement that I see that would drive me to wanting it 'desperately' is better handling of transparencies to allow transparent/semi-opaque images behind controls/backgrounds &c. This would allow shaped applications like these:
http://lightquick.co.uk/images/stori...big-work04.png
You can already achieve everything I see on your screenshot with the vbRichClient-framework (a free set of 3 Dlls for VBClassic).Quote:
Originally Posted by yereverluvinuncleber
With ease, since it supports not only vector-based, antialiased Drawing (as well as all kind of alpha-channel-Bitmaps and Icons - gaussian blurring etc.), but also a new Form- and UserControl-engine (in the context of the Framework I call those new UCs "Widgets" - they can be developed quite similar to normal VB-Usercontrols, but in addition come with an Alpha-Transparency- as well as a .Moveable property, MouseWheel-Events, MouseIn/Out etc... the Framework is Unicode-capable throughout).
Just install the "BaseDlls" first:
http://vbrichclient.com/#/en/Downloads.htm
(and read what's stated below the Download-link with regards to registry-entries).
And then check out the well-commented Tutorials/Demos, in the order they are listed on this page:
http://vbrichclient.com/#/en/Demos/GUI/
- CairoDrawing
- FormEngine
- WidgetEngine
Each of the above contains a list of Folders, ordered from "easy" to "advanced" -
each Folder is self-contained (not dependend on the Source-files in other Folders).
Olaf
I thank you for that information and I will certainly have a look at those references you have provided.
I have already created these using javascript and XML as genuine desktop widgets using the Yahoo widget engine, the IDE was Photoshop for the graphics and Context Editor for the code using a conversion script to convert the PS layers to an XML description.
I might have used VB6 if the future for VB6 had been perceived, at the time, as being more secure. However, even the Yahoo widget engine has been abandoned and so I am now looking for a new development platform. Considering Xwidget engine (Windows/Android) and/or QT (most of them)
This is another that I have created as a widget so you can see the sort of thing I now knock up:
http://lightquick.co.uk/images/stori...ndar-large.png
Regardless of whether I could fulfil my current needs with VB6 I'd still support an open source multi-language VB6-like IDE and I'd contribute toward a VB7 in one way or another.
Nice graphics (and graphics skills)...
As for good-looking, *.png-based and antialiased "AnalogueClock-KnockUps" ;)
(though still kept simple, without the Date-Visualizings and Moon-phases) -
this vbRichClient-based Widget-Demo is perhaps interesting to you as well:
http://www.vbforums.com/showthread.p...-ClockHands%29
Aside from the rich graphics-capabilities which offer anything you're perhaps wont also from the other engines (including SVG as well) -
the framework also integrates a physics-engine (a chipmunk-binding behind easier to use COM-classes), so that
you could design physically correct behaving mechanics too... (a motor, all kinds of "joints" and springs ... it's all there).
As for VB7 (and a new IDE which is based on the new Widget-Engine) - currently have not that much time as I'd like -
though the project is still on my todo-list... will post here, when I have something to show and make the next move with that...
Olaf
Complement appreciated... Having just read the description on your site and seeing what you have already done and what you intend to do, I am more than impressed by your programming skills. My graphic skills certainly exceed my programming skills (I am really no more than a scripter with initiative).Quote:
Originally Posted by Schmidt
Time is what none of us have but if it encourages you, I am really impressed that someone is delivering the components that you are producing. These were needed a long while ago...
My apologies for showing more of my stuff but as you seem to like it...
http://lightquick.co.uk/images/stori...auge-metal.jpg
Looking at your rather attractive clock widgets - I'm going to have to reconsider VB for widget-making.
FYI - my javascript widgets are here: http://lightquick.co.uk/steampunk-wi...tml?Itemid=264
Don't have high expectations of my code but the widgets do work mostly. The widgets are zipped in a .WIDGET file, there is a converter on the download page that makes it easier to unzip the widgets. Feel free to convert if you want.
Chaps. One thing that might help with any possibility that MS might break the platform and remove something like OCX capability - ReactOS. I have some high hopes for ReactOS, an open source re-engineered version of widnows (sic) which is similar in concept to what you are thinking of doing with a new VB7. ReactOS is based upon the functionality of NT 5.2 and is already bootable/runnable in alpha and will be going to beta probably on the next release.
If it is successful, ie. it goes beta then live and it appears usable, then it should provide a platform for the future for all VB6/VB7 apps in that it will not break backward compatibility just for the sake of Microsoft doing so.
I think that any developers of a future VB7 should have a stake in what the ReactOS boys are doing as I reckon it could be a partnership made, well, not quite in heaven, but close.
https://www.reactos.org/
http://lightquick.co.uk/images/stori...os-screens.png
Don't expect it to install/run VB6 yet - it isn't quite there yet. It runs lots of app.s but the memory management is still flaky, the explorer and task manager are being re-engineered now and a lot of what is there is in place because they needed something to just 'work'.
Interesting thought that when you distribute your VB6 app you could bundle an o/s with it too, almost like a runtime library... ;)
I'm following ReactOS for a long time now, it started out well, but progress is really slow in the meantime
(they're still not yet at the point of true "Windows-Driver-compatibility" - which could give a boost when
that'd be ready).
In UserLand (atop the kernel- and driver-layer) they are using SourceCode from the Wine-Project.
Have already validated this approach about 1.5 years ago (with a tinycore-linux,Quote:
Originally Posted by yereverluvinuncleber
which comes in a ~12MB-package, including a modern kernel and a Desktop-GUI).
http://www.tinycorelinux.net/
Linux+Wine is still the (much) more stable approach, compared with ReactOS.
After installing the Wine-package from the TinyCore-Repository, followed by an
install of the VB6-runtime-Files - VB6-apps were able to work on that system.
Size as a VMWare-package/disk (including the quite large Wine-Layer-libs) was about 45MB
or so (7z-compressed about 30MB) - so, yeah - a complete, modern OS, able to run VB6-apps
on top, was thus smaller than e.g. an update-package for the 4.xxx .NET-runtimes ... ;)
But resorting to that kind of thing (shipping VB6-Desktop-Apps as a VM) will not
be required IMO for a long time to come - Win9 will support VB6 and COM definitely
further - there's just too many Apps in all the Offices around the globe (even a whole
lot of .NET-based ones) which cannot function without Win32 and/or COM.
Olaf
That is a great approach and I'll consider that for the future too! I'd also like to get my yahoo widgets running under wine but the engine does not work due to some missing graphic functionality.Quote:
Originally Posted by Schmidt
I have seen ReactOS firm up a little with the last release but you are quite right it seems to make slow progress - it is a momentous task to attempt. Hoping that when it turns to a beta release the momentum will start to be generated. I feel that ReactOS is a hard project to contribute towards due to the nature of the developers, they don't always seem a communicative bunch though this has also improved recently.
Hello Everyone,
As most of you know I have been driving hard to promote the vote to MS to bring back VB6. I actually had a conversation with someone at MS a week ago, and although he is lead guy of another team not associated with vb, he kept stating that bringing the product back is highly unlikely because most modern development needs more... So funny. After the phone conversation I asked him to give me a list of things that would help my app if I re-wrote it .net. I have yet to hear from him. I think I would be stupid to actually move to .net, again trusting a company that deserves no trust.
I have also talked via forum to the people at xerocoder.com and suggested they create a convertor for vb6 code to import to their platform. They feel that they could create a convertor that can convert up to 95% of vb6 code. They use a macro system that allows you to create language keywords to convert what they have to vb6 syntax, pretty neat. I hope they decide to go for it.
Schmidt is a true genius and I wish there was a way to give him the funds he needs to get the project done, although I REALLY do agree with yereverluvinuncleber that a vb6 replacement must be able to compile a vb6 app as they run today. The way I see it that, and that alone will have vb6 devs all over the world run to its adoption. I know that may hinder the fact that it will be cross platform and win32 dependent, but those things can be much easily re-factored if a compile from current vb6 code can be achieved, all extra effort can then be focused on cross platform and removal of win32 dependencies.
I am really crossing my fingers that one of these four things happens this year
/ MS brings back vb6
/ xerocoder implements a true vb6 import
/ Schmidt finds time and money to complete his project
/ or anything comes to market as a true vb6 replacement.
That's my 2 dollars and 50 cents!
Good Day!
Hello Everyone,
I am disgusted by the banning of Megan Winter's account on social.msdn.microsoft.com. She came with valid points for Visual Basic 6.0, too valid! And what the administrator/power user does on a MICROSOFT site?! He (the power user) erased all 60-70 valid comments (on "Bring back Visual Basic 6.0 ! We all need it." issue) and banned the acount due to his inability to cope with the conversation! This guy is a disgrace for Microsoft! The admin that banned a perfect valid user like Megan Winter should not have access to that site ! The name of this power user is Cor Ligthert. Please comment there: http://social.msdn.microsoft.com/For...orum=vbgeneral
Folks, what happened to Megan Winter is NOT ok !
PS: yes, but it will not be the same. I also agree that a vb6 replacement must be able to compile a vb6 app as they run today (and this is the most important thing!). These points are important: http://vb6awards.blogspot.ro/2014/02...-basic-60.html
Cor Ligthert "terrorized" (toghether with a few cronies) the VBClassic mpvbgd-usenet-group for years.
And he's not at all good at the kind of "marketeering" he did then and there (although it's
much better than trying to talk with him about programming-topics, been there - done that).
Cor easily raises (involuntarily for the most part) ignorance to an art-form (to be fair, that's
partly because of his bad english skills) ;)
So, in short: you can as well have a nice conversation with a brick-wall - at least the responses
you'll get then, will be consistent and non-contradictory.
Just forget about it.
Olaf
So true Olaf, you're right! :)Quote:
Originally Posted by Schmidt
As the project is still on drawing board I would suggest to have look as a similar compiler B++. It is on sourceforge web site.
It seems to be abounded but it can be a starting point for this new project. It is basically an emitter which will generate C++ code in back end and compile it with either MingW or BorlandC++ (free compiler).
While we are at it.
I would like to know if it would possible to use LLVM for targeting multiple OSs?
HTH
Yogi Yang
If Olaf felt like setting up a kickstarter to fund the first stage of the project we could use it gauge the actual level of support. It would need a site and some publicity though. Not pushing you toward this - just stating that I feel that it is a valid direction to go in if you needed something to push you to complete the work you have already started.Quote:
Originally Posted by axisdj
In my plan to accomplish platform-independence (as well as 64Bit-support),Quote:
Originally Posted by yogiyang
I wanted to incorporate a "plain C"-emitter. That's mainly because I see
the (InProcess working) tinycc-compiler-library playing the main-role in a
PCode-like engine, which is working behind the scenes within the new IDE
(to allow for easy debugging, and Edit&Continue).
The "real compilation" would then allow to target either MingW for faster
and optimized "native-compiled binaries" - but alternatively also the tinycc again,
which allows for slower executing, but smaller "PCode-like" binaries then.
So the new IDE will have (as before) two different compilers - a very fast compiling
one (tinycc, about factor 10 faster than GCC), and MingW which has not the same
throughput in "processed lines of C-Code per second" as the tinyCC, but will end
up with higher-optimized, faster executing binaries.
Neither tinycc nor MingW-dependencies will be required to "ship" with
your compiled binaries finally - but I assume this is clear.
It is certainly possible - mjohnlq already suggested that here in this thread - and there'sQuote:
Originally Posted by yogiyang
also already the beginning of an LLVM-based compiler as mentioned in the posting here:
http://www.vbforums.com/showthread.p...=1#post4492531
So, it is doable - but at the moment I'd like to stick with my plan for a plain-C emitter
(the same emitted sources usable by both, the tinycc-engine as well as the MingW-C-compiler).
Since this would mean a very lean deployment of the new IDE-project (when in the first
implementations only the tinycc is acting as the compiler for both: IDE-Debug-runs as well
as final Binary-compilation).
The MingW-compiler (which has quite a large deployment-size > 10MB) could be installed as
an optional engine (to be shelled from within the IDE whereas tinycc supports both - a nearly
GCC-compatible commandline-interface - but also the already mentioned libtcc.dll).
tinycc is really impressive and comes since release 0.9.26 in both, a 64Bit- and a 32Bit-version
(able to compile the appropriate 32bit or 64bit binaries also for windows). Deployment-size -
about factor 30! smaller than MingW (only about 386KByte).
For those who want to play around with the little engine - here's the main-page:
http://bellard.org/tcc/
And here the Download-page (version 0.9.26 for Windows is what you want).
http://download.savannah.gnu.org/releases/tinycc/
Olaf
This would mean that we will not be able to debug code interactively like is currently possible in VB6.Quote:
Originally Posted by Schmidt
Would it be possible to implement an interpreter and well as code emitter?
Say if possible adopt Gold Parser (again this project is 100% in VB) to interpreting and related stuff. (http://goldparser.org/)
Just my thoughts.
Quite the opposite - the tinycc-Compiler will *allow* (due to its InProcess-availability as a Dll and its superfast compile-speed) fast Upstart-Times and a "true Interpreter-like debugging" (as well as Edit&Continue), all due to the ability of the tinyCC-dll, to add new compiled functions "on the fly" into an "already running scenario".Quote:
Originally Posted by yogiyang
Just imagine the emitted C-Code as something like .NETs "intermediate code" - and the tinycc-Dll as a kind of "VM".
The very same "emitted C-Code" will feed both - the Debugging-Process (then with the tinycc-dll as the C-Code-to-Binary-translator) - and in a true "binary-compile-run", the same C-Code gets translated into Windows PE-format (Exes or Dlls) by either the commandline-version of the tinyCC or the MingW-C-Compiler.Quote:
Originally Posted by yogiyang
I know the page and the tool - but it's not needed.Quote:
Originally Posted by yogiyang
A dedicated (handwritten) Parser is to about 90% complete (and speed-optimized) already.
Olaf
But the debugging part will be in C language and not in Basic language right?Quote:
Originally Posted by Schmidt
The possibilities of having TinyCC as a dll and using it is really great concept!
Just curious...
Will TinyCC be able to compile and run new unsaved project directly from memory as is currently possible in case VB6?
The problem that (after Binary-compilation) one can only attach normal DebuggersQuote:
Originally Posted by yogiyang
(which in case of the GCC-Debugger would report only the somewhat renamed
C-Symbols then - and have no real relation anymore to the underlying line of
VB-Code, which produced a certain "C-Block"), is known.
But in VB we don't debug stuff in this fashion (with dedicated OutOfProcess-Debuggers)
... we do it directly in the same IDE-Process against "InMemory-VB(A)-PCode"...
Well, look at that here: :)Quote:
Originally Posted by yogiyang
So the latter one is True - and will be the base for a real "InIDE-Debugging" as we areCode:Private Enum tccOutPutType
TCC_OUTPUT_MEMORY
TCC_OUTPUT_EXE
TCC_OUTPUT_DLL
TCC_OUTPUT_OBJ
TCC_OUTPUT_PREPROCESS
End Enum
wont to - I can exchange Symbols and add (newly compiled) functions into a given
TCC-InMemory-State (whilst being in an IDE-DebugSession).
That, paired with a self-implemented Stack-Area-allocation will ensure "Interpreter-
like flexibility" - but will run faster than VBs current PCode.
I've compiled a VB-friendly stdcall-variant of the tcc-lib and (next few days) will
post a CodeBank- example for InMem-usage of this "Mini-VM" from within VB (at the
moment only acting as a kind of "C-Scripting-language" from within a VB-application then).
Olaf
Wow that would be great! You are at it again!Quote:
Originally Posted by Schmidt
Please don't get me wrong. But personally I have observed that we VB6 developers have been spoiled by VB6 IDE and are used to, you know setting a breakpoint and then running the code and when the IDE halts at the breakpoint we can manipulate/check values of variables, skip execution of a code lines, add new code lines, etc.
Lack of such interactive debugging feature will probably put off a conventional VB6 developer from adopting this new alternative.
Yogi Yang
Megan has now been 'Unbanned'Quote:
Originally Posted by Schmidt
http://visualstudio.uservoice.com/fo...improved-versiQuote:
Visual Studio team (Product Team, Microsoft) commented · March 06, 2014 18:59 · Flag as inappropriate
@MeganWinter, we looked into why you were banned on Forums and you should not have been. We have unbanned you and will further investigate internally as to why this ban took place. We are tremendously sorry and apologize for any inconvenience in which this has caused.
Do you know I am quite astonished by the "head of steam" that seems to have been generated recently behind vb6 and by its loyal users. It seems that people (even windows users) are realising that the "Microsoft way" is not the only way and that there are actually other ways of doing things. I've been keeping my eyes open for a long while now and the "driving wind" behind alternatives is greater than it has ever been. Microsoft doesn't seem to be aware of it or perhaps it is blind to the outside world. Reversion to VB6 as a potential development platform for the future is one thing that I see emerging from Microsoft's Windows 8 car crash.
I reckon that if there is a chance for a VB6 alternative and a compatible and familiar IDE, then the time for it is has arrived or is arriving. There seems to be a lot of disillusionment from users with Microsoft's new NT6 GUI and also from Developers across the board regardless of which Microsoft technology they are familiar with. People are still loathe to drop the Windows environment they are familiar and productive with - but no longer expect Microsoft to provide it.
Very well put, all of the above - and as for the "Steam" - I think the recent initiaitves coincide
with Steve Ballmers resignation (roughly from the time of its announcement) - but were
perhaps encouraged also due to MS's-backpaddling to the COM-environment, which is now
(again) the technical base for all those "new, clean and tiled" (ARM-capable) WinRT-developments.
Best tool for the WinRT-job? -> C++, using those new COM-interfaces in an unmanaged way.
So why not re-incarnate the classic C++/COM companion (VBClassic) again?
I think the above two reasons are the driving force behind these latest efforts of the VBClassic-
community - if there ever was a (slight) chance for a kind of resurrection - then now is the time
to make oneself heard, to possibly make it into the "my-strategic-decisions-to-make"-list of the
new CEO - there was always "strong forces behind VBA" (in the MS-Office-Group) which in the
meantime are perhaps aware again, that "VBAs big brother" wants to get back on board.
I personally see the chances for that as only 3-5% or so - but you never know -
and even if those numbers are quite small, the chances now are a bit better than they
were e.g. 3 years ago.
Olaf
What news? Is there any? A lack of information is always teasing...
Any news about this project would be gratefully accepted.
Not directly related to this thread but interesting nonetheless, getting VB5/6 working on ReactOS (windows clone).
https://www.reactos.org/forum/viewtopic.php?f=4&t=13090
I will be posting there shortly when I have more time to test VB6 on ReactOS myself.
Olaf,
Have you made any progress on your idea for a true VB7? We would all support you in your efforts, all projects need a driving force with the capability to actually do it.
Admittedly, I didn't read through every entry above, but I did read through quite a few of them. This is a very interesting project, and it's something I've thought of myself, but there are a few problems here (possibly already discussed). First and foremost, this is a monumental project. It's certainly a bigger project than one or two people can carry off on their own. For it to have any chance at all, it'd have to compile my existing code with a minimum of effort. I thought I read that you were only going to do .bas and .cls modules. However, if you get .cls modules going, you're 99% of the way to getting .frm modules going as well. I can understand how .ctl modules may be a bit tricky, but you'd really need to get those going as well. However, I don't even see that as the major complexity you'll have to deal with. First and foremost, you'll need to be drop-dead compatible with the internal storage structure. This includes all the intrinsic variable types as well as the variant, objects, and collections. You'll have to handle both static and dynamic arrays. That includes strings being handled in Unicode but converted to ANSI when calling an API, writing to PropertyBag, or writing to disk. Arrays will have to be handled in precisely the same way too, as I have code that figures out whether a dynamic array is dimensioned or not withoiut error trapping. And variable length string garbage collectors are a rough chore for ANY language.
Bottom line, it's a HUGE job. I suppose you're doing it in some form of C with the hopes of going 64 bit. The problem is, anyone who's quite fluent in C is not going to be highly motivated to help you. Any chance you might have of getting this done would be to do it in VB6. That way, the hoard of extant VB6 programmers might come running to help. Yeah, you're boxing yourself in, but not that badly. New features could still be added and a 32bit program can write 64bit op-codes just fine. But it's just too big a job, and the existing VB6-IDE works just fine. In fact, it works so well that that's the reason we're having this discussion in the first place. Our only true hope is to try and pressure Microsoft to re-releasing VB6 (possibly with an upgrade) Here's a comment I posted elsewhere:
I've posted a list of recommendations for a VB7-COM product in many places through the years (64bit, easier unicode support, a Double-Long type variable, new Block/EndBlock keywords to reduce variable scope, ability to wrap OCX dependencies into the EXE along with manifest, and a few others). But I'd actually be happy with just a re-release of the VB6-IDE. Heck, they can put an "as is, no support" disclaimer on it if they like. Not only do they discontinue the product, but they've done everything in their power to kill backwards compatible licensing, declaring that a copy of .NET does not satisfy the VB6-IDE licensing requirements. It's as if publishers quit publishing the Harry Potter books (adamantly refusing to print more copies), but declared that they'd aggressively sue anyone who tried to make their own copies. I'm not talking about open-sourcing it, supporting it, or even providing any warranty of suitability for anything. Just sell my clients copies of it. I have several projects I've opened sourced in VB6 code and charge for consulting, adaptation, and customization. My clients would like the VB6-IDE so they can go forward with their own development teams, but they have to pay $2000+ for occasional copies of the VB6-IDE that appear on eBay. It's disrespectful, it's shameful, and it should be illegal. Heck, in my opinion, Microsoft would have been MUCH better off if they'd incorporated the VB6-IDE into their Windows OS (harking back to the days of their BASIC-OS). Imagine how addicted the world would be if they had a smart, easy-to-use programming language at their fingertips in Windows. They'd have half the world using it, and also clamoring for their OS to be ported onto every new platform (Tablets, Phones, etc) so that people could quickly write their own little VB6 style applications. Personally, I think that strategy could still work toward recovering their lost ground in the handheld markets if they would quit disrespecting the very people who have hung with them through thick and thin.
Now that Linux isn't viewed as an enemy of Microsoft, you may want to give Gambas a look. (3.6.1 released today)
For those who may be interested there is another open source project called BCX that does just what is being planned here.
The compile it ready and in production since many years. The visual IDE similar to VB6 IDE is still missing though!
The official web site is: http://www.bcxbasic.com/
There is Yahoo Group here: https://groups.yahoo.com/neo/groups/BCX/info
HTHQuote:
BCX was programmed entirely using BCX BASIC, making it a self-translating translator. And translating is FAST! BCX translates its own source code, over 24,500 lines of code, in just 1.2 seconds on a P4 laptop running XP Pro.
BCX BASIC to C/C++ Translator by Kevin Diggins (c) 2012
[Lines In: 24524] [Lines Out: 29246] [Statements: 22106] [Time: 1.22 sec's]
BCX translated BC.BAS to BC.C For a C Compiler
The C/C++ source code produced by BCX is highly portable and has been
successfully compiled using these seven popular C/C++ compilers:
Microsoft VC++
Borland Free Compiler
Pelles C Compiler
Mingw32
Digital Mars
Open Watcom
Lcc-Win32 Compiler
Yogi Yang
I am working on vb6 compiler that emit c++ that can generate object code using clang at the moment i am adding the namespace support to it after that i plan to add the class and inheritance stuff.currently it handles all vb native types (integer,long,string,byte,double,single and varient) and supports
on error *** statements
function definitions with optional byval ,byref ("optional byref" is not supported atm)
Arrays
Types
all conditional and loops statements
Generated code outputs line number information so source debuggin is possible
I intend to start an open source project once i get the compiler to be able to compile itself (for that i need to add the class support)
Thing that troubles me is that whether i should make a vb6 (COM) compatible class or a c++ class . if its a vb6 compatible class it can be exported as class library in vb6 but that makes it impossible (to my knowledge) for this new *vb7* to support inheritance since COM only support interface inheritance.hope to add implementation inheritance (or multiple inheritance if i could figure out a way out of "The diamond problem"
Also i plan to add a garbage collector instead of reference counting for objects management
more coming soon. hope to see your involvement with the project once i host the project
How far along are you at the moment?
If currently you have something working which compiles and emits VB-procedure-Code only,
maybe it's not too late to switch to "plain C-Code-emitting"?
The reason I ask is, because I've done tests already, which show promising results with real
"In-IDE-Edit&Continue-Debugging" (using the tinyC-Compiler as a kind of dynamically re-compilable
InIde-PCode-engine - but this nice and fast little compiler, which can compile directly into memory -
only understands plain C-Code).
I'd see no problem to implement COM-compatible Classes using plain C - and also no problem with
Inheritance using those C-implemented Classes.
You can send a regular E-Mail over my Forum-account to me, in case you have an interest in
discussing these things - maybe we can join forces.
Olaf
I havent checked tiny cc but Cling seems promising in the edit and continue part http://root.cern.ch/drupal/content/cling (always exited about higgs boson :P) which undestands c++ 11 .
problem is, its the limitation of COM,COM classes cannot handle implementation inheritance
Most vb6 language constructs are done including Types, in the middle of adding class support, ( also need to verify on the actual c++ output )Quote:
Originally Posted by Schmidt
In using Boost for handling higher level data structures like arrays and variants.
Compiler can handle this atm , (note that i intentionally added some syntax errors for error detection, its not a blind converter it verifies every statements down to each sub statement including types)
Code:Namespace System
Namespace Core
Public Function tFu_nction(Optional ByVal x as Long , _
Optional ByVal y as Integer="fgfg", _
Optional ByVal z as Long) as Integer
Dim xd As Integer, yc As Double, xu As Integer
x = yc = 123
Dim s As String
x = "123"
s=444
Exit Function
End Function
End Namespace
End Namespace
Public Type TestType
var1 As Long
var2 As String
var3() As String
End Type
Public Type TestType2
var1 As Long
var2 As String
var3() As TestType
End Type
Function Arraytest(g() As String) As String()
On Error Resume Next
Dim ff(1 to 9, 9 to 67) as String
Dim MyStruct as TestType
Dim MyStruct2 as TestType2
MyStruct2.var2=MyStruct.var1
ff(1, 9) = "its"
ff(2, 55) = "working"
Arraytest = ff
End Function
Function booltest() As Boolean
Dim Arr(4, 4) As String
Dim Arr2(1 to 9, 9 to 67) as String
Dim s As String
Dim ffft() As String
ffft = Arraytest(Arr)
s = Arr2(1, 9) '="its"
s = Arr2(2, 55) '="working"
Arr2(1, 9) = "***"
Arr(4, 4) = "its my life"
ReDim Preserve Arr(10, 67)
s = Arr(4, 4)
s = "12" + "99"
s = Arr2(1, 9)
booltest = 0
Dim x As Long
On Error Resume Next
While x < 7
x = x + 1
Wend
For x = 10 To 150 Step 10
If x = 100 Then Exit For
Next x
Dim Y As Long
factorial(x = 8)
Do While x < 8
x = x + 1
Loop
Do
Y = x
Exit Do
Loop
Do
Loop Until x < 8
End Function
Function factorial(ByVal n As Long) As Long
If (n <= 0) Then
factorial = 1
Else
factorial = n * factorial(n - 1)
End If
End Function
Public Function ffftFunction(ByVal x as Long,Optional xg as Integer=0,Optional z as Long) AS String
x = 5 + 7 * 8
On Error GoTo LastLine
x = System.Core.tFunction(7, xg, 0)
ffftFunction = "hello world"
On Error GoTo LastLine
If x > 0 Then x = x + "dd"
GoTo LastLine
LastLine:
911:
Resume Next
End Function
Private Function fact()
Dim TokPrec As Integer, ExprPrec As Double, xu As Integer
If TokPrec <> ExprPrec Then
fact = (System.Core.tFunction() = ".")
ElseIf TokPrec <= ExprPrec Then
Else
fact = 0
End If
fact = 5 + 7 * 8
End Function
Nice work!
Can you use the same label names within structures in the same program? (FUNCTION/SUB/MAIN)
You may want to have a peek at CERN ROOT as a development environment. (Interpretive C/C++) that uses cling for the compiler.
Within in same function NO , why ?Quote:
Originally Posted by ScriptBASIC
Not within the same function or sub but in the same program. Sorry for the confusion.
I'd strongly suggest, that you use the original type-defs and structs which are used underQuote:
Originally Posted by indika.online.lk
the covers of VB6 also (meaning the safearray and variant-structs here).
There's a lot of VB6-code out there which is accessing those structs at a lower level
(safearrays are accessed in VB e.g. for fast DIB-Handling - or fast String-Parsing - and
Variant-structs are accessed in quite some scenarios in the same way - e.g. with an
Offset of 8 Bytes, to reach the underlying Value or StrPtr or ArrPtr/ObjPtr which sits there.)
It's important to care about that in this early state, before (much) more things are packed
onto this groundwork - not easy to introduce such breaking changes as "safearray-compatibility"
at a later time.
Also the String-Type should be compatible with BSTR (since a lot of VB-Code is expecting
such an allocation to have 4 Extra-Bytes "to the left of the StringPointer" which describe the
allocated length in Bytes. Also the trailing Double-ZeroBytes should be ensured on that String-Type.
As for COM only supporting interface-inheritance (and not implementation inheritance)...
With a compiler one can juggle and re-arrange the VTable-entries as needed -
as well as defining extra-space in the Private-Vars-struct of the *inheriting* class
for the members of the Private-Vars-struct of the *inherited* Class.
That's how it could work at a lower level for the Compilers "own" generated classes.
In the simplest case - even with how VB6 actually works - we could accomplish
inheritance, when the compiler in case of our current interface-inheritance-scheme
just ensures also the *implementation* of those interface-methods, by drawing an
instance of the Class it inherited from - and delegating to the VTable-entries of that Class.
Expressed in VB-Code (all written by hand instead of a compiler-emitting-automatism):
If you define a BaseClass like this:
TypeName: cBaseClass
The above Class is not defining a "plain virtual interface" only, it also containsCode:Public Sub SayHello()
MsgBox "I'm a cBaseClass-instance"
End Sub
Public Function AddTwoLongs(L1 As Long, L2 As Long)
AddTwoLongs = L1 + L2
End Sub
the implementation behind the methods already.
Now, another class which plans to inherit that interface *and* that base-implementation
would be written this way in VB6:
TypeName: cDerivedClass
Code:'***** inheritance-by-delegation follows ******
Implements cBaseClass 'defines the VTable-entries we need to implement in addition
Private cBaseClass As New cBaseClass
Private Sub cBaseClass_SayHello()
cBaseClass.SayHello
End Sub
Private Function cBaseClass_AddTwoLongs(L1 As Long, L2 As Long)
cBaseClass_AddTwoLongs = cBaseClass.AddTwoLongs(L1, L2)
End Sub
'***** end of inheritance-by-delegation ******
'the cDerivedClass's own public Methods follow
Public Sub DoinMyOwnThang()
'...
End Sub
So - to support inheritance the compiler would do the delegation-code to the BaseClass
in above interface-signatures (the part within the asterisks) for us automatically by default.
As it is currently, a VB-developer is *enforced* to fill out any implemented (interface-inherited)
method-signature "by hand" (then in any single method being free, to either delegate to
the BaseInstance - or to "override" and putting his own stuff into the method-stub, which
can get quite straining when we talk about of 30 or more Public entries in the VTable,
although one planned to override only one or two members of the BaseClass).
So in the easiest case the compiler could be doing something like the above,
which is neither hard to understand nor to accomplish (at the code-emitter-level).
Olaf
This is why the namespace support was added to the compiler from the beginning cos runtime can expose different implementations of String,Varient by using namespacesQuote:
It's important to care about that in this early state, before (much) more things are packed
onto this groundwork - not easy to introduce such breaking changes as "safearray-compatibility"
at a later time.
Also the String-Type should be compatible with BSTR (since a lot of VB-Code is expecting
such an allocation to have 4 Extra-Bytes "to the left of the StringPointer" which describe the
allocated length in Bytes. Also the trailing Double-ZeroBytes should be ensured on that String-Type.
say if you add
orCode:using Classic.Types
the compiler uses the vb6 implementation, and use the vb6 project loader to automatically add this to source files when it converts the vb6 prj to new version.Code:using Classic.Types.String
This "Wrapping" is easy for single inheritance, but gets complected when handling multiple inheritance or polymorphismQuote:
As for COM only supporting interface-inheritance (and not implementation inheritance)...
With a compiler one can juggle and re-arrange the VTable-entries as needed -
as well as defining extra-space in the Private-Vars-struct of the *inheriting* class
for the members of the Private-Vars-struct of the *inherited* Class.
That's how it could work at a lower level for the Compilers "own" generated classes.
In the simplest case - even with how VB6 actually works - we could accomplish
inheritance, when the compiler in case of our current interface-inheritance-scheme
just ensures also the *implementation* of those interface-methods, by drawing an
instance of the Class it inherited from - and delegating to the VTable-entries of that Class.
How about doing it this way
Only COM classes are needed when you need to expose them outside the project, so what if we set the default classes to be c++ classes and public exposed classes to inherit from a class that support COM
something like
again this modification of the source can be added automatically by the project loader by looking whether it is a public or private class.So its transparent to the user.Code:Class ExposedClass Implements Classic.COM
End Class
since C++ already has the groundwork for inheritance , polymorphism , why reinvent the wheel,
thats one of the reason i choose c++ over c also to OOP to work propely we need runtime type infomation. for casting etc. so it get completed to implement it manually.
Olaf you are right we do need to talk about this now than later. so we can deduce the best implementation
ill post some c++ output of the compiler later on so i can be certain that im on the right track
Current compiler binary and vs2010 project of runtime can be seen at https://code.google.com/p/v7basic/
Runtime is really ugly atm, not to mention buggy , at this stage i only used it to check c++ code validity , but you can run it and single step the basic code :bigyello:
feel free to interrogate OpenBasic.exe by changing the test.bas
I didnt want to upload the boost library but i had to cos i modified some headers of boost multi_array.
I just ran into this framework for VB developers in C++ on sf.net.
Thought I will share it here it may be useful who knows.
http://ezbasic.sourceforge.net/index.php
HTH
Yogi Yang
@Schmidt you may consider the Chameleon Basic as a guide on the new Visual Basic 6.0 compiler.
http://sourceforge.net/projects/chameleonbasic/
Thanks for the link! I gave it a try and was surprised how far along this BASIC to ASM compiler has come. I hope the author continues with its development.Quote:
@Schmidt you may consider the Chameleon Basic as a guide on the new Visual Basic 6.0 compiler.
* Deleted *
Attachment 121157
Source: ANIMATION of the Visual Basic 6.0 incandescent bulb (simple GIF images): http://vb6awards.blogspot.com/2014/1...nt-bulb_8.html
Someone has successfully converted C code to VB6. What if doing the conversion in reverse. VB6 to C code then compile it. That behaviour is similar to Basic4Android. It uses VB.NET style syntax as frontend but java code at backend. Upon compilation, it transalates the VB.NET like code to java and compile it.
Because of that, then its possible to write a VB6 code, convert it to C++ code and compile it.
http://www.planetsourcecode.com/vb/s...12483&lngWId=1
It's already been tried on many previous incarnations, and all have stopped development (propably due to losing interest themselves).. You'll find some opensource versions already on github or some other public sites..Quote:
Originally Posted by rizalmartin
Prove it SupreDre. Show the links please.
sigh.... take your pick: http://basic.mindteq.com/ and be sure to check out the 'discontinued' section.....Quote:
Originally Posted by rizalmartin
but hee, maybe you can use one of those which made their source available and continue the work yourself...
Thank you for this link. This will help on developing a true VB7 compiler.Quote:
Originally Posted by SuperDre
Hi SuperDre,
I think you need to check this one: http://www.bcxbasic.com/
It is alive and updated regularly.
HTH
How is vb7, have you made any progress?
Sorry to resurrect the topic