What if there was a NEW vb6

Hello Group,

I am about to start a KickStarter campaign to gather funds for 3 options, all to save existing vb6 projects.

They are:

1. Funding vbRichClient to become a full IDE and compiler replacement for vb6

or

2. Funds to pay developers to write a binding to QT or Lazarus or Delphi or Xercoder or even .net native.

or LAST RESORT!

3. Lawsuit against MS for dropping vb6 Support

...

So that is the overview. My thought is that the vb6 replacement has to compile at least 95% of current projects code, with 5% code changes necessary.

That means it needs to do 95% of what vb6 does now.

My question to you is, if you could import and compile your code with up to 95% compatibly, would you switch? I think that is the base goal, we must FIRST get vb6 compatibility and then move to improve things from there. What are your thoughts?

Thanks
WP

Wow... I thought you would have dropped this by now.

Good luck on that lawsuit. I would hate to think that I would be sued for not releasing support my software 15 years after I sold it and 10 years after its intended life cycle was over.

VB6 was not meant to work with 64 bit systems, nor anything beyond Windows XP. The fact that it does still work should be seen as a plus.

The horse is dead, stop beating it ;)

I have to agree with DataMiser give this whole lets bring back VB6 **** a rest! I for one am getting sick of the arguments those threads have caused.

If it could import all my VB6 projects and compile it without problems and I could install that NEW language in new OS then I will use that to maintain my VB6 projects.

Not again, please stop, it's really getting pathetic...

Quote:

---

Originally Posted by axisdj

Hello Group,

My question to you is, if you could import and compile your code with up to 95% compatibly, would you switch? I think that is the base goal, we must FIRST get vb6 compatibility and then move to improve things from there. What are your thoughts?

Thanks
WP

---

Hi WP,

I think you need to define just what you are suggesting.

95% compatibility sounds good. But 95% of what ?

Will that include ActiveX/OCX support (at least on a 32 bit compile) ?
Will it support DAO and ADO ?
Will there be a migration tool that actually works (imports forms and code)?

Or are you just talking of 95% language compatibility, but no ActiveX support and no migration tool ?

I think the key is providing a product that will persuade VB6 users to move, don't do like Microsoft and develop a "better" but incompatible product - Microsoft have shown that doesn't work.

Arnoutdv, this is not pathetic!! If you have nothing positive to contribute, just don't bother contributing. Some of us make a living from the VB6 applications we have written and Microsoft have pulled the rug from under our feet without a viable alternative. I have applications with 100's of 1000's of lines of VB6 code working in companies all over the world and migration to .Net is near on impossible (believe me I have tried) Anyone out there who can give us a any sort of improvement on the VB6 IDE will be hailed as hero's. The guys at AX Tools (codesmart IDE tools) have done a really good job, but a fresh IDE to help improve the VB6 experience would be fantastic news for those of us who will be maintaining and tweaking VB6 code for many more years to come.

If you insist of prolonging this sort of discussion, please post in the appropriate forum. General Development perhaps and leave this one for what it's intended for. i.e. assisting those with VB6 questions / problems.

Thread moved to the 'General Developer' forum.

It is pathetic.
We have multiple VB6 projects too, and we still maintain and update them
But blaming Microsoft for replacing VB6 with VB.Net in 2002?
The VB6 IDE and compiler environment still works in windows 8.1, so what is your problem?
You have had 12 years since the end of VB6 to migrate and/or start developing in .Net
Why do you want a new IDE, if the language itself is not improved?
Just for the IDE???

Quote:

---

Originally Posted by sten2005

Hi WP,

I think you need to define just what you are suggesting.

95% compatibility sounds good. But 95% of what ?

Will that include ActiveX/OCX support (at least on a 32 bit compile) ?
Will it support DAO and ADO ?
Will there be a migration tool that actually works (imports forms and code)?

Or are you just talking of 95% language compatibility, but no ActiveX support and no migration tool ?

I think the key is providing a product that will persuade VB6 users to move, don't do like Microsoft and develop a "better" but incompatible product - Microsoft have shown that doesn't work.

---

I definitely think ActiveX/OCX must be included.
DOA and ADO will be a Priority

Yes you must be able to compile your code in a matter of hours after only MINOR changes.

WP

All I think most people are after, will I am anyway, is a improved or alternative IDE for VB6, or a way to use a more modern IDE like Visual Studio, in the same way Visual Studio can support other languages like Python, Java Script etc. An IDE to improve productivity while working with VB6 code like code folding, refactoring, better line number visualisation at design time etc. I am not really after something that fundamentely changes the language itself, maybe x64 like VBA now supports, but that is a minor thing in my view. VB6 code runs fast for LOB applications, and it just works. Yes, newer languages, C# in particular, have an improved syntax which can help improve coding and are OOP, but for a end user looking at a form on a screen, they could care less about what language you chose to write the application in, so long as it works, fast (.Net cold start lag time is a problem). A large VB6 application CANNOT just be migrated to .Net without a complete rewrite, I have tried and wasted god only knows how many man hours of the last 12 years trying to do so, so I have no alternative but to continue to work with VB6. So yes, I just want to get a new IDE to work with my existing VB6 code base, so hopefully someone comes up with a solution :)

