locked
Making Programs

    Question

  • Hi,

     

    How do i make a program where it will work on any computer regardless of whether it has .Net installed on it?

     

    Hope to hear a response soon,

     

    Wednesday, May 14, 2008 6:23 PM

Answers

  • Most vb6 programs run plainly, but like one reviewer stated there is no silver bullet for all platforms.

    Thursday, May 15, 2008 5:38 PM
  • Hello,

     

    As it has been said in a last post, nearly all computers have now the .Net Framework 2.0, except the rare XP not in SP2,

    Windows 2000 and "exotic" Windows 95/98 and Me ( oh i've forgotten some old NT4 , yes, some are always living ).

    Except if you program in Java, you will face the problem of the OS .

    - MAC OS : i don't care as their users are generally anti-Windows and they consider the security as their last problem

    - Linux : i know there is a project to adapt .Net 2.0 to Linux : i think that's called MONO

    - the other OS different of Windows are really special ( UX,SUN...) and generally reserved for storing huge databases

     

    In any case, XP SP2 and VISTA represent about 85% of the whole personnal computer.So if you write a program with .Net 2.0 , you are sure to satisfy about 85% of the users. It's not too bad.

    Don't forget that when you ask to someone to download the .Net 2.0, it will be done once and many other downloads will be available.

     

    I think that with Visual Studio 2005/2008 Express, you may produce program for enough people without thinking to the others.

     

    I'm only pragmatic.

     

    Have a nice day

     

    Thursday, May 15, 2008 6:30 PM
  •  Robotic_Rob wrote:

    Am sure Ive downloaded many programs in the past that have just worked without the need to download anything else.



    That was possible in the times where 99% of domestic users were running Win9x upon x86-compatible processors: there was a huge set of API's and the whole processor's instruction set that was shared among these 99% users, so the program wouldn't find any difference between each machine. These times, however, are long gone: nowadays there are several processor architectures that are widespread, and several Windows families (XP, 2003 Server, Vista) that have significant differences among them, and getting a native program running on all these platforms is not an easy task (specially because most of the native executable's content are instructions in the processor's native language, and there are significant differences among currently widespread processors).
    Using .NET is not that bad: if you target the 2.0 version you can rest assured that all XP SP2 and Vista users will have it; and can provide the installer just for those people that get back to you saying "hey, that didn't work, it tossed an error message about {some parts of the message here} at startup" and you're fine.
    If you still want to distribute the program as a single file no matter what, you can simply zip it (from XP onwards, windows has native support for browsing and extracting zips). Even further, you can create a self-extracting archive with any of the many zip2exe utilities that can be found on Internet. If you want to take the next step, you could configure the self-extractor to auto-run a setup batch after extraction; that batch could check for the existence of the appropriate version of the .NET framework, and then decide whether to run the .NET installer or skip it. While the recommended way to check for the installed .NET versions is to check the registry, that won't do for a batch; instead you can use something like this:

    DIR %SystemRoot%\assembly\GAC_MSIL\2.0.* /S
    IF ERRORLEVEL 1 ( GOTO REQNET2 ) ELSE ( GOTO SKIPNET2 )
    :REQNET2
    REM here goes the commands to install the .Net 2.0
    REM after the commands, you could repeat the check just to make sure
    Tongue TiedKIPNET2
    REM at this point the .Net should already be installed

    Change the 2.0 by 3.0 or 3.5 if you are targeting these versions instead.

    Ok, that was a non-elegant approach, but it's easilly implemented and gets the job done. If you want to do things the "good" way, grab an installer-maker, and go on from there. To put some example, NSIS (that's the one I generally use, so is the one about which I can speak) can create an installer that:
    1. Checks on the registry the installed versions of the .NET (if any) installed on the current computer.
    2. If the requried version is not available:
      1. Extracts the .NET installer
      2. Boots it in "silent" mode
      3. Waits for it to finish
      4. Checks that it finished without errors
        1. If there are errors, my installer will report them
        2. If there are no errors, the .NET is now ready, and the installer goes on.
    3. Once the .NET is installed (either it already was, or it has been installed in the process), the installation of my actual program / library (or collection of programs and libraries) goes on.
    Among the many advantages of using an installer there are worth pointing out:
    • Single file deploy: your entire package will be either a .exe or a .msi standalone file (avoid the tools that produce several .cab's without your consent, these are often worse than installing via PKUNZIP plus batch scripts).
    • Smaller size: besides the potentially included .NET installer, your own installer would normally take less space than distributing the same contents without it, since the contents are compressed before adding them to the installer.
    • Advanced features: most installer-making tools produce installers that let the user customize the process in several aspects:
      • Optional components: if your program includes non-essential components, it's up to the user whether to install these or not.
      • Target directory: the user should normally be able to chose where to install the program. Don't assume the user wants to have it on "C:\Program Files". Actually, I hate those installers that don't even check the environment variables nor regional configuration, and force the creation of that "Program Files" folder instead of using the "C:\Archivos the Progama" that holds most software in Spannish-windows machines. Feel free to chose a default, but let the user have the final choice: in the end, it's their machine, not yours!
      • Shortcuts: most installers (either automatically or optionally) are able to create relevant shortcuts on the desktop, quick launch bar, and/or the start menu.
      • Uninstaller: if not for everything else, at least for this reason you should make an installer: modern tools will make a decent installation that generates an appropriate uninstaller, and registers the program on the "Add or remove programs" listing.

    Hope this helps.
    Thursday, May 15, 2008 8:49 PM

All replies

  • This is a Visual C# Express Edition room. C# uses the .NET framework.

    What kind of application were you thinking of creating?

    Wednesday, May 14, 2008 6:33 PM
  • Just generally anything and everything. I started to learn C# about a month or two ago. Its slightly annoying that i need to give people the program with the little setup file with the basic .Net framework. I prefer to be able to send people the program.

     

    Wednesday, May 14, 2008 6:50 PM
  • Most Vista/XP computers have .NET, but that aside, you may want to consider Java. It boasts "all platforms".

    Wednesday, May 14, 2008 6:55 PM
  • There is really no way to make a program and have a guarantee that it will run "out of the box" on multiple different architectures. While Java is the nearest to this that you might get, it still requires the Java Virtual Machine installed on the target computer. It is not that different from the .NET. The biggest point in favor of .Net is that it allows you to author your code in a choice of different languages, while the JVM machine is aimed to work only with Java. On the other hand, the JVM has on its side a wider platform support (it currently works on all modern Windows, most flavors of Unix, MacOS, and many other systems), while Microsoft's official implementation of the .NET Framework only works on Windows system (and the latest versions only on XP or newer).
    Beyond that, it must be pointed out that it is possible to compile .Net languages to Java bytecode, thus enabling building programs for the JVM in many languages; but there are very few tools, if any, available for that purpose.
    On the other hand, thanks to the standarization of the CLI, the Windows boundary of .NET programs is breaking: Microsoft has published the SSCLI, which works out of the box on Windows, FreeBSD, and Max OS X (which is actually based on FreeBSD), and can be ported to other platforms without too much effort; but is limited to non-commercial use. There is also the Mono project (sponsored by Novell and powered by the free software comunity), which is already fully compatible (excluding a few namespaces from the library, deemed to be "too Windows-specific") with version 1.1 of Microsoft's .NET framework and near-fully compatible with the 2.0 version (the compatibility is "copy-deploy": binaries compiled from Visual Studio, for example, should run out of the box on mono, without need of re-compiling); and the dotGNU project, which is still on its way to achieve compatibility with .Net 1.x. Finally, it must be noted that, also thanks to the standarization, there is a huge list of languages, beyond the ones featured by Visual Studio, that can be compiled with third party tools into IL (and some of these tools can be integrated into the Studio), hence creating an unmatched array of usable languages and platforms able to run the resutling programs.

    As an aside, if the range of target platforms is reduced enough (ie: the program only targets some versions of Windows), then a native executable would do better: you could compile a program to native binary format (although I don't know of any C# compiler capable of native compilation) for each target system/architecture. But you must keep in mind that the final executable would be huge, since it would need to include all the libraries it's using. One of the points of the .NET is that it moves these libraries out of the final binary, so for two programs using the same library only one copy of that library is actually copied/downloaded to the target machine. In other words: if you build a native exe with 20mb of library overhead, and the user has already some other program using the same library, then the user is wasting those 20mb of space and, if either of the or both programs were downloaded, of bandwith. If you build a .NET exe, then the user might have to download the .Net Framework the first time, but further .Net programs will run without further action. This applies the other way around, so if your user already has the .Net installed (maybe they required it for an earlier version of your program), then they won't need to install it again. If distributing the .Net Framework installation bootstrapper is still such a pain, then instead you might add a notice in the readme file, the installation instructions, or the program's documentation indicating that the program requires the .Net, and providing a link to the download at the Download Center (you are already providing installation instructions and documentation with your program, aren't you?)

    Hope this helps.
    Thursday, May 15, 2008 12:29 AM
  • Well said herenvardo

     

    Thursday, May 15, 2008 3:09 AM
  • While I believe it to be fairly simple to develop applications on both the Windows & Mac OS X platforms, it is very hard to develop an application that can target every linux based machine on the market. Every installation of linux is different, and users might be missing components that your application might require. They could even be running the same version of the same OS and still have one machine missing components depending on what they chose to install during the installation of the OS. While I like Linux and think it's a very good OS, this is unfortunatly why it has not dominated the market like Mac OS X and Windows. Windows might require the .Net framework for some applications to run, but every version of XP (SP2 installed) and Vista come shipped with .Net 2.0 and it's not an option so you don't need to worry about people not having the framework already installed on the machine.

    Thursday, May 15, 2008 3:57 AM
  • Am sure Ive downloaded many programs in the past that have just worked without the need to download anything else.

     

    I ain't providing any instructions or documentation with my programs. I ain't publishing the programs to the world on a website. I just give friends the programs and i explain in person how to get it up and running. The programs are pretty self explanatory and it not Ive provided a little note in the program on what not to do.

    Thursday, May 15, 2008 5:35 PM
  • Most vb6 programs run plainly, but like one reviewer stated there is no silver bullet for all platforms.

    Thursday, May 15, 2008 5:38 PM
  • Hello,

     

    As it has been said in a last post, nearly all computers have now the .Net Framework 2.0, except the rare XP not in SP2,

    Windows 2000 and "exotic" Windows 95/98 and Me ( oh i've forgotten some old NT4 , yes, some are always living ).

    Except if you program in Java, you will face the problem of the OS .

    - MAC OS : i don't care as their users are generally anti-Windows and they consider the security as their last problem

    - Linux : i know there is a project to adapt .Net 2.0 to Linux : i think that's called MONO

    - the other OS different of Windows are really special ( UX,SUN...) and generally reserved for storing huge databases

     

    In any case, XP SP2 and VISTA represent about 85% of the whole personnal computer.So if you write a program with .Net 2.0 , you are sure to satisfy about 85% of the users. It's not too bad.

    Don't forget that when you ask to someone to download the .Net 2.0, it will be done once and many other downloads will be available.

     

    I think that with Visual Studio 2005/2008 Express, you may produce program for enough people without thinking to the others.

     

    I'm only pragmatic.

     

    Have a nice day

     

    Thursday, May 15, 2008 6:30 PM
  •  Robotic_Rob wrote:

    Am sure Ive downloaded many programs in the past that have just worked without the need to download anything else.



    That was possible in the times where 99% of domestic users were running Win9x upon x86-compatible processors: there was a huge set of API's and the whole processor's instruction set that was shared among these 99% users, so the program wouldn't find any difference between each machine. These times, however, are long gone: nowadays there are several processor architectures that are widespread, and several Windows families (XP, 2003 Server, Vista) that have significant differences among them, and getting a native program running on all these platforms is not an easy task (specially because most of the native executable's content are instructions in the processor's native language, and there are significant differences among currently widespread processors).
    Using .NET is not that bad: if you target the 2.0 version you can rest assured that all XP SP2 and Vista users will have it; and can provide the installer just for those people that get back to you saying "hey, that didn't work, it tossed an error message about {some parts of the message here} at startup" and you're fine.
    If you still want to distribute the program as a single file no matter what, you can simply zip it (from XP onwards, windows has native support for browsing and extracting zips). Even further, you can create a self-extracting archive with any of the many zip2exe utilities that can be found on Internet. If you want to take the next step, you could configure the self-extractor to auto-run a setup batch after extraction; that batch could check for the existence of the appropriate version of the .NET framework, and then decide whether to run the .NET installer or skip it. While the recommended way to check for the installed .NET versions is to check the registry, that won't do for a batch; instead you can use something like this:

    DIR %SystemRoot%\assembly\GAC_MSIL\2.0.* /S
    IF ERRORLEVEL 1 ( GOTO REQNET2 ) ELSE ( GOTO SKIPNET2 )
    :REQNET2
    REM here goes the commands to install the .Net 2.0
    REM after the commands, you could repeat the check just to make sure
    Tongue TiedKIPNET2
    REM at this point the .Net should already be installed

    Change the 2.0 by 3.0 or 3.5 if you are targeting these versions instead.

    Ok, that was a non-elegant approach, but it's easilly implemented and gets the job done. If you want to do things the "good" way, grab an installer-maker, and go on from there. To put some example, NSIS (that's the one I generally use, so is the one about which I can speak) can create an installer that:
    1. Checks on the registry the installed versions of the .NET (if any) installed on the current computer.
    2. If the requried version is not available:
      1. Extracts the .NET installer
      2. Boots it in "silent" mode
      3. Waits for it to finish
      4. Checks that it finished without errors
        1. If there are errors, my installer will report them
        2. If there are no errors, the .NET is now ready, and the installer goes on.
    3. Once the .NET is installed (either it already was, or it has been installed in the process), the installation of my actual program / library (or collection of programs and libraries) goes on.
    Among the many advantages of using an installer there are worth pointing out:
    • Single file deploy: your entire package will be either a .exe or a .msi standalone file (avoid the tools that produce several .cab's without your consent, these are often worse than installing via PKUNZIP plus batch scripts).
    • Smaller size: besides the potentially included .NET installer, your own installer would normally take less space than distributing the same contents without it, since the contents are compressed before adding them to the installer.
    • Advanced features: most installer-making tools produce installers that let the user customize the process in several aspects:
      • Optional components: if your program includes non-essential components, it's up to the user whether to install these or not.
      • Target directory: the user should normally be able to chose where to install the program. Don't assume the user wants to have it on "C:\Program Files". Actually, I hate those installers that don't even check the environment variables nor regional configuration, and force the creation of that "Program Files" folder instead of using the "C:\Archivos the Progama" that holds most software in Spannish-windows machines. Feel free to chose a default, but let the user have the final choice: in the end, it's their machine, not yours!
      • Shortcuts: most installers (either automatically or optionally) are able to create relevant shortcuts on the desktop, quick launch bar, and/or the start menu.
      • Uninstaller: if not for everything else, at least for this reason you should make an installer: modern tools will make a decent installation that generates an appropriate uninstaller, and registers the program on the "Add or remove programs" listing.

    Hope this helps.
    Thursday, May 15, 2008 8:49 PM