Vb6 , the Future, and what I have discovered

[yereverluvinuncleber]

A few VB6 replacement projects rear their head from time to time but we have yet to see anything arrive in the flesh. Krool's controls are the currently the best that VB6-ers can hope for.

I feel a step by step approach for all the other previous VB6 replacements projects would have been the best approach, had they been FOSS possibly allowing the next developer to pick up the abandoned pieces of each previous failed project. Allowing others to do something constructive with each failure and allowing growth through shared code. We might have had some more usable bits by now.

As it is, I am starting to inherit the same scepticism that seasoned members of the forum have always displayed. I'd like to believe that TwinBasic has a future but I always have a feeling that such websites are prone to disappearing shortly after. I do wish them well though.

My hope rests in RADBasic as I think that developer has his head screwed on tightly and his approach is a good one.

[Niya]

A few VB6 replacement projects rear their head from time to time but we have yet to see anything arrive in the flesh. Krool's controls are the currently the best that VB6-ers can hope for.

I feel a step by step approach for all the other previous VB6 replacements projects would have been the best approach, had they been FOSS possibly allowing the next developer to pick up the abandoned pieces of each previous failed project. Allowing others to do something constructive with each failure and allowing growth through shared code. We might have had some more usable bits by now.

As it is, I am starting to inherit the same scepticism that seasoned members of the forum have always displayed. I'd like to believe that TwinBasic has a future but I always have a feeling that such websites are prone to disappearing shortly after. I do wish them well though.

My hope rests in RADBasic as I think that developer has his head screwed on tightly and his approach is a good one.

Using VSCode as a base actually makes it reasonable for one or two people to accomplish this so this one might be different. All the "smoke and mirror" talks about making one in the past always involved doing everything more or less from scratch and with only 1 or 2 people actually ready to put in effort, failure was inevitable. VSCode represents a boat load of work that doesn't need to be done. I don't think people get how much work is actually involved in creating a modern IDE. This is the most promising effort I've seen to date. Still though, I'd advise cautious optimism.

[Daniel Duta]

Thanks @Niya. Yes, everything is COM based. I've literally got thousands of tests to ensure TwinBasic mimics the (often subtle) nuances that would trip up a naive compiler.

100% backwards compatibility is the aim, but of course it will take a while to truly get there. I think (hope) you'll be pleasantly surprised at just how close the initial release gets to that target!

At first glance it is a very impressive achievement. I know that are some remarkable guys in this forum who had or still have similar projects for some time but I don't know if any of these projects have been successfully finalized. Did you work in a team or was it 100% a personal achievement ? On the other side, at least to me it is a bit strange that you didn't co-opt any of these very talented guys because they could have contributed to the project with many valuable things. Also, I am curious which is their feedback regarding your work, especially since such a product has been awaited by the vb community for so long.

[WaynePhillipsEA]

I totally understand the scepticism... all I can say is, watch this space. You won't have to wait long before you can start trying it out for yourself.

Tomorrow I will be releasing the next video which will demonstrate the debugger with a more interesting code example, as well as demonstrating both 32-bit and 64-bit support.

@Niya is absolutely spot on about VSCode. It has been an amazing benefit to the project, and means that others will be able to contribute their own extensions to the IDE side of things since VSCode is open source.

The development team on this is myself and my partner. I certainly don't doubt there are some incredibly talented developers on this forum(!), and I hope to expand the development team soon, assuming we get enough interest in the product going forward.

[Thierry69]

The most important is the compiler, to produce 64 bits app (not including multiple OS)

[Niya]

The most important is the compiler, to produce 64 bits app (not including multiple OS)

I donno. Is COM capable of working in a 64 bit address space? I don't actually know to be honest.

[WaynePhillipsEA]

TwinBasic compiler fully supports Win32 and Win64. Yes, COM works fine on Win64 (also Microsoft Office still heavily uses COM, and has been available in 64-bit editions since 2010).

[Niya]

Ah. Ok. That makes sense.

[baka]

I hope the members here, such as The trick, Schmidt, dilettante, LaVolpe, wqweto to name a couple really great programmers will be interested in this when its out. we have waited for this for many years and this could be the start of it.

I hope its compatible with the typelib Im using now to use direct2d.

[Elroy]