here is a rough draft of the kickstarter project to gather funds for a vb6 imported/replacement. Please comment on how it can be improved.

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::Visual Basic 6 (VB6) Replacement Compiler and IDE::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

vb6 was one of the most used and popular development

environments ever created. It is estimated that there were

over 6 million professional developers using this software. In

2002 Microsoft decided that vb6 in its current state need to

be changed, they created vb.net with Major changes to code

syntax. These changes made converting vb6 programs to

vb.net almost impossible and the recommendation was to re-

write your apps. Many of these applications run systems for

companies and big and small. Converting these

applications is a huge waste of money and resources.

Fast forward to 2014, and still today vb6 apps are prevalent

in many companies to run the core business. In June 2014 a

petition with over 7400 votes on the Microsoft user voice site

was denied by the same person who denied a petition in

2005 of over 15,000 programmers. Clearly the demand is

there to bring back vb6. Many have tried to re-create this ide

and compiler but all have failed. The reason is that they were

not at least 95% compatible. The vb6 replacement MUST be

at least 95% compatible with the original version to be a

success. The starting point for the new version must be to

bring it to exactly where vb6 is today, and then improve it in

the future.

That is where this campaign comes into play. Our goal is to

gather funds to re-create a vb6 IDE and Compiler. It will only

succeed if at least 95% of the vb6 code is importable and a

programmer can import his/her vb6 project and re-compile it

in a few hours. That is the hard part. Although vb6 has been

deemed the step child in programming language, its simplicity

is achieved by many very complex workings under the hood.

I believe there are three primary options to get this new vb6

ide/complier done, but it takes money and time. There are

many out there already attempting to complete this task, but

they all do it in their spare time and therein lies the problem. If

we could gather funds to make this their full time job this new

vb6 will become a reality.

This project will require a HUGE number of people to commit

a small amount of money.

What you Get:

1. You get a way to move your large project into the future with a new way compile your vb6 Project.
2. All sponsors will be mentioned in the about screen.
3. The project will when completed be publicly published to preserve it for the future.

Once funds have been generated I see three options:
1. Pay Olaf creator of vbrichclient to complete his project of a full vb6 replacement ide and compiler.

2. Hire a group of developers to write a binding for vb6 using Lazarus the open source delphi ide/compiler.

3. offer a company like xerocoder.com the cash to generate the vb6 replacement.

Isn't there already such a kickstarter? I seem to remember seeing something about it in a thread somewhere. Perhaps it was referenced in Olaf's thread about an open source VB6 project, though I'm pretty sure it wasn't him, and I rather think that the reference wasn't even this forum.

In any case, Olaf probably knows more about that. I wouldn't go flooding the world with competing kickstarter projects for competing visions of the same thing. That seems likely to cause all of them to fail.

Quote:

---

Originally Posted by Shaggy Hiker

Isn't there already such a kickstarter? I seem to remember seeing something about it in a thread somewhere. Perhaps it was referenced in Olaf's thread about an open source VB6 project, though I'm pretty sure it wasn't him, and I rather think that the reference wasn't even this forum.

In any case, Olaf probably knows more about that. I wouldn't go flooding the world with competing kickstarter projects for competing visions of the same thing. That seems likely to cause all of them to fail.

---

As far as I know I am the only one that has proposed this.. But I will check, I agree if it is already there..

Thanks
WP

Do check. I'm sure I read a discussion about it, and I regret that I don't remember where. That also means that it may have been ONLY a discussion, and not a real thing.

The one change I would suggest is that you make Integer a 32-bit value, long a 64-bit value, and Short a 16-bit value. The reason I would suggest this is that it has become something of a standard (though I think that may be officially a standard only in C/C++). It would be nice if an Integer was an Integer across all platforms. As a change, it wouldn't be a terribly significant one.

I wouldn't migrate any of my VB6 apps, though. In all these years, the requirements have changed. If anybody wants me to make any changes, they get a new program, not a re-hash of the old one. There is only one of those programs that solves a problem that hasn't fundamentally changed in the intervening years. For the rest, the problem they were intended to solve has changed, so a re-write is better than a migration anyways. The only thing that is keeping that re-write from happening is....a sordid combination of money, politics, inertia, ignorance, and a few spices for flavor. For the rest of the programs: I'd rather that they just broke.

