Alternatives
in [Visual Basic]
|
From: Tom Shelton on 13 Jan 2009 15:19 On 2009-01-13, mayayana <mayaXXyana(a)rcXXn.com> wrote: >> > Hmm. Quickly? >> > One wonders what the framework is for >> >> You see I said for advanced stuff right? No framework can be all things > to >> all people. > > It's just that you tend to be a bit fast and loose in > the context of your arguments. I said VB.Net might be > good because the person wouldn't need to understand > Windows. To which you reply that of course they would > because the framework is limited. Apparently that's meant > as testament to the intelligence and experience of .Net > people -- that they tend to have a solid background in > Windows programming -- but it's hardly a selling point for > a tool with an 88 MB dependency! > > At the same time you're saying that .Net is cross-platform > with Moonlight. But if the framework is so limited that doesn't > say much for cross-platform applications. > >> > -- that 88 MB of bloat that .Net software wants >> > to dump onto a system -- if it "quickly" becomes >> > inadequate. (But I already know the DotNettiac >> > answer to that: "These days 88 MB is nothing. And >> > hard disks are cheaper than ever!" ) >> >> Well, on most modern machines that is exactly true - especially as you add >> more applications because that disk cost is then amoratized over the > number of >> applications using it. Beyond that, you apparently haven't heard of this: >> >> http://windowsclient.net/wpf/wpf35/wpf-intro-client-profile.aspx >> -- > > Let me see if I've got this straight. The v. 2 > framework dumps 88 MB of bloat, the v. 3+ > framework dumps hundreds of MB of bloat. > But now there's a big, exciting breakthrough: > > A limited version of the 3+ framework can be > installed that's only slightly more bloated than > the v. 2 mess! > > (The v. 2 download is something like 24 MB and > turns into 88 MB. The v. 3+ mini-mess "client profile" > package is about 28 MB according to your link. So > I'm guessing that dumps over 100 MB.) > > And that's progress? You're incorrigible. :) > > And by the logic you used above I'd be losing out if > I install the smaller package. By not dumping more > functionality onto my new hard disk I'd be actually > increasing the cost of it... at least if one believes in > "amortizing" disk costs. I guess you're right about the > superior intelligence of DotNettiacs. I'm getting dizzy. :) > > -- Tom Shelton
From: Henning on 13 Jan 2009 16:16 "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> skrev i meddelandet news:ewAlRrbdJHA.4052(a)TK2MSFTNGP06.phx.gbl... > On 2009-01-13, Mike Williams <gagamomo(a)RumAndCoke.com> wrote: >> "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message >> news:%23iBJyjadJHA.4492(a)TK2MSFTNGP03.phx.gbl... >> >> >>> C# and VB.NET programs run on Linux as well. >> >> So does RealBasic. >> > > Yes it does. I have a copy of it. Kind of sucks actually. Sorry. > > -- > Tom Shelton Agree, never thougth someone would destroy the Basic language like that! Declaring variables and constants is a disaster. /Henning
From: Schmidt on 13 Jan 2009 16:21 "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> schrieb im Newsbeitrag news:eDSO8qbdJHA.4052(a)TK2MSFTNGP06.phx.gbl... > >> Ewww... If your going to suggest a scripting language, > >> how 'bout something a little more modern and cross > >> platform - such as Python. It can do all of that, > >> and more. > > Yep, that's a nice suggestion, although the syntax is - > > well ... not VB-compatible <g>. > > > Nope. It's not - but neither is delphi. Yep, I wrote this only in the context you opened up with: > >> Ewww... If your going to suggest a scripting language... > >> But, can't take advantage of 64-bit multicore processors. > > VB6 can take advantage of multicore-processors of course > > - possible with pretty simple ActiveX-Exe-Threading. > That is true. But, there are limitations in VB.CLASSIC's > threading. It is not free-threaded, and there for hacks are > required to transfer data accross thread boundries (TLS). No, absolutely not - that's one of the nice things with AX-Exe-Threading - the transfer of data across TLS- boundaries works entirely transparent - over the same COM-Interfaces which you would use singlethreaded - and this even fully synchronized - without forcing you to write the synchronization-code yourself. > > And regarding the 64Bit - as long as your selfwritten > > VB-Apps don't need more than 3GByte RAM for > > themselfes - they should work without problems > > not only on 64Bit-Processors which "drive" a 32Bit- > > OS (which nowadays is often the default yet), but also > > on 64Bit-processors which drive a 64Bit-OS (over > > the appropriate 64-32Bit-layers, which of course also > > allow 32Bit-threading from within 32Bit-processes, > > so the use of "64Bit-MultiCores" is no problem). > > > Yes - but, many enterprise applicaitons need the extra > memory space. What do you have in mind there? A Fat Client-App which needs 3GByte of Ram??? Or more the Server-Applications as e.g. MS-SQLServer? There I have acces to over Pipes or Sockets from my 32Bit-App. > >> VB.CLASSIC has an increasingly limited lifespan... > >> At least in the enterprise. > > Maybe in the real large ones - in the many smaller firms > > I see a much longer lifespan for the typical "VB6-branch- > > solutions". > > > I see no reason that would be the case. Can you elaborate here? I know many "VB6-Shops" (inlcuding my own one), which yet deliver their branch Applications as VB6-Binaries (consisting of 100,000's of lines of code, so the porting is either yet in progress due to limited man-power (to whatever the new language/environment may be) - or it has not even started (as in my case, and I can imagine, that there are many more "shops like me", who simply "got the nerves", to not move too early - even if a migration to ..NET is planned by some shops, it is/was a good decision to wait - just look at all the new "incompatible stuff" in .NET as e.g. WPF or WCF - those who got the nerves could now directly move to the new, recommended way of coding in .NET). > Of course you wouldn't from a 32-bit app. That's the point, > you can create 64-bit apps in vb.net. These Apps don't deliver larger performance (there were many tests, which have shown 32Bit Apps often a little bit faster on the 64Bit->32Bit-layer than similar coded 64Bit-Apps, which were "natively" executed - only in some tests, which performed longer loops on 64Bit-Integers there were larger improvements). So the whole 64Bit-topic boils down to the larger available Memory-Range, which is currently more important for server-apps than for Desktop- Apps. > I am well aware of the use of strptr and typelibs. > But, those are hacks to work around the limitations in the > VB.CLASSIC marshaling behavior. No these are no hacks, these are simple calling-conventions. And the OLE-marshaling never had a single problem with BSTR-Passing - here's simply no implicite ANSI-conversion necessary (between two communicating COM-components). > My point, is that situation is now been rectivied, and the > .NET marshaller does the right thing - passes Unicode to > W api's and Ansi to A api's. The same is possible with VB6, if you have a Typelib for the W-Function and API-Declares for the A-Functions, then you can call either function-type in a transparent way (without StrPtr-enclosures for your strings). > >> 2. Direct support for calling functions that use Unions > > IIRC this should also be doable with appropriate > > TypeLib-Defines. > > Another alternative, an a common one is to use byte arrays. > But, again, both of these options are work arounds for limitations > in the marshalling behavior of VB.CLASSIC. These scenarios > are directly supported in .NET. Yep - but how often are you stumbeling over a Union-related problem in VB6 whilst using WinAPIs - I'm using the WinAPI in a broad range in the meantime and the cases are very rare, where you have to switch into "ByteArray-Mode" because of either Alignment-Problems or Unions. [__cdecl] > Recompiling is not always a possiblity. Usually, this > involves building a wrapper in C++ - though, as I recall > Matt Curland had a hack that could make this possilbe. Yep, not only the Curland-hack is available, as said - the new "Thunking-approaches" on e.g. PSC allow that too. > >> 4. Support for overloading function calls. > > Yep - that's nice - but Optional Params do well for me > > so far. > > VB.NET has optional params as well ;) In the meantime, yes - that's a nice feature - and also the Variant-Type is back again as it seems. VB.NET slowly comes to the point where VB6 already is, but it makes some progress as it seems ...<g> > >> And what about subclassing a win proc? > >> In .NET it's safe and supported in the IDE. > > IIRC on PSC there are tools, which support IDE-safe > > subclassing for VB6 in the meantime - if encapsulated in > > a little AX-Dll, then their usage should be even more easy. > Again, workarounds for behavior already included in > VS and .NET. Calling libraries should be "allowed" in both languages, I don't see any "workarounds" here - the only difference is, that in .NET the huge library is a "must-dependency" - where in VB6 I have the choice, which lib(s) I use and include in my deployment. > >> Especially when it comes to more advanced techniques as > >> multi-threading, etc. > > Oh c'mon Tom - not again these threading-topics - thought > > we had already discussed this - e.g. P. Clement has not shown > > until now a .NET-example which does the same as this VB6-one. > > www.datenhaus.de/Downloads/MandelbrotThreaded.zip > > > > I'll look at it. But, I can't promise anything. If it's graphics, > I'm not that good at that :) The "Mandelbrot-Loop" is only a few lines of code - and the prebuilt Color-Lookup-Table is also not that difficult to reimplement - the rest is Threading-stuff. > And, if I do do something with it, I can promise you it > won't be in VB.NET - but C#. Ok, if I paste that into SharpDevelop I can switch that to VB.NET-view in case I have problems with your C#-code <g>. Olaf
From: Tom Shelton on 13 Jan 2009 17:01 On 2009-01-13, Schmidt <sss(a)online.de> wrote: > > "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> schrieb im Newsbeitrag > news:eDSO8qbdJHA.4052(a)TK2MSFTNGP06.phx.gbl... > >> >> Ewww... If your going to suggest a scripting language, >> >> how 'bout something a little more modern and cross >> >> platform - such as Python. It can do all of that, >> >> and more. >> > Yep, that's a nice suggestion, although the syntax is - >> > well ... not VB-compatible <g>. >> > >> Nope. It's not - but neither is delphi. > Yep, I wrote this only in the context you opened up with: >> >> Ewww... If your going to suggest a scripting language... > >> >> But, can't take advantage of 64-bit multicore processors. >> > VB6 can take advantage of multicore-processors of course >> > - possible with pretty simple ActiveX-Exe-Threading. > >> That is true. But, there are limitations in VB.CLASSIC's >> threading. It is not free-threaded, and there for hacks are >> required to transfer data accross thread boundries (TLS). > No, absolutely not - that's one of the nice things with > AX-Exe-Threading - the transfer of data across TLS- > boundaries works entirely transparent - over the same > COM-Interfaces which you would use singlethreaded - > and this even fully synchronized - without forcing you > to write the synchronization-code yourself. > Sure - unless your tyring to share the data. Try it out. A change to a value in one thread, is not reflected in another thread. Each thread gets their own copy of any data TLS is nice, if your threads do not need to interact - but, becomes a hinderance when they need to share resources. >> > And regarding the 64Bit - as long as your selfwritten >> > VB-Apps don't need more than 3GByte RAM for >> > themselfes - they should work without problems >> > not only on 64Bit-Processors which "drive" a 32Bit- >> > OS (which nowadays is often the default yet), but also >> > on 64Bit-processors which drive a 64Bit-OS (over >> > the appropriate 64-32Bit-layers, which of course also >> > allow 32Bit-threading from within 32Bit-processes, >> > so the use of "64Bit-MultiCores" is no problem). >> > >> Yes - but, many enterprise applicaitons need the extra >> memory space. > What do you have in mind there? > A Fat Client-App which needs 3GByte of Ram??? > Need is probably the wrong word here :) But, any process that needs to work with a large amount of data can benifit from the larger address space. > Or more the Server-Applications as e.g. MS-SQLServer? > There I have acces to over Pipes or Sockets from my > 32Bit-App. > > >> >> VB.CLASSIC has an increasingly limited lifespan... >> >> At least in the enterprise. >> > Maybe in the real large ones - in the many smaller firms >> > I see a much longer lifespan for the typical "VB6-branch- >> > solutions". >> > >> I see no reason that would be the case. Can you elaborate here? > I know many "VB6-Shops" (inlcuding my own one), which yet > deliver their branch Applications as VB6-Binaries (consisting of > 100,000's of lines of code, so the porting is either yet in progress > due to limited man-power (to whatever the new language/environment > may be) - or it has not even started (as in my case, and I can > imagine, that there are many more "shops like me", who simply > "got the nerves", to not move too early - even if a migration to > .NET is planned by some shops, it is/was a good decision to wait - > just look at all the new "incompatible stuff" in .NET as e.g. > WPF or WCF - those who got the nerves could now directly > move to the new, recommended way of coding in .NET). > New things are always being added. When is it going to be the right time? But, if you did wait - this is a good time :) WPF is a really nice technology. >> Of course you wouldn't from a 32-bit app. That's the point, >> you can create 64-bit apps in vb.net. > These Apps don't deliver larger performance (there were > many tests, which have shown 32Bit Apps often a little > bit faster on the 64Bit->32Bit-layer than similar coded > 64Bit-Apps, which were "natively" executed - only in some > tests, which performed longer loops on 64Bit-Integers there > were larger improvements). So the whole 64Bit-topic boils > down to the larger available Memory-Range, which is > currently more important for server-apps than for Desktop- > Apps. > I agree. Server apps are much more likely to make use of the memory space. >> I am well aware of the use of strptr and typelibs. >> But, those are hacks to work around the limitations in the >> VB.CLASSIC marshaling behavior. > No these are no hacks, these are simple calling-conventions. > And the OLE-marshaling never had a single problem with > BSTR-Passing - here's simply no implicite ANSI-conversion > necessary (between two communicating COM-components). > But I wasn't talkign about COM componets. We were specifically talking about calls to native api's. And they are hacks - for many years, StrPtr wasn't even a documented function... And to use a typelib, you either have to find one that already exists or dive into learning IDL. >> My point, is that situation is now been rectivied, and the >> .NET marshaller does the right thing - passes Unicode to >> W api's and Ansi to A api's. > The same is possible with VB6, if you have a Typelib for > the W-Function and API-Declares for the A-Functions, > then you can call either function-type in a transparent way > (without StrPtr-enclosures for your strings). > Yes - if your willing to step outside of VB and learn to use IDL. >> >> 2. Direct support for calling functions that use Unions >> > IIRC this should also be doable with appropriate >> > TypeLib-Defines. >> >> Another alternative, an a common one is to use byte arrays. >> But, again, both of these options are work arounds for limitations >> in the marshalling behavior of VB.CLASSIC. These scenarios >> are directly supported in .NET. > Yep - but how often are you stumbeling over a Union-related > problem in VB6 whilst using WinAPIs - I'm using the WinAPI > in a broad range in the meantime and the cases are very rare, > where you have to switch into "ByteArray-Mode" because of > either Alignment-Problems or Unions. > Hmmm... How 'bout the console api? > [__cdecl] >> Recompiling is not always a possiblity. Usually, this >> involves building a wrapper in C++ - though, as I recall >> Matt Curland had a hack that could make this possilbe. > Yep, not only the Curland-hack is available, as said - the > new "Thunking-approaches" on e.g. PSC allow that too. > >> >> 4. Support for overloading function calls. >> > Yep - that's nice - but Optional Params do well for me >> > so far. >> >> VB.NET has optional params as well ;) > In the meantime, yes - that's a nice feature - and > also the Variant-Type is back again as it seems. No it's not. I assume your talking about type inference - this is NOTHING like Variant. And it can be turned off. Dim i = 1 Is going to make i an Integer value - it is NOT a Variant. If you were to do this: Dim i = 1 i = "Hello, World!" You would get a big fat compiler error. > VB.NET slowly comes to the point where VB6 already is, > but it makes some progress as it seems ...<g> > Not really. >> >> And what about subclassing a win proc? >> >> In .NET it's safe and supported in the IDE. >> > IIRC on PSC there are tools, which support IDE-safe >> > subclassing for VB6 in the meantime - if encapsulated in >> > a little AX-Dll, then their usage should be even more easy. > >> Again, workarounds for behavior already included in >> VS and .NET. > Calling libraries should be "allowed" in both languages, It is. > I don't see any "workarounds" here - the only difference Really. Hmmm... 3rd party tools created specifically to overcome limitations in the language and ide are not work arounds. > is, that in .NET the huge library is a "must-dependency" - > where in VB6 I have the choice, which lib(s) I use and > include in my deployment. The VB6 runtime is a must dependency as well... It just happens to be included on pretty much every machine :) This is starting to be the case with the .NET framework - it is a part of Vista and new machines. Window 7 has it - since it includes Windows Powershell. But, I will give you this point. VB6 can have a significantly smaller distibution foot print... Still, I find that the productivity gains far outweigh this one minor issue :) > >> >> Especially when it comes to more advanced techniques as >> >> multi-threading, etc. >> > Oh c'mon Tom - not again these threading-topics - thought >> > we had already discussed this - e.g. P. Clement has not shown >> > until now a .NET-example which does the same as this VB6-one. >> > www.datenhaus.de/Downloads/MandelbrotThreaded.zip >> > >> >> I'll look at it. But, I can't promise anything. If it's graphics, >> I'm not that good at that :) > The "Mandelbrot-Loop" is only a few lines of code - and > the prebuilt Color-Lookup-Table is also not that difficult > to reimplement - the rest is Threading-stuff. > I've started to look at it - so far, doesn't look all that difficult a conversion... >> And, if I do do something with it, I can promise you it >> won't be in VB.NET - but C#. > Ok, if I paste that into SharpDevelop I can switch that > to VB.NET-view in case I have problems with your > C#-code <g>. I would do it in VB.NET - but, I just don't do much work in that anymore. I'm afraid, I wouldn't be a good representitive of the language :) -- Tom Shelton
From: expvb on 13 Jan 2009 17:35
"Bee" <Bee(a)discussions.microsoft.com> wrote in message news:5F4A713D-F6B7-4FB3-AD26-9A1BB4A23DAF(a)microsoft.com... > Me - diehard VB6 user. > My friends - wanting to learn to program apps for Windows. It depends on your long term planning. Is this for a job/career, or hobby/shareware development? If it's for a job, then the market dictates. This is between MS DotNet and Borland products mostly. Most jobs now request more DotNet than VB6. DotNet seems to target businesses, like those who develop custom software for businesses. For them DotNet is the perfect tool. Keep in mind that MS has acquired several ERP/Accounting software in recent years totaling millions of end users. Some of which has VBA or VBA like language to expand the software and customize it to fit the end user need. So DotNet developers who develop ERP software will find themselves competing against Microsoft and their marketing strategies, or work for specific customers to customize MS Products using VBA.Net or similar for them. Here is the list of MS ERP/Accounting software: http://www.microsoft.com/dynamics/product/productoverviews.mspx ERP: http://en.wikipedia.org/wiki/Enterprise_resource_planning If your intention is to use the language for hobby/shareware development, then you can choose what you want. However, it's difficult to convert code from one language to another, but there are commercial converter tools out there. There are practically no free decent ones. DotNet 2005/2008 Express editions are free, including for commercial use, but there are limitations that limit shareware sales. Here is a summary of why I see DotNet as not suitable for shareware(There are some exceptions depending on the software and the target user): - 2005 Editions compiled code do not run on Windows 95(Windows 9x/NT4 for the 2008 Editions), and use more resources than an equivalent VB6 program. - Require Windows 2000 to install VB2005, and XP for VB2008. This is for the development computer only. - Run time size is 25 MB+, which takes a long time to download with dialup. It comes with some operating systems and service packs. - Each new edition obsoletes an older DotNet Library. For example, VB.Net 2008 can only target .Net Labara 2.0 or after, forcing some users to update the runtime. - Compiles to EXE in an op-code like language, making it easy to decompile. You can use an Obfuscator, but the good ones are not free, even expensive. See these articles: http://en.wikipedia.org/wiki/Common_Language_Runtime http://en.wikipedia.org/wiki/Visual_Basic_.NET#Criticism > So what about > RealBasic > Delphi > PowerBasic Two of these products are not free(RealBasic and PowerBasic). Older Delphi 2006 and Turbo C++ 2006 from Borland are available for free, including commercial use. They have limitations, but I am not sure what they are. See their FAQ. http://www.codegear.com/downloads Click on "C++Builder" or "Delphi" and look for "free download". They have a DotNet and non-DotNet editions, avoid the DotNet editions. Also, there is FreeBasic. It's open source in the beta stage and the compiler is written in FreeBasic itself. It's unfortunately not compatible with VB6 code, but it has more features like pointers, multithreading, inline assembly, function overloading, unions, plus many others that you would find in C++, VB.Net, or Delphi. It has string indexing feature, for instance. In VB6, if you want to refer to a character from a String variable, you have to use Mid function or statement. In FreeBasic, you can use sFullName[5]. VB.Net supports this by using String.IndexOf() Method, but this may add method calling overhead, which makes it slow. http://en.wikipedia.org/wiki/FreeBASIC http://www.freebasic.net http://www.freebasic.net/index.php/about?section=features See the Gallery for some applications written with FreeBasic. If this language develops large user base and someone makes a conversion tool for VB6 code, then I might move to it. C++(Not C#), Delphi, FreeBasic can make binary files with minimum dependency. That is, make an EXE or DLL that depends only on DLL's that are included with the OS, such as user32.dll, and kernel32.dll. C# always use the DotNet library. Finally, this newsgroup is for VB6(VB Classic) and lower. DotNet has separate groups; all of which have either "dotnet" or "vsnet" in the name. Thank you |