I donno. Is COM capable of working in a 64 bit address space? I don't actually know to be honest.

The VBA (both 32-bit and 64-bit) is all COM based.

[dilettante]

Yeah, the Windows Shell and much of Windows above the kernel level is heavily COM based.

Visual Basic should have been named Windows Basic. Or you could turn it around and rename Windows something like "VBOS."

[Schmidt]

Looks like the most promising approach so far (from somebody who seems to know what he's doing)...

But here's my assumptions (please correct me Wayne, if I'm wrong):
- it currently works only as an interpreter
.. (not compiling to "full native speed", which would rule out to compile e.g. the RC6-sources in a 64Bit-version)
- it currently has a whole lot of dependencies to MS-Dlls like for example the COM-related ones: OleAut32.dll, Ole32.dll, ATL.dll
.. (not allowing to run its own compiled Class-Libs on a Linux-System without Wine - e.g. as a VB-compatible NodeJS-replacement within a Docker-Container)

That said, it'd still be a "good start" - when the sources would be made available under a generous license later on...
(to be able to "fix" the points above - not sure though, whether opensourcing is planned - and under which license).

Olaf

[Niya]

None of his posts so far gave me the impression that he is using an interpreter but this is actually an interesting question.

[WaynePhillipsEA]

Thanks for all the feedback and questions so far.

@Schmidt, as of right now, yes, we are compiling to an interpreted state which is roughly equivalent to VB6 p-code (or what we call excode in VBA). I apologise if this wasn't clear; it is mentioned on the TwinBasic website.

However, it has long been planned to incorporate full native compilation via the LLVM backend compiler. In fact, it would be fair to say that the project has been designed specifically for LLVM, as I have wrote an LLVM based compiler before for an internal project, and I know it well. I am fully expecting to be able to have TwinBasic offer native code compilation within 3-6 months. LLVM is an amazing backend compiler, and it will be a great fit with this project.

We don't have any dependencies to ATL or any C++ runtimes. At the moment, we do have dependencies on OleAut32/Ole32, and it is most likely we will keep these in place on the Windows versions of TwinBasic for compatibility concerns. Replacements will of course be needed once we make an effort to support other OSes. There are currently about 1k lines of assembly, which is mostly needed to mimic the VBA x64 implementation of the floating point math (which occurs on the old 80-bit FPU rather than using newer SSE/AVX instructions). So we also need to rewrite that for non-x86/x64 based platforms. All in all, my current timescale for offering multi-platform support is 12-months.

Open sourcing of the compiler is not currently planned. The VSCode extension part is written in JS/TS (as all VSCode extensions are), so it makes sense for use to open source that part of the project.

[Niya]

May I ask how many of you are working on this currently?

[WaynePhillipsEA]

May I ask how many of you are working on this currently?

There's 2 of us, I am lead developer.

On another note, we've just put out the second instalment to the video which is available via the TwinBasic website. We demonstrate the debugging capabilities like breakpoints, callstack, live variables info, watch window, debug console and also show off running some proper legacy code and upgrading it to run in 64-bit.

[wqweto]

as of right now, yes, we are compiling to an interpreted state which is roughly equivalent to VB6 p-code (or what we call excode in VBA).

That is a viable approach for creating VB *compiler* because compiling a VB6 project to an executable might involve executing part of the code (so called comptime code) which can be done only by an integrated interpreter.

My idea for a "VBScript w/ types" compiler it to use interpreter's p-code/VM opcodes as a form of intermediate representation that is fed into LLVM but not sure if this is viable or p-code has to be dropped and just start populating LLVM's builder from the AST.

Will try some combined interpreter/compiler in rust during the holidays, something that can interpret `a = 5 : b = 2 * a : Wscript.echo b : Set c = CreateObject("Scripting.Dictionary")` and then compile a x64 executable.

cheers,
</wqw>

[baka]

since I work with Direct2D, what I need is a window to render the graphics.
I read GUI support, including backwards compatibility with VB6 forms.
will there be another form as well? if so, any benefit from using it?

In the new video I see that you need to replace Long with LongPtr and add PtrSafe in the API declaration.
Im thinking here, how to have 1 source that works with both 32 and 64 or a way to tell the IDE to skip or use lines depending on 32 or 64.
example

!32(
Public Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (lpDest As Any, lpSource As Any, ByVal cbCopy As Long)
)

