locked
What's next for Visual Basic ? Is Dot Net the only option? Can you compile VB to not be a .Net App?

    質問

  • 1 - Where are we with Visual Basic?

    (MS lost me when they went to .Net)

    2 - What is the latest version of VB?

    3 - Can you write an application in the current version of VB without using the .Net stuff?

    4  - And compile it so that it is not reliant on the .Net virtual machine?

    Finally, will programs developed using the original VB6 run on Windows 7? How about the upcoming Windows 8?

    Thanks for any help.


    2012年2月23日 14:15

すべての返信

  • Hi,

    This is Visual Basic 2010 that still relies on the .NET Framework. You have third party tools supposed to embed what is needed inside the EXE file (never used them) but then it's perhaps best to just choose another non .NET dependent compiler as it kind of defeat the purpose of .NET IMO...

    VB6 is supported under Windows 7. Never saw anything for Windows 8 about VB6. Try (Ah ! Good point they updated their statement for Windows 8) :  http://msdn.microsoft.com/en-us/vstudio/ms788708 (and it is supported)


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".



    2012年2月23日 14:33
  • VB 2002=version number 7.0
    VB 2003=7.1
    VB 2005=8.0
    VB 2008=9.0
    VB 2010=10.0

    (VB 2012 Developer previewhttp://msdn.microsoft.com/en-us/library/dd642420(VS.110).aspx)

    .Net is always required.

    Visual Studio:
    http://msdn.microsoft.com/en-us/vstudio/aa718325


    Armin

    2012年2月23日 14:45
  • 1 - Where are we with Visual Basic?

    (MS lost me when they went to .Net)

    2 - What is the latest version of VB?

    3 - Can you write an application in the current version of VB without using the .Net stuff?

    4  - And compile it so that it is not reliant on the .Net virtual machine?

    Finally, will programs developed using the original VB6 run on Windows 7? How about the upcoming Windows 8?

    Thanks for any help.


    I think you have some misconceptions about what .NET is and is not. While it is human nature to resist change, the .NET framework has made programming available to a greater potential developer market (both good and bad). It has also been around a decade, now - indeed, some are beginning to consider it long-in-the tooth...

    Answer 3 & 4.

    The .NET framework is NOT a virtual machine. You can think of it as a bank of rather extensive DLLs, or libraries of code, which allow the developer to work on applications and higher level thinking than shuffling bytes around - these libraries do all the grunt work for you. If you use the .NET framework, then you need the .NET framework. Note that most computers come with the framework, or make it easily accesible to those that don't have it. With an operating system that can consume 7 or 8 GB of space, a 30MB file really isn't a stretch.

    Remember, we went through the 'runtime' argument with VB6 (and VB5 and VB4): can you run a VB6 application without the runtimes? The question is moot because it is the end result that counts.

    "Wow! a new application that does all my banking for me, makes the coffee, and does my job for me, and allows me to win at WoW! I want that....oh, wait, it needs the .NET 4.0 framework. Pah, who needs that hassle! Grrr."


    Stephen J Whiteley

    2012年2月23日 14:58
    モデレータ
  • Patrice,

    You mentioned "another non .NET dependent compiler"

    Would you be kind enough to refer me to some of those alternatives.

    And, that's good news about VB6 in Windows 8 !

    Maybe we should create the Application using VB6...

    but it would be helpful to look at all the available alternatives to .NET (in this particular case)

    Thanks for the help.

    2012年2月23日 15:00
  • Also note that the Framework is becoming even more integrated with Windows as of Windows 8.

    The Mono Project also exists to get a compatible framework for non-Windows operating systems.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    2012年2月23日 15:14
    モデレータ
  • Assuming you want to keep a basic like language you could try : http://en.wikipedia.org/wiki/Category:BASIC_compilers. RealBasic, PowerBasic, KBasic are those I heard about from time to time but you'll find likely also some changes compared with VB6 (not sure if what you disliked was language changes or having a one time runtime installation). If the later .NET Framework 4 introduces a usable "client profile" that should be enough for most desktop based application and that is about 40 mb in size...


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".

    2012年2月23日 16:03
  • Stephen, thank you kindly for your reply.

    Regarding your comment that ".NET frame is NOT a virtual machine"
    - It is my understanding that applications written using the .NET framework compile to an intermediate language... Common Language Runtime (CLR)
    - And at runtime that CLR code is fed to another program which then converts it into "native language" for the machine.
    - That software may be called an Interrupter... or translator... or runtime compiler or virtual machine... I'm not sure but...
    - And as I understood it .NET was to be MS response to the Java Virtual Machine which reads the 'byte code' or whatever it is called that the Java compiler produces...
    - The goal as I understood it was this "virtual machine" could be deployed and used on Windows and non-Windows systems... so the developer could write the app once and compile it for "interpretation" by the various versions of the "virtual machine"
    - And while I understand that lot's of good time saving classes/objects/methods/sub-routines/etc have been developed for .NET... the goal of having a .NET "virtual machine" or "Interpreter” running on Linux, Mac, etc did not fully materialize... right?

    I may be wrong with my above thought of what .NET was... so thanks for any additional comments from you or others.

    Regarding your analogy of .NET being simply a collection of DLL's... which to me are...
    ... a bunch of code consisting of 'classes' that can be instantiated (sp?) to an object
    ... which contains a bunch of methods & properties... and maybe other objects...
    ... or the DLL may just contain some code that you can call from your application directly to do a job...
    ... or maybe the DLL has some pointers to code somewhere on the machine that can do some task

    Or... maybe there is code in the DLL that actually launches another program called a 'virtual machine" or 'interpreter" or whatever... (is this the case?)

    I don't think the 30MB file to support .NET App's is the issue and your analogy to the VB6 runtime is a good one.
    - To me the issue is what kind of programmer are you?
    - You can now use Drag & Drop tools and never write a line of code.
    - You can use a very high level language that...
    ....depends on another program on the machine...
    ....that depends on yet another program on the machine...
    ....etc...
    .... until the CPU finally get's an instruction to shift the bits up in Register A by one or to write the value from memory location xyz to Peripheral A...
    - Or you can use a language and a compiler that results in code the CPU can simply execute... with no middle-ware getting in the way... except for the OS, of course.
    - Ultimately it's a matter of project requirements, schedule & budget...
    - And in today's market the poor software guy is getting beat up by marketing to just get it done...
    - and so we are all headed for drag and drop or you miss the marketing window...
    - and to heck with worrying about system resources.

    But I digress... sorry :-)

    Your points are good ones but we are still looking at options other than .NET for this particular project.

    But who knows? We are still researching.

    • 編集済み Mel_3 2012年2月23日 16:40
    2012年2月23日 16:05
  • Reed,

    Thanks for the introduction to the Mono Project. That looks very interesting.

    I'm wondering if MonoDeveloper and Windows Visual Studio Express is all that is needed for a project.

    Visual Studio Professional is the next step up from Visual Studio Express... right?

    If so what does "Professional" provide that is is of the most importance?

    Thanks for the help.

    '

    2012年2月23日 16:39
  • You do misunderstand...

    The source code is written in a high level language like VB or C#.

    The language complier (VB compiler, C# compiler, etc.) converts the code into an intermediate program language called MSIL.

    The MSIL source code is then further compiled into assembly.  MSIL is still a programming language and must be compiled.  It is possible to write .Net applications directy in MSIL and then compile the assembly.  Its just that MSIL is not friendly and there is no rich editor.  .Net code was meant to be written by people using high level languages, then converted by the compiler into MSIL, and then the MSIL is compiled into assembly at run-time as-needed by the Just-In-Time (JIT) compiler.

    The .Net Framework is comparable to a suite of DLLs, as Stephen said.  The .Net Framework should be considered as an extension of the Windows Base Code.  It should not be seen as an interpreter such as the Java VM or the VB6 Runtime.  With Windows 8 and WinRT we will see even tighter integration of the framework with the widnows core (WinRT should remove most of the remaining COM-Interop sometimes necessary with indepth Windows interaction).


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"


    2012年2月23日 16:47
    モデレータ
  • That should be enough to get started.

    I think that the main differences between express and professional are:

    1) Express is one language per IDE; Pro is all languages in one IDE

    2) Express has only a few basic project templates; Pro has many project templates for Forms, Services, Web, Office, etc.

    3) Express lacks certain windows or wizards like the Data Sources window.

    However, you can still do everything in Express that you can do in Pro but it may take a bit more work in Express when Pro offers a template or window to speed up productivity that Express doesn't have.

    I rarely use Express so there may be other limitations I'm forgetting, but I think those are the main issues.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    2012年2月23日 16:52
    モデレータ
  • In addition to Mono mentioned by Reed Kimble, applications written against WinRT will run also on Windows On ARM (http://blogs.msdn.com/b/b8/archive/2012/02/09/building-windows-for-the-arm-processor-architecture.aspx) processors using the same binaries. This is another thing that would not have been possible without this kind of architecture.

    Also it's quite easy to reuse your skills accross Desktop, Web, Windows Phone, Silverlight, Windows 8 applications and likely others I forgotten (for example XNA alllows even to develop against XBoxes)... Basically now each environnement (a real OS, a plugin that runs inside a browser, a phone device, a game console etc...) is seen through its own variation of a .NET like "runtime" that ships as a single unit, is installed once for all and exposes its capabilities as classes (note though that they are differents runtimes, you'll feel at home quickly but you don't have the same classes, mechanisms accross those platforms). "The Framework" could be considered as just how the OS is seen by a developper. You can also of course use thrid party librairies and (depending on the platform) tap into the underlying OS features that would not have been yet exposed.

    Even with native apps you actually do depend on external librairies as this is just how Windows is built (you never had to upgrade a component used by your VB 6 app ?). You do have MFC Librairies, third party ActiveX controls, a VC++ runtime etc... that are distributed through various means...


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".

    2012年2月23日 18:39
  • Thanks Guys!

    Very Helpful.

    2012年2月23日 20:38
  • Stephen, thank you kindly for your reply.

    Regarding your comment that ".NET frame is NOT a virtual machine"
    - It is my understanding that applications written using the .NET framework compile to an intermediate language... Common Language Runtime (CLR)
    * Not quite, should be Microsoft Intermediate Language (MSIL)
    * The CLR is "framework part" of .Net

    - And at runtime that CLR code is fed to another program which then converts it into "native language" for the machine.
    * Not quite; the MSIL is compiled into a native code assembly at run time by the JIT.  The resulting exe or dll is in MSIL but is compiled on the fly as the program executes.

    - That software may be called an Interrupter... or translator... or runtime compiler or virtual machine... I'm not sure but...
    * Typically Interpreter, especially today where "virtual machine" or VM now referrs to a full instance of an OS running within a virtualized OS environment.

    - And as I understood it .NET was to be MS response to the Java Virtual Machine which reads the 'byte code' or whatever it is called that the Java compiler produces...
    * From the perspective of object-oriented managed-code, yes.  But .Net was intended to be far superior to Java by laying directly on top of the OS and specifically not requiring an interpreter. The interpreter is replaced functionally by the Just-In-Time compiler.

    - The goal as I understood it was this "virtual machine" could be deployed and used on Windows and non-Windows systems... so the developer could write the app once and compile it for "interpretation" by the various versions of the "virtual machine"
    * This was a Java design benefit, yes.  It was not originally part of what .Net was intended to do, but non-Windows developers wanted it enough that things like the Mono project, Microsoft's own incentives around PHP and Azure, and a number of other third-party products are making .Net technologies friendly for a number of platforms.
    * Custom compilers can be created for visual studio to take the MSIL which is generated from the source language and then compile it into native code (machine code/assembly code) for other platforms or processors.
    *  But it is not enough to simply translate the instructions for another OS or processor... because many of those instructions are telling Windows to do windows-stuff.  So OSX or Linux would not have that "windows-stuff" to do.  This is where something like MONO comes in.  Mono will pretend to be the CLR only it will listen for instructions to do "windows-stuff" and know how to actually perform the equivelent "osx-stuff" or "linux-stuff".  This "stuff" is essentially the same code proceedures that a C++ developer would write (appropriately) for any platform.

    - And while I understand that lot's of good time saving classes/objects/methods/sub-routines/etc have been developed for .NET... the goal of having a .NET "virtual machine" or "Interpreter” running on Linux, Mac, etc did not fully materialize... right?
    * We've covered this =)

    I may be wrong with my above thought of what .NET was... so thanks for any additional comments from you or others.

    Regarding your analogy of .NET being simply a collection of DLL's... which to me are...
    ... a bunch of code consisting of 'classes' that can be instantiated (sp?) to an object
    ... which contains a bunch of methods & properties... and maybe other objects...
    ... or the DLL may just contain some code that you can call from your application directly to do a job...
    ... or maybe the DLL has some pointers to code somewhere on the machine that can do some task
    * Yup, that sounds pretty good to me too. oh, and instantiated is correct.  :)

    Or... maybe there is code in the DLL that actually launches another program called a 'virtual machine" or 'interpreter" or whatever... (is this the case?)
    * In Java, Ruby, Python, and many others, this would be the case.  Not in .Net though - the required programs are already running as part of the OS.

    I don't think the 30MB file to support .NET App's is the issue and your analogy to the VB6 runtime is a good one.
    - To me the issue is what kind of programmer are you?
    - You can now use Drag & Drop tools and never write a line of code.
    - You can use a very high level language that...
    ....depends on another program on the machine...
    ....that depends on yet another program on the machine...
    ....etc...
    .... until the CPU finally get's an instruction to shift the bits up in Register A by one or to write the value from memory location xyz to Peripheral A...
    - Or you can use a language and a compiler that results in code the CPU can simply execute... with no middle-ware getting in the way... except for the OS, of course.
    - Ultimately it's a matter of project requirements, schedule & budget...
    - And in today's market the poor software guy is getting beat up by marketing to just get it done...
    - and so we are all headed for drag and drop or you miss the marketing window...
    - and to heck with worrying about system resources.
    * With most modern development systems there is a good blend of choice between code-centric and designer-centric development.  If the development system doesn't offer a good blend of those choices than it it likely dated or built for a specific purpose.  .Net offers a wide variety of development choices; which kind of developer are you?

    But I digress... sorry :-)

    Your points are good ones but we are still looking at options other than .NET for this particular project.

    But who knows? We are still researching.

    I know I already replied once, but I couldn't help going back and addressing a few things point-by-point... what can I say, I enjoy these kinds of threads.  :) 

    Also, if you want to share with us a brief description of the application you intended to build, we might be able to help suggest a technology.  As a general platform ".Net" has become so broad that the hardest part about using it could be deciding which specific .Net technology(ies) to employ!

    And if .Net isn't the right answer (which sometimes is the case) then many of us are also familiar with other technologies so may be able to offer some direction.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"


    2012年2月23日 20:57
    モデレータ
  • If you are set on not using the .NET framework - or more specifically, that's the path you take - then using a C-style language will be more versatile. Non-.NET VB, I believe, is rather limited. With C, once you have the syntax and structuring down, then the platform is almost independent: you just need an appropriate IDE, framework and/or system API.

    For me, I program a lot of low level PLCs, HMI systems and various interface mechanisms. When on Windows, I'll use VB.NET as I feel it's easier to concentrate on the task, rather than understand the language (but that's a personal opinion). If a fast algorithm is needed, I'll use a standard C DLL - which can quite readily be used with .NET.

    As you note, the tool to use depends on external constraints quite considerably. However, without knowing the specifics, if you are programming on the windows platform, the easiest and quickest choice would be a .NET based language. If you are familiar with VB, then it would be VB.NET.


    Stephen J Whiteley

    2012年2月23日 21:22
    モデレータ
  • Thanks again folks.

    Regarding the particular application driving this... two goals...

    1 - Migrate a Access VBA project to a more general purpose language that can be compiled, safely distributed, copy protected, and difficult to de-compile... just as any other commercial application might be.

    2 - Position for future development projects with new and improved skills using a more general purpose, broadly used, aggressively supported, and stable language, IDE, etc... hopefully with cross platform compile capabilities... and good tools for creating an installer package suitable and safe for general software distribution in the market place.

    Thanks again for the comments everyone.

    2012年2月29日 14:28
  • Well, lets address the primary part of Point #1 that everyone seems to get hung up on first...

    Anyone with the know-how can decompile anything running on Windows.  If your program includes some sensative algorithms then there are tools and techniques you can use to obfusticate the code and make it more difficult to read.  There are thousands of commercial .Net applications so its safe to say the language has little to do with it.  Its more about coding technique and obfustication.

    Click-Once distribution is really slick and powerful so I'd say you're covered there as well.

    And since the code is VBA to start with, VB.Net is a natrual transition path.

    As for point #2, other than perhaps the corss-platform support (when talking desktop apps) I don't know what would fit the bill better than .Net.

    If your main objectives are future-proofing the app, protecting your code, and offering wide-platform support, then consider a cloud-app (SaaS).  Use .Net to build an application that serves itself up through the web via HTML5, or use SilverLight and target various UIs.  If a browser is the ultimate runtime engine, your program can work on anything you can fit a UI on.  It is also quite common today to create your application independant of a UI and then offer individual UIs for various platforms and formats.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    2012年2月29日 15:51
    モデレータ
  • Reed, thank you again for your very informative comments.

    Point #1:
    Yes programs can be decompiled... but to what? Assembly Language or can a .NET application be decompiled all the way back to the original .NET source code? That would mean a fully compiled .exe file could be decompiled to give VB or C or C++ .NET source code ? Is that true?

    If that is true then one would wonder if any .exe, no matter what language it was originally written in could be turned into source code for any chosen .NET language one desires... I guess it is possible to program anything but that sounds like a lot :)

    Point #1a:
    Distribution & Copy protection issues are one of the key concerns developers have...
    1aA: How to package your application so it can be downloaded as a time-limited, or function-limited demo...
    1aB: and include the code/tools in the package for preventing the user from just reinstalling the demo over and over... 
    1aC: How to take a finger print of the destination PC and use that as part of the copy-protection
    1aD: How to allow the user to enter a unique key for that particular machine and that particular copy of the application to enable full functionality after the user had paid for full functionality.

    Point #1 Summary:
    - The ability to build and securely distribute applications
    - With reasonable decompile difficulty
    - And industry standard demo copy contro
    - And industry standard copy protection
    Are among some of the key issues developers are interested in.

    The Question: Does .NET provide all of this built in (if so which version?)... or must the Developer cobble together their own scheme & code?

    Point #2: future-proofing, SaaS, etc

    I wonder if there are any simple concept tutorials (video tutorial would be nice :) on line that basically quickstarts you through a "Hello World" or other such example to...

    "Use .Net to build an application that serves itself up through the web via HTML5, or use SilverLight and target various UIs."

    However I'm not sure about SilverLight. Isn't that going the way of Flash? I would think HTML5 would be the way to go...

    But writing a simple .Net app and having it available as a cloud app using HTML5 sounds very interesting.

    - Know of any quick start tutorials?

    - I haven't been keeping up on SaaS Cloud providers. I know Amazon offers a lot of Cloud stuff. Who do you suggest for a quick little experiment?

    Thanks again for the help.

    2012年3月1日 13:50
  • Wow, someone should have caught that and corrected me...

    I'm glad this came up because I wasn't entirely correct... I've been thinking of .Net as "managed-native-code" for so long now that I take for granted and forget about some of the technicalities.

    You were right that .Net framework is technically a virtual machine (OS-integrated), and the assemblies contain the MSIL and not the machine code.  The part we've forgotten to mention is the JIT.  The MSIL is compiled more-or-less in real-time as the program is executed; so in practice it is more like native code running on the OS than it is like script code running in an interpreter.  But since the package (exe or dll) contains MSIL it can be easily decompiled and rebuilt into a higher level language.

    This is where Obfustication and/or Refactoring come in to protect your code.  And this is something extra you have to do, and it is a trade-off between rapid development and extra steps for protection.  But considering that more than half of your application is likely to be code to show UI controls and handle user events and nobody cares or wants to see it, you often only need to worry about one DLL with a handful of specialized, task-specific classes that need to be protected.

    Again, if you use any kind of SaaS or hybrid model, you can keep the sensative portions of the program in the cloud and never give the user a chance to decompile it in the first place.

    As for Demos/Trials and Licensing Activation, I would suggest looking at two of the largest and most pirated software titles of all time: MS Office and Adobe Photoshop.

    These products show that you really have two options: one, deal with the theft and make paying for the product include enough benefit that legit users will want to pay; or two, move to an online/telephone activation method against a remote server you control and force everyone to activate and occasionaly reauthenticate.

    Forcing the application to go online and connect to a server you control is about the only way to enforce any kind of registration or limited usage.  You can try to make it hard to get two free trials by requiring and recording the email address and telephone number of the user when they activate the trial online, but you then have to foot the bill to validate that email and phone number (you actually have to call them).

    At the end of the day, if you product is good and reasonably priced, the people who can use it will buy it.  Your Terms of Use and legal department cover the rest.

    You might want to look through: http://msdn.microsoft.com/en-us/magazine/rss/default.aspx?z=z&all=1 

    I remember recent seeing an article that does a whole "i-tunes" like music store in a simple example.

    And as for SilverLight, I'd say it is on its way in more than out.  Right now it's a pretty hot platform; windows phone development for instance is either SilverLight or XNA.

    For the cloud, you can look at Windows Azure and Google Apps as different ends of the provider spectrum; but keep in mind that so long as you have an IIS webserver you can control (either your own or hosted) then you can deploy your own webapp and therefore your own "cloud"-centric solutions.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    2012年3月1日 17:05
    モデレータ
  • Thanks again Reed.

    OK, since... effectively... if I understood your answer correctly... MSIL is executed by a Just-In-Time process (compiler, interpreter, translator, or what ever) that already resides on the machine... and converts the MSIL code into actual instructions for the CPU...

    That gets me back to asking if any of the Visual Studio Products... VB, C, or C++ can actually produce a fully compiled computer program that requires no further JIT processing... for lake of a better term... what we once considered a .exe or .com program... which actually consisted of fully compiled machine code...

    I would guess traditional C or C++ compilers would do this... for instance the open source GCC compiler... (many others listed on Wikipedia).

    But I'd rather stick with MS products... but would really like to have the application completely compiled and not require a JIT...

    So do any of the Visual Studio products do this?

    Thanks again for the help.

    2012年3月1日 22:18
  • Since the issue relates to the underlying MSIL, if any VS product does it, they all do it.

    In this case, I believe the answer is to add NGen to your list of protection tools:
    http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=VS.80).aspx

    This would allow you to bypass the JIT. 

    I believe you could also create a custom JIT in conjuction with a custom Compiler to encrypt the intermediate code (disassembling such a package would result in an encrypted version of the MSIL).


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    2012年3月1日 22:44
    モデレータ
  • Also note, the reason I had forgotten all these details over the years is because the Framework works so well; you literally forget it is there (as intended). 

    Don't fear the JIT compiler; it is your friend.  =)


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    2012年3月1日 22:47
    モデレータ
  • It looks like the issue with NGen is that it is run on the users machine at the time the VS app is installed.

    This means you are still distributing your program as a high level (intermediate) language (MSIL) that can easily be converted back to source code.

    Here is the process as I understand it...

    Step 1: Developer writes a program using .NET. (Source Code)
    Step 2: Developer ask the .NET development system to "compile" the Source Code via the CLR into MSIL (MS Intermediate Language)
    Step 3: Distribute the application (your distributing MSIL at this point... not a fully compiled application... this code is easily converted back to Source)
    Step 4: User installs the application on their pc. The application is still MSIL at this point)Step 5: User "Runs" or "Launches" the application
    Step 5: The Applications MSIL code is fed to a JIT Compiler... which actually compiles it into code the computer's cpu can execute.

    Correct so far?

    Alternately... using NGen the steps are altered as follows...

    Step 4: User installs the application on their pc (their putting a copy of your program on their PC that is still MSIL code & easily convertec back to Source)
    Step 5: the NGen program (resident on the users computer) compiles the applications MSIL code to code the computer's cpu can execute and saves it so that it is ready to run when the user wants.

    Is the above also correct?

    What I would wish for is...
    Step 1: Developer write a computer program (Source Code)
    Step 2: Developer compiles the program to code the target computers cpu can execute with no further compilation or conversion required
    Step 3: Distribute the application (your distributing a completely compiled computer program now... that can be dis-assembled to Assembly Language by a knowledgeable programmer... but would be extremely difficult to convert back into high level language source code)
    Step 4: User installs the application on their computer
    Step 5: User runs the application anytime they wish... 

    Here is the question... is MS or Adobe or Intuit, etc distributing their applications as MSIL code?

    If so then they must be putting all the good stuff into fully compiled DLL's... that is difficult to restore to source code...

    As I can't imagine they would distribute propritary code as MSIL... would they?

    Maybe I still have this all wrong.

    Thanks again for the help.

    2012年3月2日 16:12
  • Yeah, it sounds like you've got that right.  But I'm really curious as to why you are so against the JIT?  I mean, we are talking about some kind of data management application if it used to be an Access VBA solution... right?  With all of .Net's optimizations for data, I would almost challenge someone to write a data management application in C++ that was noticably faster and more stable than one created in VB.Net.  If a person could do it, they could probably also write a better OS than Windows, given enough time.  =P

    Anyway, MS is moving in the direction of having applications in 100% managed code, but they have decades of C++ to work with; same goes for Adobe.  These guys probably aren't good examples because their primary application cores are so old.

    But there are 100s if not 1000s of commerical .Net applications... here are a few good examples of some high-dollar applications:

    http://www.intuitivemfg.com/product-tour/technology/erp-and-net.aspx
    http://www.epicor.com/Solutions/Pages/Enterprise-Business-Software.aspx
    http://www.infor.com/product_summary/erp/sl/

    Those are entire ERP packages written in 100% managed code.

    Although I don't believe any of them are 100% .Net yet (maybe Nav...), the entire MS Dynamics product line is headed toward being written in .Net as well.

    If you are concerned about your source code, then you Obfusticate and Refactor.  If you follow the recommendations for protecting your code, the MSIL becomes extremely labor-intesive to decipher -edit- I should probably say, "any higher level code generated from the MSIL".  It works for lots of folks all over the world, and it's nothing new... this should give you confidence.

    Every choice is about weighing pros and cons, isn't it?  This is a mature product supporting real-word applications; its not just a toy.  If the pros of .Net did not far outweigh the cons, I don't think it would be nearly as huge as it is.  The .Net framework may not always be the best choice for every solution, but I haven't really seen anything about this situation which indicates that another technology would be better.

    One can embrace all that is good and useful about .Net and learn about how to protect against potential code theft which may or may not ever occur, or they can forego all of the benefits entirely in order to ensure that the fear of a possiblity never becomes a reality. :)


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"


    2012年3月2日 17:12
    モデレータ
  • Without an IL layer, all high-level language compilers would have to be able to produce native code. This is reinventing the wheel for every language. With a central JIT-compiler this redundance can be avoided, and everone can benefit from improvements and optimizations without a required integration in every single language.

    Also don't forget that the JIT-compiler is able to compile to 32 or 64 bits depending on the OS of the target computer. Without it, two versions of the same application would have to be distributed.

    And platform "independence"? Hardly possible to run on Mono if you compile with e.g. 32 bit Windows target on the development computer.


    Armin


    2012年3月2日 17:52
  • Are the major Microsft or Adobe or Intuit products sold & distributed as MSIL or other intermediate language?

    2012年3月2日 19:49
  • Are the major Microsft or Adobe or Intuit products sold & distributed as MSIL or other intermediate language?

    Like I said, those are a poor choice for example; you're talking apples and oranges.  Adobe and Intuit have never had .Net-based applications and Microsoft has decades of C++ code to deal with.  MS is migrating products toward managed code as best it can but few have made it to 100% .Net applications.  That should change substantialy though with Windows 8.

    AFAIK Adobe's flagship products, also being reliant on decades of C++ code, have not been implemented in managed code.  I don't know what the latest quickbooks uses but again it coming from an ancient code-base to begin with.  But as previously mentioned, things are about to change quite a bit - I don't know if Adobe development tools for Windows will always be relegated to "legacy mode" but I would expect Adobe to get on board with wanting to offer the best possible user experience. So we may see fully-managed Adobe products in the near future.

    The three examples I gave you cost far more than QuickBooks and Adobe Creative Suite combined and they are from well established companies, with Infor in particular being every bit as large as Intuit or Adobe, so its not like we're talking about off-the-wall software vendors here. 

    I'm trying to give you apples to apples; you need to look at software either developed, or completely rewritten, within the last ten years.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"

    2012年3月2日 20:49
    モデレータ
  • Without an IL layer, all high-level language compilers would have to be able to produce native code. This is reinventing the wheel for every language.


    Armin


    Armin got it I think right here with the IL layer comment.  Eric Lippert blogged about almost this exact same topic just a couple months ago.  He does a good job explaining what the reasons for an IL are:

    http://blogs.msdn.com/b/ericlippert/archive/2011/11/18/why-il.aspx

    2012年3月2日 22:18
  • I'm not sure what is wrong with compilers producing code that the target machine will run... with out the aid of a second compiler (JIT compiler in this case.)

    If your going to write a JIT compiler for every flavor of cpu, system architecture, OS, available system calls, etc... why not just package that JIT compiler code along with the source code compiler... and let the developer compile for the target machine/system of their choice.

    I'll take a look at the referenced article.

    Maybe this was answered earlier in the thread... but do the VS C & C++ compilers also... only compile to MSIL... or do they do a complete compile to "native" code? Is it only VS VB (& maybe C#) that are only compiled to MSIL?

    Thanks again for all the comments guys. I'm sure this has all been discussed before... but I'm also quite sure there are others who are late to the party... like me :)

    2012年3月4日 2:44