Unicode

[Afrow UK]

How about VS 2010 Express?

Stu

[mzd]

Logging support for Unicode version

Hello,

Thank you for this port. I am interested in enableing logging using LogSet and then logging using LogText. It seems that the Unicode distributions don't turn on logging. The non-unicode distributions have a "special build" for makenisis which has logging enabled. Is there a similar "special build" with logging enabled for the unicode port?

Thanks,

mzd

[mrphantuan]

@Wizou: If you check my BgWorker plugin, you can see that I'm checking for kernel32::lstrcatW in the import table.

I also have some sample code in there that checks $pluginsdir, but like you said, you don't know the offset, so it has to use IsBadReadPtr() and there could be false positives.

Unfortunately, it turns out that writing hybrid plugins is a huge pain in the ass, and I can't recommend doing it on anything except very simple plugins





_______________

[ADMIN EDIT]
Warning: Spam(?) links removed!

[Wizou]

@mrphantuan: I don't know which post you are referring to exactly..
However, regarding hybrid ANSI/Unicode plugins, I have changed my mind and consider it now also a bad idea to try to create such plugins.
And so I don't plan anymore on committing a plugin API that would work transparently with ANSI & Unicode.
It is just simpler for plugin author to build 2 separate DLL variant, one for ANSI, one for Unicode.

And my recommendation for compatibility with Unicode NSIS automatic plugin variant detection, is to name the ANSI version "MyPlugin.dll" and the Unicode version "MyPluginW.dll" and offer them in the same folder.

[Anders]

@mrphantuan: I don't know which post you are referring to exactly..

I believe that is something I posted, why he posted it now, I have no idea.

And yes, a single dll for both versions is possible, but just to much work in practice, just use TCHAR and compile two versions...

[mzd]

Logging support for unicode version

Hello All,

I appears to me that all queries regarding logging support in the unicode port are being ignored. So, here goes again: is there any support for logging using LogSet in the unicode port. I have not yet understood the motivation behind turning off such a basic feature in any scripting language and especially in an install tool.

Thanks,

-mzd

[Afrow UK]

It is turned off because it adds extra overhead to the installer. You'll have wait for kichik or someone with greater knowledge of the internals of NSIS to explain why such a feature cannot be toggled dynamically at installer compile time though. Perhaps when logging was implemented the developers didn't think of allowing dynamic enabling, or that the amount of work required was unnecessary. Sometimes using C compile time directives (#if ... #endif) with separate builds of a product is much simpler. Now that the code base is so large it'd probably be a lot of work to change now.

Edit: When the next version of NSIS is released which is Unicode, you will have a logging build then (http://nsis.sf.net/Special_Builds). For now you will just have to rebuild. You just need to install a few things to build; nothing that will cost you anything.

Stu

[mzd]

@afrowuk.

Appreciate the response. Rebuild is an option, but not for me, since I don't own the build tools. The NSIS distribution is shared with other products and I am not at liberty to replace it with a custom build. It needs to be a published release ( a published special build distribution is ok ).

You mentioned that the next version of NSIS will be unicode enabled. Is that 2.47+?
Any insights in to the timeframe? Anyway, these are queries for the general NSIS Discussion forum.

Thanks,

-mzd

[CrushBug]

Go, go, NSIS Unicode version!

[DrO]

It needs to be a published release ( a published special build distribution is ok ).

as this unicode build isn't really an official version then it's not too surprising no logging version was offered and would assume that any 'official' unicode versions would have a logging version providing along with the large string version (unless plans, etc have changed in that respect).

You mentioned that the next version of NSIS will be unicode enabled. Is that 2.47+? Any insights in to the timeframe?

it looks like it'd be 2.50 based on what's in cvs / help docs though i guess that might change and i think the timeframe is when it's done and ready. as work keeps starting / stopping on it, things seem to be taking longer than i guess it was hoped to have been.

-daz

[Anders]

it looks like it'd be 2.50 based on what's in cvs / help docs...

I think that number was just a placeholder used by the fork

[pabs]

status?

Whats the status of the Unicode support in SVN?

Actually, what is the status of SVN itself, right now I can't even seem to build makensis from SVN on Linux, it complains about tchar.h being missing.

[jimpark]

mzd, sorry about not replying to this forum earlier. For some reason, my auto notification to a new message got lost. I just uploaded a logging version for you. You should see it in the download section of www.scratchpaper.com.

[Anders]

Whats the status of the Unicode support in SVN?

Actually, what is the status of SVN itself, right now I can't even seem to build makensis from SVN on Linux, it complains about tchar.h being missing.

Nobody has touched the unicode stuff in a while, don't get your hopes up about this ever getting fixed. (You might be able to compile with VS2005+, otherwise you are out of luck)

[MSG]

So, I guess it's unlikely that there will ever be a new version of NSIS, then?