!64(
Public Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (lpDest As Any, lpSource As Any, ByVal cbCopy As LongPtr)
)

that !32() any code, functions, declares, apis etc. will only be used in 32 mode, and !64() only in 64bit mode.

[Xusinboy]

since I work with Direct2D, what I need is a window to render the graphics.
I read GUI support, including backwards compatibility with VB6 forms.
will there be another form as well? if so, any benefit from using it?

In the new video I see that you need to replace Long with LongPtr and add PtrSafe in the API declaration.
Im thinking here, how to have 1 source that works with both 32 and 64 or a way to tell the IDE to skip or use lines depending on 32 or 64.
example

!32(
Public Declare Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (lpDest As Any, lpSource As Any, ByVal cbCopy As Long)
)

!64(
Public Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (lpDest As Any, lpSource As Any, ByVal cbCopy As LongPtr)
)

that !32() any code, functions, declares, apis etc. will only be used in 32 mode, and !64() only in 64bit mode.

In the VBA, the code will be like this:

#If Win64 Then
    Private Declare PtrSafe Function GetKeyboardLayoutName Lib "user32" Alias "GetKeyboardLayoutNameA" (ByVal pwszKLID As String) As Long
    Private Declare PtrSafe Function LoadKeyboardLayout Lib "user32" Alias "LoadKeyboardLayoutA" (ByVal pwszKLID As String, ByVal flags As Long) As Long
#Else
    Private Declare Function GetKeyboardLayoutName Lib "user32" Alias "GetKeyboardLayoutNameA" (ByVal pwszKLID As String) As Long
    Private Declare Function LoadKeyboardLayout Lib "user32" Alias "LoadKeyboardLayoutA" (ByVal pwszKLID As String, ByVal flags As Long) As Long
#End If

[WaynePhillipsEA]

In the VBA, the code will be like this:

#If Win64 Then
    Private Declare PtrSafe Function GetKeyboardLayoutName Lib "user32" Alias "GetKeyboardLayoutNameA" (ByVal pwszKLID As String) As Long
    Private Declare PtrSafe Function LoadKeyboardLayout Lib "user32" Alias "LoadKeyboardLayoutA" (ByVal pwszKLID As String, ByVal flags As Long) As Long
#Else
    Private Declare Function GetKeyboardLayoutName Lib "user32" Alias "GetKeyboardLayoutNameA" (ByVal pwszKLID As String) As Long
    Private Declare Function LoadKeyboardLayout Lib "user32" Alias "LoadKeyboardLayoutA" (ByVal pwszKLID As String, ByVal flags As Long) As Long
#End If

Exactly the same in TwinBasic. We have full conditional compilation support, in fact this will be seen briefly in the next video coming soon.

[WaynePhillipsEA]

@baka in most cases in TwinBasic you won't need conditional compilation. The LongPtr datatype is 32-bits wide on Win32 and 64-bit wide on Win64. The LongLong datatype is 64-bit wide on both architectures.

[WaynePhillipsEA]

@baka, with regards to forms, we might also look at supporting Microsoft Access forms, but that will come much later.

[baka]

thx for answering.
I think its time to make TwinBasic its own thread.

[peterst]

The expectations of many people for new VB6 successor is to be 150-200% compatible* with their source code and to run everywhere - from Win 98 to Win 10+, Android, iOS, MacOS, 80-90% of Linux distros. Well, maybe only on Windows systems.

