You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(16) |
Jul
(26) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
|
Feb
|
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(17) |
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2020 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Wizou <sou...@wi...> - 2010-06-24 23:40:35
|
I would appreciate to get an answer quickly, before I go in holidays and completely forget all the development I've done so far and it would take me a lot more time to get back into it and make things correctly... I feel that having a Unicode-compatible NSIS is very important for all the people using NSIS, so please don't wait too much in this subject.. especially as I'm ready to finish all the hard work.. I'm very confident in all the changes I've submitted already, so i just need your green light on the fact we won't be using the ANSI build of makensis.exe anymore.. (You just need to check that Unicode NSIS gives good results on various installers scripts, either generating ANSI or Unicode installers) Then I will be able to complete these last steps I explained below Wizou a écrit : > I must also do these things for Unicode NSIS : > > * Update documentation > * Convert NLF & NSH language files to Unicode > * Make sure NSIS works fine with pure-Unicode languages (that have > no associated codepages) > * Import pure-Unicode language files that were added to Jim Park's > repository > > That is easy to do, but the thing is : > I cannot complete these tasks until you give me green light about not > using ANSI MakeNsis.exe anymore. > (because ANSI version cannot support Unicode NLF) > > So please test & review the latest Unicode version and tell me when I > can proceed > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > ------------------------------------------------------------------------ > > _______________________________________________ > Nsis-devel mailing list > Nsi...@li... > https://lists.sourceforge.net/lists/listinfo/nsis-devel > |
From: Wizou <sou...@wi...> - 2010-06-16 16:30:23
|
alright, I let you it... don't hesitate to discuss here about your plans or if you need help Amir Szekely a écrit : > But those ArtificialFunctions would have been real functions if not > for this limitation. > > On Wed, Jun 16, 2010 at 7:25 PM, Wizou <sou...@wi... > <mailto:sou...@wi...>> wrote: > > as czi said, sometimes (often) you also need to push a set of > variables you don't want a block of code to modify and restore > them after. > > If i'm correct, a lot of the NSH included with NSIS implements > ArtificialFunctions which are not real function but blocks of code > generated as inline macro on-the-fly when the user call them... > > > Amir Szekely a écrit : >> I'd much rather go for a complete solution here rather than keep >> adding more and more workarounds. >> We need a normal way to define a function with arguments and >> return values. >> It's not that fun to create function prologue/epilogue manually. >> >> On Wed, Jun 16, 2010 at 7:14 PM, Wizou <sou...@wi... >> <mailto:sou...@wi...>> wrote: >> >> I intend to implemented this feature request: >> https://sourceforge.net/tracker/?func=detail&aid=1654575&group_id=22049&atid=373088 >> <https://sourceforge.net/tracker/?func=detail&aid=1654575&group_id=22049&atid=373088> >> with the following syntax: (example) >> >> Push $R1 $R6 "foo" >> .. >> Pop $R1 $R6 $0 >> >> Is anyone opposed to that syntax ? >> >> IMHO, we don't need new MultiPush/MultiPop keywords, and separate >> arguments by spaces rather commas seems more appropriate for >> NSIS syntax. >> (like was suggested in the comment or in the submitted patch) >> >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Nsis-devel mailing list >> Nsi...@li... >> <mailto:Nsi...@li...> >> https://lists.sourceforge.net/lists/listinfo/nsis-devel >> >> > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Nsis-devel mailing list > Nsi...@li... > <mailto:Nsi...@li...> > https://lists.sourceforge.net/lists/listinfo/nsis-devel > > |
From: Amir S. <ki...@gm...> - 2010-06-16 16:27:31
|
But those ArtificialFunctions would have been real functions if not for this limitation. On Wed, Jun 16, 2010 at 7:25 PM, Wizou <sou...@wi...> wrote: > as czi said, sometimes (often) you also need to push a set of variables > you don't want a block of code to modify and restore them after. > > If i'm correct, a lot of the NSH included with NSIS implements > ArtificialFunctions which are not real function but blocks of code generated > as inline macro on-the-fly when the user call them... > > > Amir Szekely a écrit : > > I'd much rather go for a complete solution here rather than keep adding > more and more workarounds. > We need a normal way to define a function with arguments and return values. > It's not that fun to create function prologue/epilogue manually. > > On Wed, Jun 16, 2010 at 7:14 PM, Wizou <sou...@wi...> wrote: > >> I intend to implemented this feature request: >> >> https://sourceforge.net/tracker/?func=detail&aid=1654575&group_id=22049&atid=373088 >> with the following syntax: (example) >> >> Push $R1 $R6 "foo" >> .. >> Pop $R1 $R6 $0 >> >> Is anyone opposed to that syntax ? >> >> IMHO, we don't need new MultiPush/MultiPop keywords, and separate >> arguments by spaces rather commas seems more appropriate for NSIS syntax. >> (like was suggested in the comment or in the submitted patch) >> >> >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Nsis-devel mailing list >> Nsi...@li... >> https://lists.sourceforge.net/lists/listinfo/nsis-devel >> > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Nsis-devel mailing list > Nsi...@li... > https://lists.sourceforge.net/lists/listinfo/nsis-devel > > |
From: Wizou <sou...@wi...> - 2010-06-16 16:25:55
|
as czi said, sometimes (often) you also need to push a set of variables you don't want a block of code to modify and restore them after. If i'm correct, a lot of the NSH included with NSIS implements ArtificialFunctions which are not real function but blocks of code generated as inline macro on-the-fly when the user call them... Amir Szekely a écrit : > I'd much rather go for a complete solution here rather than keep > adding more and more workarounds. > We need a normal way to define a function with arguments and return > values. > It's not that fun to create function prologue/epilogue manually. > > On Wed, Jun 16, 2010 at 7:14 PM, Wizou <sou...@wi... > <mailto:sou...@wi...>> wrote: > > I intend to implemented this feature request: > https://sourceforge.net/tracker/?func=detail&aid=1654575&group_id=22049&atid=373088 > <https://sourceforge.net/tracker/?func=detail&aid=1654575&group_id=22049&atid=373088> > with the following syntax: (example) > > Push $R1 $R6 "foo" > .. > Pop $R1 $R6 $0 > > Is anyone opposed to that syntax ? > > IMHO, we don't need new MultiPush/MultiPop keywords, and separate > arguments by spaces rather commas seems more appropriate for NSIS > syntax. > (like was suggested in the comment or in the submitted patch) > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Nsis-devel mailing list > Nsi...@li... > <mailto:Nsi...@li...> > https://lists.sourceforge.net/lists/listinfo/nsis-devel > > |
From: Amir S. <ki...@gm...> - 2010-06-16 16:17:26
|
I'd much rather go for a complete solution here rather than keep adding more and more workarounds. We need a normal way to define a function with arguments and return values. It's not that fun to create function prologue/epilogue manually. On Wed, Jun 16, 2010 at 7:14 PM, Wizou <sou...@wi...> wrote: > I intend to implemented this feature request: > > https://sourceforge.net/tracker/?func=detail&aid=1654575&group_id=22049&atid=373088 > with the following syntax: (example) > > Push $R1 $R6 "foo" > .. > Pop $R1 $R6 $0 > > Is anyone opposed to that syntax ? > > IMHO, we don't need new MultiPush/MultiPop keywords, and separate > arguments by spaces rather commas seems more appropriate for NSIS syntax. > (like was suggested in the comment or in the submitted patch) > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Nsis-devel mailing list > Nsi...@li... > https://lists.sourceforge.net/lists/listinfo/nsis-devel > |
From: Wizou <sou...@wi...> - 2010-06-16 16:14:36
|
I intend to implemented this feature request: https://sourceforge.net/tracker/?func=detail&aid=1654575&group_id=22049&atid=373088 with the following syntax: (example) Push $R1 $R6 "foo" .. Pop $R1 $R6 $0 Is anyone opposed to that syntax ? IMHO, we don't need new MultiPush/MultiPop keywords, and separate arguments by spaces rather commas seems more appropriate for NSIS syntax. (like was suggested in the comment or in the submitted patch) |
From: Wizou <sou...@wi...> - 2010-06-16 12:43:12
|
I must also do these things for Unicode NSIS : * Update documentation * Convert NLF & NSH language files to Unicode * Make sure NSIS works fine with pure-Unicode languages (that have no associated codepages) * Import pure-Unicode language files that were added to Jim Park's repository That is easy to do, but the thing is : I cannot complete these tasks until you give me green light about not using ANSI MakeNsis.exe anymore. (because ANSI version cannot support Unicode NLF) So please test & review the latest Unicode version and tell me when I can proceed |
From: Anders <and...@us...> - 2010-06-09 21:25:34
|
I don't really see the point, it is impossible to have a working transparent thunking layer since not every unicode path can be represented as a ansi path. I already made a CallAnsiPlugin plugin, it would also be possible to create a CallUnicodePlugin and they should cover the few cases where somebody needs to call a "non native" plugin. Also, PopStringA/W(str,COUNTOF(str)) should not exist at all, you only know the size at runtime so COUNTOF is useless here! (I know a lot of plugins hardcode the buffer size, but the official API cannot make this mistake) |
From: Wizou <sou...@wi...> - 2010-06-09 19:49:16
|
#ifndef ___NSIS_PLUGIN__H___ #define ___NSIS_PLUGIN__H___ #ifdef __cplusplus extern "C" { #endif #include "api.h" #include "nsis_tchar.h" #pragma comment(lib, "pluginapi.lib") #ifdef _countof #define COUNTOF _countof #else #define COUNTOF(a) (sizeof(a)/sizeof(a[0])) #endif #ifndef NSISCALL # define NSISCALL __stdcall #endif typedef struct _stack_t stack_t; extern unsigned int g_stringsize; // length of strings used in the current NSIS installer (in ANSI or Unicode characters) enum { INST_0, // $0 INST_1, // $1 INST_2, // $2 INST_3, // $3 INST_4, // $4 INST_5, // $5 INST_6, // $6 INST_7, // $7 INST_8, // $8 INST_9, // $9 INST_R0, // $R0 INST_R1, // $R1 INST_R2, // $R2 INST_R3, // $R3 INST_R4, // $R4 INST_R5, // $R5 INST_R6, // $R6 INST_R7, // $R7 INST_R8, // $R8 INST_R9, // $R9 INST_CMDLINE, // $CMDLINE INST_INSTDIR, // $INSTDIR INST_OUTDIR, // $OUTDIR INST_EXEDIR, // $EXEDIR INST_LANG, // $LANGUAGE __INST_LAST }; // The following macro or function must be called at the beginning of every NSIS entrypoint provided by your plugin! #define EXDLL_INIT() ExDLL_Init(hwndParent, string_size, stacktop, (char*)variables) void NSISCALL ExDLL_Init(HWND hwndParent, unsigned int string_size, stack_t **stacktop, char *variables); // pass the arguments from your entrypoint /* TCHAR is a generic type defined as 'wchar_t' or 'char' depending if you are compiling with UNICODE defined or not. For portability, use TCHAR as your character type. You can then choose the type of compilation that suits you best or provide both variant of your plugin. Ex: if you want your plugin to work under Windows 9x, you might want to compile as ANSI because Unicode API won't be available on the target computer. On the contrary, if you need to support Unicode for multi-language compatibility, you might want to compile your plugin as UNICODE. In any case, if you use this plugin API, both variants of your plugin will be compatible with both the ANSI *and* Unicode version of NSIS. This plugin API will do the work of converting ANSI/Unicode strings as required, as well as truncation if the length of strings differ (ending \0 included) ===== NSIS GENERIC API ===== popstring(str) : pop a string off NSIS stack. str must be defined as: TCHAR str[maxlen] popstringn(str,maxlen) : same, but str can be a pointer to a buffer of maxlen TCHARs return 0 on success, 1 on empty stack. pushstring(str) : push a string onto NSIS stack. peekstring(stkpos,str) : copy a string from NSIS stack. str must be defined as: TCHAR str[maxlen] peekstringn(stkpos,str,maxlen) : same, but str can be a pointer to a buffer of maxlen TCHARs stkpos is the position of the string to copy from the stack (0 for stack top) return 0 on success, 1 if stack does not contain enough entries getuservariable(varnum,str) : retrieve the value of a standard NSIS variable. str must be defined as: TCHAR str[maxlen] getuservariablen(varnum,str,maxlen) : same, but str can be a pointer to a buffer of maxlen TCHARs use the INST_* enum to choose which variable setuservariable(varnum,str) : change the value of a standard NSIS variable use the INST_* enum to choose which variable myatoi(str) : convert a string to a signed integer (supports "-" and "0x" prefixes) myatou(str) : convert a string to an unsigned integer (supports only decimal digits) myatoi_or(str) : same as myatoi, but you can 'OR' several binary values using the '|' character (ex: "1|4|8" returns 13) */ int NSISCALL popint(); // pop an integer off NSIS stack int NSISCALL popint_or(); // pop an integer with support for or'ing (ex: "1|4|8") void NSISCALL pushint(int value); // push an integer onto NSIS stack //========================== // generic redirection based on your ANSI/UNICODE compilation variant #ifdef _UNICODE #define popstring(str) PopStringW(str,COUNTOF(str)) #define popstringn PopStringW #define pushstring PushStringW #define peekstring(stkpos,str) PeekStringW(str,COUNTOF(str)) #define peekstringn PeekStringW #define getuservariable(varnum,str) GetUserVariableW(varnum,str,COUNTOF(str)) #define getuservariablen GetUserVariableW #define setuservariable SetUserVariableW #define myatoi myatoiW #define myatou myatouW #define myatoi_or myatoi_orW #else // ANSI defs: #define popstring(str) PopStringA(str,COUNTOF(str)) #define popstringn PopStringA #define pushstring PushStringA #define peekstring(stkpos,str) PeekStringA(str,COUNTOF(str)) #define peekstringn PeekStringA #define getuservariable(varnum,str) GetUserVariableA(varnum,str,COUNTOF(str)) #define getuservariablen GetUserVariableA #define setuservariable SetUserVariableA #define myatoi myatoiA #define myatou myatouA #define myatoi_or myatoi_orA #endif // use preferably the above generic TCHAR-compatible macros rather than the following prototypes int NSISCALL PopStringA(char *str, int maxlen); // 0 on success, 1 on empty stack void NSISCALL PushStringA(const char *str); int NSISCALL PeekStringA(int stkpos, char *str, int maxlen); // 0 on success, 1 on error void NSISCALL GetUserVariableA(const int varnum, char* str, int maxlen); void NSISCALL SetUserVariableA(const int varnum, const char *str); int NSISCALL myatoiA(const char *str); // converts a string to an integer unsigned NSISCALL myatouA(const char *str); // converts a string to an unsigned integer, decimal only int NSISCALL myatoi_orA(const char *str); // with support for or'ing (2|4|8) int NSISCALL PopStringW(wchar_t *str, int maxlen); // 0 on success, 1 on empty stack void NSISCALL PushStringW(const wchar_t *str); int NSISCALL PeekStringW(int stkpos, wchar_t *str, int maxlen); // 0 on success, 1 on error void NSISCALL GetUserVariableW(const int varnum, wchar_t* str, int maxlen); void NSISCALL SetUserVariableW(const int varnum, const wchar_t *str); int NSISCALL myatoiW(const wchar_t *str); // converts a string to an integer unsigned NSISCALL myatouW(const wchar_t *str); // converts a string to an unsigned integer, decimal only int NSISCALL myatoi_orW(const wchar_t *str); // with support for or'ing (2|4|8) #ifdef __cplusplus } #endif #endif//!___NSIS_PLUGIN__H___ |
From: Wizou <sou...@wi...> - 2010-06-09 16:16:57
|
I'm making the Unicode version of MakeNsis able to generate both ANSI & Unicode installers So we don't have to release two variant of NSIS and we can have everybody use only the Unicode version once and for all It's almost complete already.. This is what I have done so far : * For compatibility, Unicode NSIS supports ANSI scripts file, including langage-dependent codepaged LangString * I've add a UnicodeInstaller on/off keyword. * NSIS_UNICODE & NSIS_CHAR_SIZE defines are automatically adjusted depending on UnicodeInstaller * When establishing the list of plugins available, if plugins Sample.dll and SampleW.dll is found, it will consider SampleW to be the Unicode variant of Sample, and use it if it generates a Unicode installer, mapping Sample::function calls to SampleW::function . (The script author can still decide to explicitely call SampleW::functions) * When determining which Stub to use, makensis adds a 'W' suffix for Unicode installers (i.e : lzmaW is the Unicode variant of the lzma stub) * I've added a InstallOptionsW::make_unicode function (specific to the Unicode variant of InstallOptions) to convert automatically the .INI files (standard ones or ones provided by the user) to Unicode, so that WriteINIStr can write Unicode captions in it And it works great ! I've verified that when generating an ANSI installer, the bytes are exactly identical to what ANSI NSIS generates. This is what I plan to improve : * Instead of UnicodeInstaller keyword, we could use a TargetMinimalOS <major.minor> so that the script author can tell NSIS what API of Windows the installer will be allowed to use. o If <major.minor> is 5.0 or more (= Windows 2000 or more recent), a Unicode installer will be generated o This is a more generic approach than UnicodeInstaller o The stub suffix could then become this major.minor instead of 'W' (like lzma.5.0) o This way we can create stubs that take advantage of specific versions of Windows Also, we will need to change SConstruct so that it builds Plugins and the Stub in BOTH ANSI & Unicode (with specific names as described above) I have a very small understanding of Scons, so if someone could help me with that, it would be nice. |
From: Wizou <sou...@wi...> - 2010-06-09 16:11:54
|
I'm done with the first stage of the Unicode port. As you might have seen, it was not just a dumb merge from Jim Park sources.. I made a lot of improvements and fixes over Jim Park version. Anyway, the current state is that you can compile NSIS sources either as ANSI, or as Unicode using *scons dist UNICODE=yes *Stubs & plugins will be compiled as Unicode as well. As for the scripts, the Unicode version should be completely compatible with Jim Park's version. The next stages are : * Make the Unicode version of MakeNsis able to generate both ANSI & Unicode installers o So we don't have to release two variant of NSIS and we can have everybody use only the Unicode version once and for all * Provide a Plugin API transparently compatible with both ANSI & Unicode installers o So plugin developers can choose to compile their plugins as ANSI and/or Unicode, and the plugin layer automatically converts if there is an ANSI/Unicode mismatch between the installer and the plugin I will detail these stages in the following 2 mails... (so don't start the debate yet) |
From: Wizou <sou...@wi...> - 2010-06-09 13:54:35
|
We will use this mailing-list to discuss issues and progress about current developments in NSIS sources. |