By the way, I love the lawsuit idea. If you win, could you send me a PM about it before the news media gets ahold of it? I want to sue Borland for the Quattro Pro macros that no longer run, Microsoft for the Excel95 macros that no longer run, and Intel for creating the 286 that rendered my 8086, clock-dependent, Joust game quite useless (I couldn't hit the key fast enough to get the bloody ostrich off the ground at 12 MHz).

I think you had best be a whole lot more specific about the 5% change you will tolerate. That may sound all warm and fuzzy, but it's a total landmine to the whole project. If you consider an absurd example, such as getting rid of the keyword With, it would be far less than 5%, but it would break a HUGE number of programs. There are any number of other examples that can be seen as 5% from one vantage, while not from another.

For that reason, I think you should probably remove that 95% compatibility thing. Make it 100% compatible, or forget about the whole thing, because people will drive a truck through whatever gap you leave.

Quote:

---

Originally Posted by Shaggy Hiker

I think you had best be a whole lot more specific about the 5% change you will tolerate. That may sound all warm and fuzzy, but it's a total landmine to the whole project. If you consider an absurd example, such as getting rid of the keyword With, it would be far less than 5%, but it would break a HUGE number of programs. There are any number of other examples that can be seen as 5% from one vantage, while not from another.

For that reason, I think you should probably remove that 95% compatibility thing. Make it 100% compatible, or forget about the whole thing, because people will drive a truck through whatever gap you leave.

---

Very Good point. I agree. I think 100% of native exe's should be the goal.

Thanks
WP

Duplicate threads merged - please post each topic only once.

Oh, so you are Winston potgieter! I think 1 hindrance on this kickstart project is that Olaf is not entertaining the idea of being able to import existing VB6 projects, at least that's what I remember from this threads.

I see now that I misread the VB6 is DEAD thread post #495. Because you left out the comma after thank you, I interpreted that as you had heard something from Winston Poltregeister, but now I see that you ARE him. That makes more sense. I thought you were simply copying his stuff on a lot of things, but in reality it was just you posting the same thing on different forums.

Quote:

---

petition with over 7400 votes on the Microsoft user voice site

was denied by the same person who denied a petition in

2005 of over 15,000 programmers. Clearly the demand is

there to bring back vb6.

---

Hmm this would indicate that the demand is less than 1/2 what it was in 2005 and if your stat is correct about there being over 6 million professionals who used VB6 that is a very very small percentage.

Also consider that many of the people who vote in these things are not professional developers and do not even own a legit copy of the software so you have maybe 3000 that actually own a legal copy of VB which is a far cry from 6 million.

That said if a new option became available I would look into it but would not invest any money into it until it was proven in the field.

Actually, you have to be very careful when comparing those two. The second poll is not a one person one vote poll. A person can add up to three votes. This means that on any of those user voice polls (the first one), the number of voters is a fraction of the vote count. We can assume that of the people who voted, the average votes per person should be somewhere between 1 and 2, except that we have also seen that the people who want VB6 revived include some individuals who are exceptionally passionate on the issue, so it is quite likely that the number of votes per person is greater than 2, though probably not as high as 3.

Furthermore, there is no mechanism on the User Voice site to prevent box stuffing, so it is possible for people to have voted multiple times in order to run up the vote. Whether or not this has happened is impossible to tell from the numbers, but if it did happen, then those individuals would certainly have given the full three votes each time, so their count could be WAY above 3.

Lastly, there is a considerable difference in exposure for different polls. For example, I never even heard of the first one, and wouldn't have heard of the second if WP hadn't posted a link to it. So, comparing the polls is unlikely to be even remotely valid. The one thing we can say with some certainty is that the 7000+ in the User Voice poll doesn't represent 7,000 distinct people, and is likely less than half that.

Quote:

---

Originally Posted by DataMiser

Hmm this would indicate that the demand is less than 1/2 what it was in 2005 and if your stat is correct about there being over 6 million professionals who used VB6 that is a very very small percentage.

---

My exact thoughts when I first read through the OP's draft copy; not exactly persuasive. And this is compounded by Shaggy's equally valid observations about the veracity of the numbers in the first place. IMO, if there is a demand, you need to establish what it is for yourself (hard work) and then demonstrate that demand to potential subscribers to the project. Relying on pop-polls ain't gonna cut it, I don't think...

Is Tiobe Index referring to just vb6 - Who Cares
Is vb6 a language for only non-professional programmers? Who Cares
Does it matter that vb6 is not truly OOP as defined by todays academics? NO!
Does it matter that all you .net / c++ OOP drones think that vb6 is a toy? NOP!

I don't really give a crap what you think about vb6.

All I know is my two products, where I make a living, are written in VB6. They work, People love them.

I will find a way to re-compile them from my current code base. I am not going to waste my time re-writing my software to get to the same functionality, that is just STUPID!

If all of us who do care and have projects like mine come together we will find a solution!

Good DAY!

http://forums.watchuseek.com/attachm...8108528268.jpg

Quote:

---

Originally Posted by axisdj

or LAST RESORT!

3. Lawsuit against MS for dropping vb6 Support

---

Attachment 116337

Quote:

---

Originally Posted by axisdj

I don't really give a crap what you think about vb6.

---

Rather an odd thing to say since your thread kind of asks that question. You even seemed to want to get people to invest into it so what they think of it would be rather important don't you think?

As for re-writing your software, this is where you would improve it and perhaps add new functionality. Not much point in rewriting if you are not going to change anything that would be kind of stupid.
Then again using a product that was pretty much dead 10 years ago to write the software that pays your bills and then expecting that Microsoft would cave to your desires is not the smartest thing either ;)

Quote:

---

3. Lawsuit against MS for dropping vb6 Support

---

Fantastic, absolutely fantastic, i vote that you go straight for option 3 and Sue Microsoft!

