I think green software is software that requires no installation, is short and concise, and most of the current shareware falls into this category (or moves closer to green software).
Even the relatively large Photoshop software puts some registration items into a special registration file (reg file). When the operating system is reinstalled, you only need to import the reg file into the registry. In addition, software such as Kingsoft basically can be run without installation.
At present, most shared software is made using Delphi. Although its Pascal syntax is awkward, everyone still insists on using it. The best reason is that it is very convenient to make green software. Basically, everything can be done with an Exe file. .
Use VC to make shareware. If it is developed based on API (not MFC), it always feels like killing a chicken with a powerful tool (current machine configurations are relatively high, and shareware is generally small programs for applications, unlike servers. The performance requirements are so high, and the development cycle with VC is relatively long).
Although MFC is relatively fast to develop, there is also a runtime problem. Make it a dynamic link. Users of the Windows 9X series cannot use it. Compile it into a static link. The software size will be expanded by more than 1M. When the network bandwidth is not sufficient, It's better to use less.
There are many introductions to using VB to make green software, but a slightly complicated program also comes with a lot of dowries: VB runtime library, ocx control, etc. If the software also uses a database (such as ADO, DAO, etc.), Whether it can be made into green software is still unknown.
However, VB is easy to use and it is relatively fast to develop software. If you have a good grasp of API technology, most software can be implemented well. If you use VB to make shareware, development is easy and you can increase extra income. Why not?
But how to solve the above problems? Based on my experience and the development of some green software, I will share my opinions. If there is any inappropriateness, please correct me.
First, the problem with the runtime library can be solved in this way. At present, most users are using Win2000 and XP platforms, and for platforms above Win2000, Microsoft has added the runtime library to the system directory for us. (Concerning this point, Delphi users are very dissatisfied and think this is unfair competition. VB's runtime library and MFC's runtime library have been integrated into the system. In this way, Delphi is far behind software developed by VB and MFC, at least in terms of software size. ), so these users do not need to consider the issue of the runtime library. For users of the 9x series, the VB runtime library can be placed online, and users can download it directly from the Internet if necessary. If you don't mind the size of the software, you can also publish the runtime library together with your software (just put the runtime library in the same directory as the current software).
Although Microsoft no longer supports VB, as long as subsequent versions of Windows continue to integrate the VB runtime library, there is still a bright future for using VB to develop shared software (Microsoft dares to integrate the 100M .net platform, not to mention the 1.25M VB runtime Where's the library? I'm optimistic about that :)
Second, if you use VB to develop shared software, I recommend using only the basic controls of VB. In addition, do not use database operation controls (or references) such as DAO and ADO. If you operate data, I recommend defining the database format yourself (you can imitate databases such as dBase). format), when the amount of data is not large (for example, less than 10,000 records), this can be done. Current user machines are relatively high-end, so there is no need to consider too many performance issues. In this case, only the runtime library is needed to run the VB program. On Win2000 or above systems, it can be run directly.
Third, in order to make the software interface beautiful, you can directly use the image control to map the image. I always like to use this method. For multi-language versions, you can read ini files or directly read pure resource files compiled by VC (you can refer to an article I wrote: VB dynamically loads pure DLL resources (http://blog.csdn.net /yefanqiu/archive/2005/03/16/320640.aspx).
Fourth, after the software is developed, it is best to use exe compression software to compress it. This has two advantages. First, it adds an obstacle to being cracked. Second, the size of the software is greatly reduced, which is convenient for release.
Fifth, as for encryption, that is a matter of benevolence and wisdom. There is no need for me to talk more here. ->