Nduiker project 3rd days

Today is Saturday. I thought it was a very easy day. Only at this time can I write my blog today.

Yesterday, the nduiker project was not doing well, ^_^, but it was just getting started.

Summarize the technical problems:

The test execution file is dos, 16-bit, and 32-bit.ProgramIt took a lot of effort to find some materials on the Internet,

Visual Basic. Net Definition

Declare function getbinarytype lib "Kernel32" alias "getbinarytypea" (byval lpapplicationname as string, byref lpbinarytype as integer) as integer

C # Definition

[Dllimport ("kernel32.dll", setlasterror = true)] Static extern int getbinarytypea (string lpapplicationname, ref int lpbinarytype)

In fact, this API can be found in msdn. The key is to find a website that can query. Net APIs.

Http://www.webtropy.com/articles

This website provides standard. Net API queries and provides standard examples.

However, when using this API, everything works normally, but there is a problem when determining the number of file digits. Currently, you can only determine whether the file is an executable file and cannot continue to make in-depth judgments. Very depressing, looking for a solution.

Some APIs and interesting classes are also found in the specific solution. Although they are not available now, you should study them now.

Knowledge Base

How to use functions in version. dll -- a 32-bit Sample app)

Osfeature class

This class is very good. In the past, when using some Delphi skins, we found the form gradient effect, but these effects can only be displayed in a specific system. Now, through this class, it is easy to check the support of the operating system.

Yesterday's summary is basically like this. In general, it only solves the problem of whether the file is executable, but it is much better than determining whether the file is executable by file name.

Some new ideas about the nduiker project:

During these days, nduiker has taken a deeper look at the prototype of the nduiker project. First, nduiker can turn a large number of isolated CommandLine-based assembly into a usable program, although there are many ways to call other programs in the program, CommandLine may be the best way to combine products on multiple platforms. Currently, there is no better solution for interactive CommandLine programs.

Although a program can be connected through a batch processing file, the script program porting and transfer are complex because the batch processing file is large, multiple functions are combined into a large program, or the call is confusing. The key is that most programs are all on everybody's hard drive, which is a big waste.

Therefore, nduiker's mission is to organically combine these scripts to gradually form a standardCodeBy combining various programs in a visual way, this creates great productivity.

Nduiker should be able to take advantage of the advantages of existing scripts. the powerful functions of. Net improve the efficiency of scripts and improve the security of scripts (many scripts contain key information such as user names, passwords, server addresses, and so on ).

Nduiker should form a standard CommandLine web service, so that programmers can understand, communicate, and use command line, rather than letting good functions lie in the help.

Nduiker should also advise software vendors to pay attention to CommandLine development and application, so that CommandLine can be called in a unified and convenient way, and further facilitate the use of programmers.

Oh, maybe nduiker should be calledNcommandlineBetter? Select one for me.

Our current task is to plan the project functions and specific development directions.

Recently, it mainly collects various advanced CommandLine applications.

The second step is to complete some auxiliary tools for project development, such as CommandLine management tools and a CommandLine content management tool based on XML.

At the same time, we have completed some technical provisioning.

Come here today. Come tomorrow.

All good programs should support command line.