I've lately been finding that some of my VB6 customers are experiencing odd crashes around calls to SQL stored procedures. Getting what appears on the surface to be a timeout on the client side when in reality the SPROC runs instantly in QA. Now I'm a database programmer for 30 years and I know how to debug problems. I've not gotten to the bottom of this one yet - and I'm starting to suspect that ADO is not keeping up with how the server-side is processing requests.

The only lucky thing going for me is that I have a migration plan that I started three years ago that I can use to re-build these screens or interfaces. Plan is to leave the VB6 stuff behind ASAP.

If I had a modern VB6 replacement IDE that ran in all new versions of WINDOWS - that would accept the SOURCE and PROJECT files from this VB6 app - I would have possibly changed my migration strategies.

Although part of the strategy has to involve your customers. Do they still want a VB6-only user-interface? From my customers I am able to get funds for the migration - it might be multi-year with some - might not be full development costs for others. Regardless, as an ISV I have always thought of myself as a professional like an architect or lawyer. Some hours you work are fully compensated for - others are support and maintenance - some pro bono.

What are the two applications that you make a living with actually do? Do they involves MS SQL-like databases?

If you're really serious about getting a new VB6 then crowd sourcing's probably a pretty good place to tsart. Apart from anything it's going to provide you with a much better indicator of whether there's any demand for it than the various surveys you typically link to. If people are willing to put their hand in their pocket there's a demand. If they're not, well then there really isn't. So I say take a punt and see what happens.

However, I do think some of your suggestions as to what you'll actually do with the money are flawed:-
1. Don't sue Microsoft. Whether you like it or not VB6 was their intellectual property to do with as they wished. They have no legal or moral obligation to you.
2. If the VBRichClient is the project Olaf was working on in the project communication area then he explictely stated that he wasn't interetsed in supporting old VB6 apps. That's not the product you're looking for.

So the only real option you've given for spending the money is to pay a group of developers to develop it for you. That may be sensible if you can find people with the skills and if you can generate enough funds to pay them. The first part of that equation shouldn't be difficult. The second part, however, I have my doubts. Good luck though.

Quote:

---

All I think most people are after, will I am anyway, is a improved or alternative IDE for VB6

---

This is a position I don't think I've seen expressed before and I struggle to understand it. Everyone else I've seen in the "Bring back VB6" camp has wanted some feature or other added, otherwise whats the point? I've heard there are difficulties getting Visual Studio classic to rin in Win 8 or 8.1 (though many people have succeeded) but surely just maintaining an old XP machine for development would be alot less hassle than writing your own ide.

Quote:

---

Originally Posted by szlamany

- some pro bono.

---

That's when you are listening to U2, right?

Quote:

---

Originally Posted by szlamany

I've lately been finding that some of my VB6 customers are experiencing odd crashes around calls to SQL stored procedures. Getting what appears on the surface to be a timeout on the client side when in reality the SPROC runs instantly in QA. Now I'm a database programmer for 30 years and I know how to debug problems. I've not gotten to the bottom of this one yet - and I'm starting to suspect that ADO is not keeping up with how the server-side is processing requests.

The only lucky thing going for me is that I have a migration plan that I started three years ago that I can use to re-build these screens or interfaces. Plan is to leave the VB6 stuff behind ASAP.

If I had a modern VB6 replacement IDE that ran in all new versions of WINDOWS - that would accept the SOURCE and PROJECT files from this VB6 app - I would have possibly changed my migration strategies.

Although part of the strategy has to involve your customers. Do they still want a VB6-only user-interface? From my customers I am able to get funds for the migration - it might be multi-year with some - might not be full development costs for others. Regardless, as an ISV I have always thought of myself as a professional like an architect or lawyer. Some hours you work are fully compensated for - others are support and maintenance - some pro bono.

What are the two applications that you make a living with actually do? Do they involves MS SQL-like databases?

---

They are theatrical and stage production intelligent lighting control and radio automation

Quote:

---

Originally Posted by FunkyDexter

If you're really serious about getting a new VB6 then crowd sourcing's probably a pretty good place to tsart. Apart from anything it's going to provide you with a much better indicator of whether there's any demand for it than the various surveys you typically link to. If people are willing to put their hand in their pocket there's a demand. If they're not, well then there really isn't. So I say take a punt and see what happens.

However, I do think some of your suggestions as to what you'll actually do with the money are flawed:-
1. Don't sue Microsoft. Whether you like it or not VB6 was their intellectual property to do with as they wished. They have no legal or moral obligation to you.
2. If the VBRichClient is the project Olaf was working on in the project communication area then he explictely stated that he wasn't interetsed in supporting old VB6 apps. That's not the product you're looking for.

So the only real option you've given for spending the money is to pay a group of developers to develop it for you. That may be sensible if you can find people with the skills and if you can generate enough funds to pay them. The first part of that equation shouldn't be difficult. The second part, however, I have my doubts. Good luck though.


