#530 Improve plugin API for NSIS 3.x

[賈可]

In the plugin API, we can found a structure declaration named "exec_flags_t". This structure provide some utility installer settings for plugin developtors. Now, NSIS 3.x is comming, and it can build both ANSI and unicode installer with one script file. I sugguest NSIS to add an extra flag to indicate whether the installer was built with unicode, this could help developtors to make one plugin working with both ANSI and unicode installer.

typedef struct {
    int autoclose;
    int all_user_var;
    int exec_error;
    int abort;
    int exec_reboot; // NSIS_SUPPORT_REBOOT
    int reboot_called; // NSIS_SUPPORT_REBOOT
    int XXX_cur_insttype; // depreacted
    int plugin_api_version; // see NSISPIAPIVER_CURR, used to be XXX_insttype_changed
    int silent; // NSIS_CONFIG_SILENT_SUPPORT
    int instdir_error;
    int rtl;
    int errlvl;
    int alter_reg_view;
    int status_update;
    // add unicode flag
    int unicode;
} exec_flags_t;

To use it, we must check "plugin_api_version" member first. Though there is a previous case, the plugin "BgWorker.dll" works under both ANSI and unicode, but it check unicode by IsWindowUnicode when hwndParent is not NULL, else, it is very inconvenient.

[Anders]

The BgWorker plugin was created when the only Unicode version was the unofficial fork and the layout of future plugin directories was unclear. We now have full directory separation so I don't really seen the need for a run-time flag.

While the idea of a CHAR/WCHAR agnostic plugin is cute, actually developing one is not exactly a pleasure. You need extra conversions for every input and output string (stack and registers) and branches for everything that might call a A/W Windows function...

[賈可]

Though you think it is unnecessary, I still express my opinion. To write a plugin compatible with both ANSI and unicode, the source code could use the unicode string and unicode functions only, just convert the input and output. Also, why these functions or macros exists in pluginapi.h?
- PushStringA
- PopStringA
- PushStringW
- PopStringW
- GetUserVariableA
- SetUserVariableA
- GetUserVariableW
- SetUserVariableW
As you say, they are unnecessary. I also dislike these function if I could not detect string encoding while running.

[賈可]

I don't think this feature is necessary. But if doesn't support checking text encoding, these functions are pointless and should be removed.

[Anders]

Pointless is a bit harsh. Some of the APIs in newer versions of Windows only have a wide version, this is even true for some of the old shell APIs and these helper functions save you some work by converting for you.