Registered: Jun 2002
From: N/A

@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

__________________
IntOp $PostCount $PostCount + 1

Quick Link | Report this post to a moderator | IP: Logged

Registered: Sep 2007
From:

For the next release, I plan on adding to pluginapi.h:

// True if NSIS is built with Unicode support.
bool NSISCALL IsUnicodeNSIS();

Also, Olivier noted that you could use IsWindowUnicode(hwnd). But this may not work on silent installers.

However, I would still encourage that the plugin writers use TCHARs or a strategy similar to it and compile and link with the right Unicode declarations and definitions. I know there is a temptation to try to generate a single binary that could work on both the ANSI and the Unicode NSIS variants but that seems a bit dangerous to me.

__________________
Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.

Quick Link | Report this post to a moderator | IP: Logged

Registered: Aug 2007
From: Paris, France

@Anders: IsBadReadPtr won't help you here as it will be valid memory range (.bss variables area), just you're not checking a valid Unicode 2nd byte.
Checking 'lstrcatW' import from main module is however a good idea

@jim park: I still wonder how you would create such a IsUnicodeNSIS, unless you pass special exec_flags_t value from NSIS to the DLL


If we have such a way for the DLL to detect the version of NSIS, I'm thinking about creating a new pluginapi.h/pluginapi.lib that could transparently convert variables and stack from ANSI or Unicode to the plugins choice depending on whether it is called from Unicode-NSIS or not
This would make plugins creator's life easier.

__________________
My NSIS plug-ins: http://wizou.fr

Quick Link | Report this post to a moderator | IP: Logged

Registered: Mar 2009
From:

@jimpark: What about turning on/off "messages about including files" ? NSIS Unicode is great tool and I ask You to add this option, please.

Quick Link | Report this post to a moderator | IP: Logged

Registered: Jun 2002
From: N/A

Noooooooooo, we don't need a IsUnicodeNSIS() function or any kind of pluginapi helpers to do both.

It has already been done with the unicode layer for win9x, just use that.

I'm with Jim on this, plugin devs should use TCHAR and compile two versions. There is also my CallAnsiPlugin plugin for older stuff with no source.

@Wizou: well, I'm sure it can be done without checking the import table. The IsBadReadPtr usage was just a big hack and I never finished that type of detection.

__________________
IntOp $PostCount $PostCount + 1

Quick Link | Report this post to a moderator | IP: Logged

Registered: Sep 2007
From:

@Wizou: That's a good point. It's very difficult to write an IsUnicodeNSIS(). The only thing I could do is try validating the string (if anything) to see if it's good UTF16LE. Look in validateunicode.cpp which is in Source. You'll see a class there that can validate UTF16LE/BE as well as UTF8.

@Anders: I agree with you in that this API, even if accurate, is a bad idea. I'm pulling IsUnicodeNSIS() from pluginapi.h. It will NOT be in the next release.

__________________
Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.

Quick Link | Report this post to a moderator | IP: Logged

Registered: Oct 2009
From: Germany

Does someone know why I'm always getting empty unicode files when I'm using:

code:
unicode::FileUnicode2Ansi "${_HDDS_countFile}" "${_HDDS_countFile}_tmp" AUTO
Pop $R0
${If} "$R0" != 0
  # error handling
${EndIf}

Last edited by ChocJunkie on 11-10-2009 at 03:10 PM

Quick Link | Report this post to a moderator | IP: Logged

Registered: Jun 2002
From: N/A

If we are going to have any chance of a merge, the examples and header files need to be 100% the same, meaning that both the current A and U builds need some changes:

*The ansi version needs to change its handling of &wXX so that XX is a count of characters and not bytes (and update the docs) (The unicode version already has this fixed)

*The unicode system plugin needs to default to the W version of functions when autodetecting (foo >> fooW and not fooA)


To reduce the NSIS_MAX_STRLEN confusion, we should probably make it really clear in the docs that NSIS_MAX_STRLEN is a count of TCHAR's (Or maybe even rename it). We should also add a predefine for the count of bytes, I suggest we name it NSIS_MAX_STRCB

Both versions currently fail this little test script

__________________
IntOp $PostCount $PostCount + 1

Quick Link | Report this post to a moderator | IP: Logged

Registered: Sep 2007
From:

quote:

---