This is a position I don't think I've seen expressed before and I struggle to understand it. Everyone else I've seen in the "Bring back VB6" camp has wanted some feature or other added, otherwise whats the point? I've heard there are difficulties getting Visual Studio classic to rin in Win 8 or 8.1 (though many people have succeeded) but surely just maintaining an old XP machine for development would be alot less hassle than writing your own ide.

---

Actually I have been in contact with Olaf, and he is open to creating a full replacement. His only opposition at this time is the doubt that any compiler besides the MS based ones may not work in the future. So for now he is waiting to see what signs we are given in windows 9 to the future compatibility of compilers outside of the MS orginzation. The whole windows store thing has us wondering where thing are moving.

I also got a great lead yesterday from a gentleman in China that took a asp classic open source compiler and modified it to work on vb6 projects. He claims he can take any vb6 project and convert it to c++ and then compile to binary with no changes. He is going to send me some info I will keep everyone updated.

For me to start the kick starter project I will need to pick the best possible solution, don't think giving three options as I did at the start of this thread will work. I admit the lawsuit idea is childish and I retrackt that statement.

Looks like something will happen, as more and more option come to the surface I will need to evaluate the success potential of each one and go for the one with the best chance of success, an as of now I still think Olaf's option is the best, but time will tell.

Had to type this on an android tablet, dear lord what a pain....

If I'm not mistaken - I believe you said in another post that your app was all UI. If that's the case why is a port to VB.Net so difficult?

What controls are you using on the form that are not found in .Net - or not close enough in functionality?

That might be a tall order if his UI consist of several dozen to near a hundred Forms(eg. Word or Excel). If its only a couple of Forms(eg. Virtual DJ) with a bunch of controls then I agree and don't see what the problem is.

Quote:

---

Originally Posted by szlamany

If I'm not mistaken - I believe you said in another post that your app was all UI. If that's the case why is a port to VB.Net so difficult?

What controls are you using on the form that are not found in .Net - or not close enough in functionality?

---

Not so much controls, but the speed of native and the code obfuscation.

Also, JIT, a button may be pressed from a hardware device, then has to display and trigger hundreds of different functions, and do it several times a second. I have not tried it, but don't think it's feasible.

Lets just say NONE of my competitors are using .net, they are all native32, and some of them are multi million $ companies.

Hope that makes sense.

Quote:

---

Originally Posted by axisdj

Not so much controls, but the speed of native and the code obfuscation.

Also, JIT, a button may be pressed from a hardware device, then has to display and trigger hundreds of different functions, and do it several times a second. I have not tried it, but don't think it's feasible.

---

LOL...even an interpreted language like JavaScript can execute several thousand functions a second. Hell, even scripting languages in games can go that fast.

Look at Demon Arena, it features a 2D engine I wrote for fun. It can comfortably animate several hundred entities at the same time. I stress tested it with 5000 creature entities and it still runs smoothy. It'll drive you nuts if I told you the amount of things the engine has to do on every creature every several milliseconds, the bounds checking, angle calculations, direction checks not to mention that some of the creatures have complex definitions that are like small programs themselves, which define their behavior, a thing even I had doubts when I first wrote it but the damn thing still works like a breeze. The only thing that can slow it down is the collision detection system and that has nothing to do with the language. Its just a very poor implementation not even real game programmers would dare to use. Frankly speaking, your implication that the .Net runtime may not be feasible for your app is utter nonsense.

Quote:

---

Originally Posted by axisdj

Lets just say NONE of my competitors are using .net, they are all native32, and some of them are multi million $ companies.

---

Didn't you say in your other thread that you're using a DLL ? The DLL would be native code. You know that you can still call it from VB.Net/C# right ?

Even if you're talking to the hardware from VB6 you do know that ultimately all the heavy lifting will be done by the Windows kernel right ? You talk to the hardware through user space APIs which are usually little more than wrappers around kernel functions. Its a form of isolation which keeps user space apps from interfering too deeply with the Windows kernel.

The point is you don't have that much control over performance other than how much and how often you send data to your devices and since all programming languages can execute function calls at phenomenal speed then it means you can control your devices with phenomenal speed.

Quote:

---

Originally Posted by axisdj

Hope that makes sense.

---

