Alternatives
in [Visual Basic]
|
From: Mike Williams on 13 Jan 2009 14:47 "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.
From: mayayana on 13 Jan 2009 14:59 > > 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. :)
From: Tom Shelton on 13 Jan 2009 15:08 On 2009-01-13, Schmidt <sss(a)online.de> wrote: > > "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> schrieb im Newsbeitrag > news:%23iBJyjadJHA.4492(a)TK2MSFTNGP03.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. >> > I don't think any other "RAD" tool has that ability, >> > other than VC6. > >> 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). > 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. >> 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? >> And for the record - VB.NET (actually .NET in general) >> provides even better support, and you can actually call >> 64-bit api's as well. > Why would I want to call a 64Bit-API from my 32Bit- > Application, if the 32Bit-API-pendant does the same? ;-) > Of course you wouldn't from a 32-bit app. That's the point, you can create 64-bit apps in vb.net. >> Don't believe me? I can name a number of things that >> .NET makes easier when dealing with native calls: >> >> 1. Direct support for Unicode API's. > To change a "Byval As String" to "Byval As Long" in the > API-Declaration is really not a big deal - and then there > are Typelibs for direct support of the W-Functions, without > the need to use StrPtr(SomeString) in the Call, W-APIs > in a Typelib support direct BString-Passing (avoiding > VBs indirect ANSI-Conversion-automatisms). > 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. 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. >> 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. >> 3. Direct support for both __stdcall and __cdecl calling >> conventions > Ok, here you got me - until now I've not figured out, > how to enable that in a VB-Typelib-Declaration. > But C(++)-recompiling (at least the interesting enough > OpenSource-Libs) with a StdCall-Convention > is not a big deal. > 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. Again, you miss the point. These are work arounds for the limited behavior of the VB.CLASSIC marshaller. >> 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 ;) > >> 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. >> 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 :) And, if I do do something with it, I can promise you it won't be in VB.NET - but C#. > And IIRC, you have participated in the appropriate thread > some month's ago too. I don't recall being involved in any threading discussions... I remember being involved in one involving some graphics stuff - something I'm not very proficient at... -- Tom Shelton
From: Tom Shelton on 13 Jan 2009 15:09 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
From: Schmidt on 13 Jan 2009 15:14
"mayayana" <mayaXXyana(a)rcXXn.com> schrieb im Newsbeitrag news:eYREQVbdJHA.1528(a)TK2MSFTNGP03.phx.gbl... > Thanks for that info. I guess it is about > time that I take another look at Linux. Regarding Hardware which works completely out of the box, I'd recommend a small motherboard with integrated NVidia-graphics, which is more than capable, to run all the newer 3D-Desktop-enhancements (after installing the NVidia closed-source-driver, which is well supported regarding the install-process on Sidux as well as in Ubuntu). The AMD-integrated grfx-chipsets got also better closed- source-linux-drivers in the meantime, though not (yet) that stable as the NVidia ones (on the other side, AMD has opened a bit more than NVidia over the last months regarding support for OpenSource 3D-drivers for their new grfx-chipsets, but this is currently work in progress, which should show good results in the new releases of the open radeon-hd-driver for example - but until now I'd go with NVidia). Just an example for a cheap MB, which includes also a GBit-Network-chip and a fully supported sound-chip: http://www.newegg.com/Product/Product.aspx?Item=N82E16813157148 But there are of course other vendors with similar boards - just wanted to mention a "fully compatible" graphics-chipset, which I know works with the newer 3D-enhancements without problems (all the integrated NVidia-chipsets do well - be it the 6xxx, 7xxx or the new 8xxx-series - and that with very low power-consumption). But enough of this off-topic-stuff for now. ;-) Olaf |