Originally posted by Anders
*The unicode system plugin needs to default to the W version of functions when autodetecting (foo >> fooW and not fooA)

---

code:

::CreateFile(...);

code:

#ifdef UNICODE
#define CreateFile  CreateFileW
#else
#define CreateFile  CreateFileA
#endif // !UNICODE

__________________
Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.

Quick Link | Report this post to a moderator | IP: Logged

Registered: Aug 2007
From: Paris, France

For your information, I'm starting to merge Unicode port of NSIS version into NSIS repository.

I will try to take the most of what has been discussed here into account.
However my plan is first to make it the most transparent possible for the user and the plug-ins developer.

__________________
My NSIS plug-ins: http://wizou.fr

Quick Link | Report this post to a moderator | IP: Logged

Registered: Sep 2007
From:

That's excellent news! Is there an ETA on when this will be complete?

__________________
Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.

Quick Link | Report this post to a moderator | IP: Logged

Registered: Aug 2007
From: Paris, France

No ETA yet.. I just started the SVN branch I will work on..
I guess the first merge/port will be easy especially as your work will greatly simplify the effort.
But then there will be a phase of discussion/arbitration/tweaking/testing as to what should be the user & developer experience regarding this new version.
I will keep you updated on my progress.

__________________
My NSIS plug-ins: http://wizou.fr

Quick Link | Report this post to a moderator | IP: Logged

Registered: Jun 2002
From: N/A

well, if we don't look for "functionW" before "function", we are going to need some kind of define that is "A" or "W" and maybe a list of API's where it is required. IMHO that is the wrong approach, and the reverse is needed, they need to look for the char type specific version first unless a (new) option is provided in the system call

__________________
IntOp $PostCount $PostCount + 1

Quick Link | Report this post to a moderator | IP: Logged

Registered: Aug 2007
From: Paris, France

my opinion is to check whether the parameter type contains a "t", then we know we are facing an API which has two variant..
and only in this case, we start checking for 'functionW' or 'functionA' variant first.. if entrypoint is not found, then we check for 'function'

__________________
My NSIS plug-ins: http://wizou.fr

Last edited by Wizou on 11-17-2009 at 10:16 AM

Quick Link | Report this post to a moderator | IP: Logged

Registered: Sep 2007
From:

@Wizou: the problem with that check is that if the user calls CreateFile() with 'w' in the Unicode version of NSIS, that's not wrong either. CreateFile should still resolve to CreateFileW.

Like I said, the only problems I've seen are the string functions that mimic standard library calls. There aren't that many and they are all lowercased like C standard library functions. If the person has programmed C at all, functions like strlen should jump out as taking char* and not wchar_t*. So it should raise a warning flag and the user should realize he should put a W at the end.

__________________
Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.

Quick Link | Report this post to a moderator | IP: Logged

Registered: Jun 2002
From: N/A

Windows programmers don't think about that, I'm so used to just calling lstr*, I don't think about the char type. Whats wrong by defaulting to the W versions and only falling back if W does not exists or a option to disable it was set?

Do you have a single example of a function that needs to be called without W when running as unicode (meaning foo should be called with WCHAR* even if fooW exists)?

__________________
IntOp $PostCount $PostCount + 1

Quick Link | Report this post to a moderator | IP: Logged

Registered: Aug 2007
From: Paris, France

quote:

---

Originally posted by jimpark
@Wizou: the problem with that check is that if the user calls CreateFile() with 'w' in the Unicode version of NSIS, that's not wrong either. CreateFile should still resolve to CreateFileW.

---

__________________
My NSIS plug-ins: http://wizou.fr

Last edited by Wizou on 11-17-2009 at 03:17 PM

Quick Link | Report this post to a moderator | IP: Logged

Registered: Jun 2002
From: N/A

Yeah, I agree with Wizou

__________________
IntOp $PostCount $PostCount + 1

Quick Link | Report this post to a moderator | IP: Logged

Registered: Sep 2007
From:

That would be nice if everyone did that. But remember, when people read the Windows documentation, what do they read? The documentation says to use CreateFile(). It does not say to use CreateFileW() for Unicode. We're just lucky that Microsoft has been largely consistent with these W and A suffixes.