Not really. Sorry man :(

I'm beginning to get the feeling that someone has seriously mislead you axisdj. While I'm not questioning your ability to create quality apps for your clients, its becoming clear to me that you really don't have even a basic understanding of how Windows works. You don't need this knowledge to write applications but if you're going to be talking about JITs, compilers, runtimes and such you really should start learning a little bit about what goes on when you execute an app in Windows. I don't know everything about this but I have a firm general understanding and I'm telling you, nothing you said in your last post made a lick of sense. It was like reading a cave man's explanation of why a combustion engine isn't working properly.

I am going to kind of agree with his last post. I did a lot of "control" creation at runtime in VB6 - always found it to be smooth and painless.

VB.Net's controls do not scale like VB6 from my experience. Really nice things like FlowPanels or FlowLayouts - whatever they are called - can't handle lots of changes during runtime, for example. GRID speeds are terrible.

That's one of the driving reasons I left for the browser world and jQuery - the browser/JavaScript/HTML is made for UI - and really has a tight control and speed is what all these browser engines compete over.

My next DESKTOP UI will be written in a much lower level language then .Net - whatever it takes to make a WINFORM looking APP without using MS .Net libraries.

Has anyone ever used TOAD (oracle developer tool)? I wonder what that is written in...

TOAD, the Oracle tool from Quest/Dell was written in Delphi.

They say there here too: TOAD Setup and Configuration

Quote:

---

Originally Posted by Niya

LOL...even an interpreted language like JavaScript can execute several thousand functions a second. Hell, even scripting languages in games can go that fast.

Look at Demon Arena, it features a 2D engine I wrote for fun. It can comfortably animate several hundred entities at the same time. I stress tested it with 5000 creature entities and it still runs smoothy. It'll drive you nuts if I told you the amount of things the engine has to do on every creature every several milliseconds, the bounds checking, angle calculations, direction checks not to mention that some of the creatures have complex definitions that are like small programs themselves, which define their behavior, a thing even I had doubts when I first wrote it but the damn thing still works like a breeze. The only thing that can slow it down is the collision detection system and that has nothing to do with the language. Its just a very poor implementation not even real game programmers would dare to use. Frankly speaking, your implication that the .Net runtime may not be feasible for your app is utter nonsense.



Didn't you say in your other thread that you're using a DLL ? The DLL would be native code. You know that you can still call it from VB.Net/C# right ?

Even if you're talking to the hardware from VB6 you do know that ultimately all the heavy lifting will be done by the Windows kernel right ? You talk to the hardware through user space APIs which are usually little more than wrappers around kernel functions. Its a form of isolation which keeps user space apps from interfering too deeply with the Windows kernel.

The point is you don't have that much control over performance other than how much and how often you send data to your devices and since all programming languages can execute function calls at phenomenal speed then it means you can control your devices with phenomenal speed.



Not really. Sorry man :(

---

Ok. Again if .net is so wonderful why are none of my competitors using it? They are mostly using QT win32?

Anyway i know how you feel about us vb6 types.

Wp

Quote:

---

Originally Posted by szlamany

I am going to kind of agree with his last post. I did a lot of "control" creation at runtime in VB6 - always found it to be smooth and painless.

VB.Net's controls do not scale like VB6 from my experience. Really nice things like FlowPanels or FlowLayouts - whatever they are called - can't handle lots of changes during runtime, for example. GRID speeds are terrible.

That's one of the driving reasons I left for the browser world and jQuery - the browser/JavaScript/HTML is made for UI - and really has a tight control and speed is what all these browser engines compete over.

My next DESKTOP UI will be written in a much lower level language then .Net - whatever it takes to make a WINFORM looking APP without using MS .Net libraries.

Has anyone ever used TOAD (oracle developer tool)? I wonder what that is written in...

---

Well controls in VB6 are lighter than those in the .Net Framework. VB6(actually ActiveX) even had windowless controls which were even lighter than a typical control. The LayoutPanel controls do have a lot of quirks and work quite terribly when you try to do fancy things with them. I have mixed feelings about the DataGridView though. I use it all the time and don't experience performance problems unless I try to populate it with too much data but I believe that's why it has a virtual mode, which allows a lot more flexibility with how you populate the grid with data. In general though, I don't get problems with UIs in VB.Net apps but I know what you're talking about.

When building very complicated UIs, VB6 does seem to have an edge in performance. I've faced this and realized I had to change a couple old habits. For example, UIs that morph like checking a box which reveals extra options. In VB6, I would have done something like this by hiding(Visible=False) a GroupBox or UserControl and showing it when the option was checked. VB6 handled this quite nicely but you're going to have problems if you do this excessively in VB.Net. I had to change this habit. I no long hide controls, I just instantiate them now. Its much cleaner that way anyway. Another thing is that GDI+ can be a little sluggish when compared to GDI which is what you would have used for user drawn controls in VB6. In general its not a problem but controls that have to perform too many graphical operations per paint is going to perform worse than its VB6/GDI counterpart. I've found that a little optimization here and there can boost their performance. You can't go hog wild like you could in VB6, you have to pay a little more attention to how you're drawing your controls now. Another solution is to use XNA which seems to work quite well for Shaggy.

Yea so I agree that VB.Net isn't close to being the best for creating snappy UIs and I agree with your move to Web UI interfaces. I've always held that HTML/XAML and similar tech is unbeatable for creating nice UIs.

Anyways, axisdj's last post wasn't about controls. He seemed to be saying that he isn't sure that the .Net runtime can execute hundreds of function calls per second which of course is ridiculous.

Quote:

---

Originally Posted by axisdj

Ok. Again if .net is so wonderful why are none of my competitors using it? They are mostly using QT win32?

---

Why are you asking me? You really expect me to know the answer to that ?

Quote:

---

Originally Posted by axisdj

Anyway i know how you feel about us vb6 types.

---

Really ? How do I feel about "vb6 types" whatever that is.

[EDIT]

Also take note of szlamany's attitude. Notice that VB.Net fell short for him in a certain regard and instead of populating the forums with these ridiculous bring back VB6 threads, he opted to use another tech that met his requirements. That is how a professional does things. They don't cry and moan, they act.

Quote:

---

Originally Posted by Niya

Why are you asking me? You really expect me to know the answer to that ?



Really ? How do I feel about "vb6 types" whatever that is.

[EDIT]

Also take note of szlamany's attitude. Notice that VB.Net fell short for him in a certain regard and instead of populating the forums with these ridiculous bring back VB6 threads, he opted to use another tech that met his requirements. That is how a professional does things. They don't cry and moan, they act.

---

I actually have a very control heavy app, What i thought jit means and the reason i dont like it is, if i press a button for the first time, it compiles, and that delays the intended action, which is not acceptable. Im sure there is a work around though?
Maybe press all buttons on start up, but that slows start up...

Also code security is very important to me, and from what i have seen it is much easier to de-compile a .net app even if it is obfuscated, rather than a native app.

Sorry , i can understand your frustration with me.

I will try to limit post on this forum.

Quote:

---

Originally Posted by axisdj

I actually have a very control heavy app, What i thought jit means and the reason i dont like it is, if i press a button for the first time, it compiles, and that delays the intended action, which is not acceptable.

---

Yes, every method is only compiled when its first called but have you tested it to see just how much of a hit you took ? As a matter of fact, lets find out. I'm going to knock together an app just to test this very thing and you can be the judge of the results.

Quote:

---

Originally Posted by axisdj

Also code security is very important to me, and from what i have seen it is much easier to de-compile a .net app even if it is obfuscated, rather than a native app.

---

No argument there. Its actually one of my only few gripes with MSIL bytecode.

Quote:

---

Originally Posted by axisdj

Sorry , i can understand your frustration with me.

---

My frustration is with you mouthing off untrue things. Attitudes like yours might very well discourage people from trying out VB.Net or C# which is a disservice. Being that I have used both VB6 and VB.Net I can speak with authority that VB.Net is nowhere near as bad as you guys make it out to be nor is it inferior to VB6, far from it. Someone reading your words might be persuaded by them. This is why I took as long to move away from VB6 as I did, it was because of reading words like yours and I could have benefited if someone had told me the truth which is why I'm so adamant about my views on this topic. I hate that I allowed myself to be swayed by the unwarranted prejudice of fools.

Quote:

---

Originally Posted by axisdj

I will try to limit post on this forum.

---

I have no desire to silence you despite what you say. Fatina and Carlos Rocha, maybe...those two are just ridiculous but you're a lot more reasonable then they are.

Quote:

---

Originally Posted by Niya

Anyways, axisdj's last post wasn't about controls. He seemed to be saying that he isn't sure that the .Net runtime can execute hundreds of function calls per second which of course is ridiculous.

---

Actually from what I am hearing him say it is all about controls.

In VB6 if you had a hundred sensors and feeders for lights you would setup a control for each one. That's just not the .Net way to do things - those "elements" should have a GUI reference for DISPLAY and a single PATH for control - that can be shared among all "elements".

Regardless- check out this link. The GC is your worse enemy - not JIT...

http://stackoverflow.com/questions/8...et-application

Also - check out this - it might mean you can JIT once in advance

http://msdn.microsoft.com/en-us/magazine/cc163610.aspx

Quote:

---

Originally Posted by dilettante

TOAD, the Oracle tool from Quest/Dell was written in Delphi.

They say there here too: TOAD Setup and Configuration

---

Interesting - I've used TOAD a lot and saw it look WinForm like and also felt that it was not a MS native app. I've also noticed that Sony Vegas is kind of like that (although they use MS SQL Express for storing all your "edit" points and video libraries).

Maybe Microsoft SHOULD put all that VB6 stuff they included in the 2002 version of Visual Studios back in the next version of Visual Studios just to appease the VB6 crowd. :rolleyes:

Quote:

---

Originally Posted by axisdj

Ok. Again if .net is so wonderful why are none of my competitors using it? They are mostly using QT win32?

Anyway i know how you feel about us vb6 types.

Wp

---

You could just as easily ask: If VB6 is so wonderful, why are none of your competitors using it? Since you feel that VB6 is clearly adequate, then all of your competitors must be wrong. If they are wrong about VB6, why couldn't they be wrong about other things?

Quote:

---

Originally Posted by szlamany

In VB6 if you had a hundred sensors and feeders for lights you would setup a control for each one. That's just not the .Net way to do things - those "elements" should have a GUI reference for DISPLAY and a single PATH for control - that can be shared among all "elements".

---

I re-read this like 20 times and I'm still not sure what you're trying to say here lol

Quote:

---

Originally Posted by Shaggy Hiker

You could just as easily ask: If VB6 is so wonderful, why are none of your competitors using it? Since you feel that VB6 is clearly adequate, then all of your competitors must be wrong. If they are wrong about VB6, why couldn't they be wrong about other things?

---

I was wondering this myself.

Quote:

---

Originally Posted by szlamany

The GC is your worse enemy - not JIT...

---

You know I've always wondered about this. There are tonnes of articles and forum posts on the internet that talk about the GC kicking in at bad times thereby causing jitter yet, I've not encountered any situation in my own development where this has happened. I eventually made an app to brute force it and after allocating an unrealistic amount of objects I did notice a slight jitter when I called GC.Collect. I concluded that in a typical app GC is not really an issue.

That being said, if your app needs to be able to respond in real time then it really shouldn't be executing in a managed environment so it makes some sense why axisdj is upset about MS abandoning VB6 which produced native code without the effects of the GC and JIT compilation. However, this doesn't make his position any more valid as its kinda like asking MS to continue VB6 just for the sake of people who are writing time sensitive code. People wrote all manner of apps in VB6, many of which VB.Net can also be used to author. Why should all those people be denied a better tool to please a small niche of developers who are doing things they probably shouldn't even be doing in the first place.

Quote:

---

Originally Posted by Niya

I re-read this like 20 times and I'm still not sure what you're trying to say here lol

---

I was suggesting that the "display" of controls should be lightweight (knowing of the .Net control bloat) and then morph the same "action and event" logic over each "display" element. That way JIT compile of event functions is no longer relevant.

Ah. I understand now.

I won't speculate about the impact of the JIT in this scenario since I've no experience with real-time necessities that comes with interacting with certain types of hardware. In my own experience playing around with hardware, latency was never really and issue. Nonetheless, in the past when I needed high level performance, I've always resorted to C++ but these scenarios weren't hardware related. Mostly string and image processing. VB6 as thin as it was still had way too many abstractions that hindered performance of certain types of algorithms.

I totally agree with those statements...

Quote:

---

Originally Posted by Shaggy Hiker

You could just as easily ask: If VB6 is so wonderful, why are none of your competitors using it? Since you feel that VB6 is clearly adequate, then all of your competitors must be wrong. If they are wrong about VB6, why couldn't they be wrong about other things?

---

Many of them did start with vb6, but have now moved to QT or Visual C++.

I think the main reason is that they are MUCH larger companies with many programmers and larger budgets. I feel I kind of cheated by using vb6, but in the end my vb6 code still compiles to native exe, in a very similar way that vc++ project does(I know there is a runtime needed... but so does c++). That is what makes vb6 so great, it saves time of development, gives you the power you need to compete with vc++ generated apps, with same code security as vc++ and in my opinion very close to the same performance.

The only reason I am so passionate about vb6, is that my codebase took years to mature to what it is today, and I just can't sit by, rewrite the whole thing and end up with un-secured source, with possibly slower performance.

I am sorry it bothers some of you that I am so persistent about this, but I have never failed at a goal I have set, and my goal is to organize some way to use my existing code and have it be compiled by something else. I love challenges and this is a big one. It will happen, sooner or later. People have told me all my life that can't be done.. or that does not make sense.. and I always accomplish the goal I set out to do.

I will continue to formulate a crowd-funding solution. I have several possible options right now, and waiting on more details for all those options. I will soon create a forum for this new project. It will be a central meeting place to find out about what the options are and how to move forward to the ultimate goal of a vb6 replacement.

Peace

Quote:

---

Originally Posted by axisdj

I will continue to formulate a crowd-funding solution. I have several possible options right now, and waiting on more details for all those options. I will soon create a forum for this new project. It will be a central meeting place to find out about what the options are and how to move forward to the ultimate goal of a vb6 replacement.

Peace

---

Good luck mate :thumb:

I wish you success in this endeavor.:cool:

I disagree with the whole code security aspect, but I've already stated my objections to that view and don't see any point in doing so again. VB6 and VB.NET are both great languages when it comes to putting out working programs in short order, which is why I have used both for writing apps over the last (nearly) two decades. I suspect that the reason your competitors went with C++ over VB has very little to do with the quality of C++ and more to do with a persistent view of VB as a toy language, especially among C++ developers. That's their loss. The point is that you can't use your competitors choices as some indication that .NET isn't viable, because they also rejected a language that you know, first hand, IS viable. Therefore, their actions are no indication of wisdom.

I can understand why you would want to stick with a code base that took years to develop. I'd like to believe that what I write today will be viable in a decade. Perhaps it will be. However, others suggest that the desktop itself, and possibly MS, won't be around in a decades, and they may be right. We simply can't count on the world remaining static. I'd love to know what technology will work on the systems of today as well as the systems of tomorrow, but I don't. We had the luxury of living/working in a window of time when the OS of one company dominated a relatively homogenous hardware platform. That allowed us the luxury of targeting one system with the confidence that it would remain dominant/viable for a long time. I don't believe that time is over just yet, but plenty of other people feel that it is drawing to a close. If we really see the demise of the desktop, we will be back to a world where you may have to pick a platform, or go web-based. It's not a world I look forward to, as I'm old enough to remember when it wasn't enough to find a program that you liked, you also had to determine whether it even ran on the hardware you were using.

Developers would prefer that their programs reached the widest possible audience. That would require a homogenous platform, or great cross-platform performance. Since the latter has been promised since the early 90's, and has never really been realized, and the former seems to be fading away, we may not get what we'd like.

At least we get to eat steak...

Oh - that's the other thread :)