* 150-200% compatibility is not only the project but also all dependencies from known and unknown sources (OCX, DLLs and others which don't have source available and most written 20-25 years ago)

The famous classic VB forms editor (and later WinForms in .NET) is the reason many people start with VB/VB.NET as this is the shortest path from no knowledge to some real application with multi-forms user interface, while using other language it may take days to get same results.

And there will be many disappointed. Its seen in VB.NET sub-forum where VB6-ers want the "old" behavior and don't want to change their mind.

If we skip forms editor, as it will cause lot of pain (e.g. .NET 5/Core forms editor is still preview), the language itself is good one. More important are the features, "frameworks", libraries, tooling and everything else, that makes it useful as modern development system.

[wqweto]

Btw, No-Code Platforms are on the rise in 2020-2021 getting showered by millions of VC investment, so our beloved VB6 IDE gets reinvented again and again. . .

cheers,
</wqw>

[baka]

I dont have those expectation at all.
what I would like is that it can deal with the "basic" stuff, if any old and outdated ocx would not work its not the end of the world.
its not that we need to stop working with VB6, its more like a new IDE that we use for new projects or "recent projects".

for me its about a migration where I can use my knowledge of VB6 in this new IDE.
its not only the ability to start coding from the beginning, since I already know the basics and language syntax, but also that I can still use vbforums.com as the main source of help and interesting discussions.

this twinbasic, if continued and worked on, could give what we all need to have a programming language that are as good as any new and modern one.
will there be limitations? some vb6 code dont work? is there a need to change parts of the code I have done?
as long its possible to achieve what I did have in mind, I dont mind. a new IDE will require some work and I expect that.

in the future, if everything goes well, and the dev is starting to look into the possibility to add compilers for mac/android/linux, we can now really start to create applications for any platform using visual basic as the syntax language.

[Niya]

in the future, if everything goes well, and the dev is starting to look into the possibility to add compilers for mac/android/linux, we can now really start to create applications for any platform using visual basic as the syntax language.

Aren't there already things out there on the market that can target different platforms with the BASIC syntax? Why try to re-invent this stuff? Isn't the point of all this to have a modern IDE with some modern features that is 100% compatible with VB6 projects?

[baka]

all the different programming alternatives I tried are not even close to VB6. so its not re-invention at all but progression.

[SearchingDataOnly]

Aren't there already things out there on the market that can target different platforms with the BASIC syntax? Why try to re-invent this stuff? Isn't the point of all this to have a modern IDE with some modern features that is 100% compatible with VB6 projects?

At present, there is almost never a VB6 alternative's IDE that its user experience can reach 30% of VB6-IDE.

IMO, there are three best desktop application IDEs in the world: VisualStudio.NET, Delphi and VB6-IDE. The features of VB.NET (or C#) IDE is 120%-150% of VB6-IDE, but its complexity is 300% of VB6-IDE. In other words, the only IDE that can perfectly combine simplicity, ease of use and efficiency is VB6-IDE.

VSCode is currently the best code editor, but it is not an IDE. Although VSCode can expand a large number of features through plug-ins, the user experience of using VSCode to develop VB6-Apps can hardly reach 50% of VB6-IDE. But WaynePhillipsEA's choice of VSCode as TwinBasic's IDE is still a very wise choice, because there is no better choice.

I believe Olaf can develop a good enough alternative language for VB6, but I don't know how Olaf can achieve a new IDE that is as close to perfection as VB6-IDE.

(From dm)

[Niya]

all the different programming alternatives I tried are not even close to VB6. so its not re-invention at all but progression.

As far as I could see B4J is as close as you could possibly get to a "VB6" to write code for Android. If TwinBasic goes in that direction, it's just gonna be a cheap knock-off of this.

I know it's exciting to think about all these exciting possibilities, but don't forget how all this started. You guys wanted a modern VB6 that's fully compatible with VB6 projects and you finally seem to be getting it after more than nearly 2 decades. Don't lose sight of that and get lost with all these extra requirements because you most likely will not like what comes out the other end.

[Niya]

At present, there is almost never a VB6 alternative's IDE that its user experience can reach 30% of VB6-IDE.

IMO, there are three best desktop application IDEs in the world: VisualStudio.NET, Delphi and VB6-IDE. The features of VB.NET (or C#) IDE is 120%-150% of VB6-IDE, but its complexity is 300% of VB6-IDE. In other words, the only IDE that can perfectly combine simplicity, ease of use and efficiency is VB6-IDE.

VSCode is currently the best code editor, but it is not an IDE. Although VSCode can expand a large number of features through plug-ins, the user experience of using VSCode to develop VB6-Apps can hardly reach 50% of VB6-IDE. But WaynePhillipsEA's choice of VSCode as TwinBasic's IDE is still a very wise choice, because there is no better choice.

I believe Olaf can develop a good enough alternative language for VB6, but I don't know how Olaf can achieve a new IDE that is as close to perfection as VB6-IDE.

(From dm)

Why not just stick with the VB6 IDE because anything else can only ever be "something like it". Nothing can be VB6 but VB6. See what I'm saying?

[baka]

for me personally I dont care about a fancy modern IDE, I want functionality.
I also don't care about .ocx compatibility, since I don't use any.
I don't care about any component, since I create my own buttons, textboxes, menus etc.

so if this twinbasic will not grant me anything fancy, I dont care.
what I want is a way to compile my project to 32 and 64 bit.

right now twinbasic is the closest so far for what I have been waiting for.
will it fail? well, I still have VB6

but do you really think that I would still be using VB6 if there was something better to use?
I enjoy working in VB6 and if Im gonna change it will be because I feel its worth it.

if twinbasic is not that, I will keep using VB6.
so all those warnings, Im not sure why you keep writing those? Im not a child, I can deal with disappointments.

[WaynePhillipsEA]

Hi everyone, we just wanted to say thanks for all the comments and feedback on TwinBasic (and the future of BASIC in general) so far. We are very much listening, and all the feedback helps to direct or at least help us prioritize the work in front of us.

[Niya]

so all those warnings, Im not sure why you keep writing those? Im not a child, I can deal with disappointments.

Stop taking things so personal. You're not the only one on this side of the fence that talks about this stuff. Truth be told, I was actually thinking more about axisdj and another dude who's handle I can't remember right now when I wrote that, not you. I remember them being so caught up in their feelings about Microsoft abandoning VB6 that they let it get in the way of common sense and facts. With regards to Android support, I was thinking specifically of dilettante. Dilettante biggest gripe from day one was .Net being "bloatware" because of the Framework. Well guess what, Android is not Windows. If you want to write VB6 code for Android, you're going to have to include some kind of "bloatware" Framework to support all the stuff VB6 programmers are accustomed to like Collections, StdPictures etc. The more compatible to VB6 you want it to be, the more "bloated" the Framework would have to be. You think there is such a thing as an hPicture on Android? Yet if you wanted high compatibility with VB6 code you're gonna have to implement that in the Framework and have it internally translate it to whatever the Android equivalent might be. That's a whole lot of code. How long do you think it will be before someone like dilettante comes along and starts complaining about how bloated the Android framework is.

Point is, I get that you guys love VB6, but you tend to get so passionate about it that it blinds you to the point of not being able to be completely objective and reasonable. Let Wayne do his thing and give you guys what you want and think very carefully about what you're asking for, because as I said before, you may not like what comes out the other end.

[dilettante]

As far as I could see B4J is as close as you could possibly get to a "VB6" to write code for Android.

I suspect you meant B4A, but the syntax is similar to B4J and the code editor and libraries are almost identical... though the GUI designers are different.

[Niya]

I suspect you meant B4A, but the syntax is similar to B4J and the code editor and libraries are almost identical... though the GUI designers are different.

I didn't get to B4A. I searched for Android BASIC and as soon as I checked out B4J among the search results, I was surprised at how strikingly similar it is to writing BASIC code is Visual Studio. I was impressed enough with what I saw that I might actually give this thing a try. Xamarin only allows you to write C# code and while it's only prudent to drop VB in favor of C#(Since it seems the future of MS is C# and not BASIC), I'm thinking this might at least be worth checking out before I made that commitment. Not that I'm look for a way to avoid C# but it would at least be nice to write Android code in language I've grown accustomed to in the mean time. I'll look into B4A as well.

[Erel]

I suspect you meant B4A, but the syntax is similar to B4J and the code editor and libraries are almost identical... though the GUI designers are different.

That was true in the early days of B4J. Now they are based on the same visual designer (the native controls are different). You can actually copy and paste views between the three platforms - B4J, B4i and B4A.

[baka]

I dont think we need to take the job of taking care of peoples emotions. if they can't deal with disappointments, the best remedy is disappointments and hopefully they learn from it.

of course we should have a critical mind, Im thinking that, programmers are working with logical thinking, so they should be able to do any logical assumptions without putting too much emotions into it.
so, its not that Im putting all my money of TwinBasic and start dreaming of a fantasy world where it will be the perfect tool for me and everyone else.

I enjoy the expectations and I like to think this could be it, this without making it personal so that I will die if it will not work like I hoped.
so, for me, I rather think positively than negatively and that WaynePhillipsEA feels that we are happy and have expectations of his project instead of being critical and start to argue to not get your hopes up or that "this has been doing a long time, don't expect anything, just failures" attitude. to have a negative attitude helps nobody.

[yereverluvinuncleber]

With regard to people's desires for a new VB6? well, that discussion has been done to death. Dare I say it but the different viewpoints and the arguments it engenders are the main the reasons why this community of clever programmers has never come up with its own solution even given its own admitted capability and plenty of time to do so.

For me the VB6 IDE is a good place to work in, it interfaces with user's own controls, is extensible and does more than just acting as an IDE, it IS VB6, just as much as the language itself. The IDE and its quirks, the language and its quirks are a package.

VB6 the package, as it is today - equates to one person's desires for VB6 just as much as the desire for new language features, native 64bitness and multi-platform capability, future capability equates to another's. We all want something different. It can't all be done at the same time and trying to obtain them all in order to please everyone is the mistake. It has to be done in steps.

For me the initial goals to aim for would be the IDE, the language and its quirks retained and 64bitness to provide that future proofing. However, as I already have the real VB6, the language and its quirks to fall back on, I really don't need a whole new VB6 as the first step.

So, the first thing I would aim for if I were the main dev working on a VB6 replacement, would be the ability to compile to 64bits, to give it 64bitness. I was never previously that keen on 64bit with regard to real requirements (my programs will never require 3gb of RAM) but I have come to realise that although for a lot of devs here the 64bit capability is just a badge, it is actually a badge that could tell the world that VB6 has no limits and is no longer stuck in the past. This one change could make VB6 seem to have a future.

With the impending demise of 32bit apps on Windows (that might never happen?), the certainty that the 64bit binary provides is very important. Like the "Intel Inside" badge, it seems to mean very little but it does give a lot of confidence to the user.

The other stuff can come later, step by step.

[Niya]

I dont think we need to take the job of taking care of peoples emotions. if they can't deal with disappointments, the best remedy is disappointments and hopefully they learn from it.

of course we should have a critical mind, Im thinking that, programmers are working with logical thinking, so they should be able to do any logical assumptions without putting too much emotions into it.
so, its not that Im putting all my money of TwinBasic and start dreaming of a fantasy world where it will be the perfect tool for me and everyone else.

I enjoy the expectations and I like to think this could be it, this without making it personal so that I will die if it will not work like I hoped.
so, for me, I rather think positively than negatively and that WaynePhillipsEA feels that we are happy and have expectations of his project instead of being critical and start to argue to not get your hopes up or that "this has been doing a long time, don't expect anything, just failures" attitude. to have a negative attitude helps nobody.

I'm not saying to not get your hopes up, I'm saying be careful with what you ask for. It's easy to say you want this and that but someone has to think about how to engineer that. Someone has to spend time actually doing it. You don't know what they have to do to get it done and even the engineers themselves wouldn't know. Sometimes you would have to give up things and that has the potential to make a lot of people unhappy.

What Microsoft did by abandoning VB6 for .Net was insane at the time. It was a very huge risk for them to go with something completely new and untested over something that was already a proven success. Why would anyone do something so insane? Well it turns out, they felt that going forward with their vision for the future of Visual Basic couldn't stand on the foundation they built. They felt it wasn't engineered to support the things they had in mind and the only way forward was to start from scratch which is how we got VB.Net. Now whether that is true or not is irrelevant. They are the ones putting in the work and only they know the EXACT challenges of bringing their vision to reality and we really don't get to question that. Now their gamble paid off, .Net was a resounding success but it left a small minority very unhappy.

The same thing could happen here. Everyone is already hopeful. But when you start asking for this feature or that feature, remember he has to figure out how to engineer that and his solutions could very well lead to changes that people don't like. I'm not saying he shouldn't add new features. He should. There are many things that could be brought to VB6 that without changing the essence of it. But be careful about going too far, otherwise you better be prepared for what comes out.

I'll bottom line this. I think it would be a good idea to focus ONLY on being 100% compatible with VB6 for now because as far as I could tell, this requirement ranks very highly among the people this is intended for. You could add a couple of small things that don't really break anything like new data types or 64 bit compilation and what not. But get the core of what you want out of the way first. And when you get finally something that makes everyone happy, then you can have a discussion about how to move forward. A very careful discussion.

All of this is just my opinion though. The opinion is one man is just that. Take it as such.