If you write C/C++, you will also be calling CreateFile() with wchar_t*. Because that's what the documentation tells you to do. You just have to make sure you define some macro like _UNICODE or UNICODE. If you read the fine print you get the "is implemented as CreateFileW() and CreateFileA()" but no example tells you to use these directly.

And remember, there's really no bearing on type-safety here. I can use any old function signature and as long as the name of the function matches, the System plugin will push your arguments, whatever types they may be, onto the stack and happily call the function. The arguments can be totally wrong types and have bogus values. So it's not even useful in that respects either.

__________________
Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.

Quick Link | Report this post to a moderator | IP: Logged

Registered: Jan 2002
From: Kolding, Denmark

To the best of my knowledge, there IS no CreateFile-function, only CreateFileA and CreateFileW. CreateFile is #defined to CreateFileA or CreateFileW in WinBase.h, depending on whether or not UNICODE is defined.

As such, if the Sytem plug-in allows you to just write CreateFile, then it must either already be checking for *A, or it has some predefined mappings.

Quick Link | Report this post to a moderator | IP: Logged

Registered: Sep 2007
From:

quote:

---

Originally posted by Anders
Windows programmers don't think about that, I'm so used to just calling lstr*, I don't think about the char type. Whats wrong by defaulting to the W versions and only falling back if W does not exists or a option to disable it was set?

Do you have a single example of a function that needs to be called without W when running as unicode (meaning foo should be called with WCHAR* even if fooW exists)?

---

__________________
Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.

Quick Link | Report this post to a moderator | IP: Logged

Registered: Sep 2007
From:

@Pidgeot: Yes, you are right. There is no CreateFile() function in the library you link to. There's a macro. But the documentation tells you to call CreateFile().

__________________
Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.

Quick Link | Report this post to a moderator | IP: Logged

Registered: Jun 2002
From: N/A

quote:

---

Originally posted by jimpark
That would be nice if everyone did that. But remember, when people read the Windows documentation, what do they read? The documentation says to use CreateFile(). It does not say to use CreateFileW() for Unicode. We're just lucky that Microsoft has been largely consistent with these W and A suffixes.

If you write C/C++, you will also be calling CreateFile() with wchar_t*. Because that's what the documentation tells you to do. You just have to make sure you define some macro like _UNICODE or UNICODE. If you read the fine print you get the "is implemented as CreateFileW() and CreateFileA()" but no example tells you to use these directly.

---

__________________
IntOp $PostCount $PostCount + 1

Quick Link | Report this post to a moderator | IP: Logged

Registered: Sep 2007
From:

@Anders: What you say is true. But if you are coding a Unicode only app, you will notice that people use wchar_t with CreateFile() and not CreateFileW().

Either way, I don't like the system to think it's smarter than the programmer.

__________________
Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.

Quick Link | Report this post to a moderator | IP: Logged

Registered: Jun 2002
From: N/A

but we sort of have to be, in windows/C world, this stuff happens at compile time, for us it happens at runtime, and so, t is our clue that the user trusts us and expects us to the right thing

(OT: Why don't you two hang out in IRC, this discussion would go a lot faster that way)

__________________
IntOp $PostCount $PostCount + 1

Quick Link | Report this post to a moderator | IP: Logged

Registered: Sep 2007
From:

Unfortunately, my access to the internet is very limited. So I can't IRC. This is also what keeps me from being able to work on the NSIS repository directly (and hence that's why I haven't created a branch in the repository for my stuff here). So once the group actually takes my code into the repository, I can't work on it anymore. Anyway, that's my situation and will be for the foreseeable future.

__________________
Unicode NSIS advocate -- http://www.scratchpaper.com for latest build and source.

Quick Link | Report this post to a moderator | IP: Logged

Registered: Jun 2002
From: N/A

Well, there are HTTP IRC "clients" that work just fine, try mibbit

__________________
IntOp $PostCount $PostCount + 1

Quick Link | Report this post to a moderator | IP: Logged

Registered: Aug 2007
From: Paris, France

You are both right...
The user doesn't want to care or know about CreateFileA or W, he will just use CreateFile... and parameter type 't', and there will be no problem.

I think the few users that care to write their own System::Call (rather than copy/pasting them from somewhere) should know about TCHAR/LPTSTR and A/W variant.

__________________
My NSIS plug-ins: http://wizou.fr

Quick Link | Report this post to a moderator | IP: Logged