Well, you might be surprised to find that adding the function did not grow System.dll by a single byte. The code section grows in some increments and it just fits nicely into the space available. And if you really want to fuss over bytes, if you compare my version of the ANSI System.dll, it's actually 512 bytes smaller. And the Unicode version is the same size as the official one.
Unicode
573 posts
Auto conversion of text encodings:
Here's basically what the Unicode NSIS does as far as auto-encoding/decoding of text types.
Here's basically what the Unicode NSIS does as far as auto-encoding/decoding of text types.
- If the file has no BOM in the beginning, it assumes it's an ANSI text file. (It will probably use the system codepage to convert it internally to UTF-16LE -- but I'm not sure about this. It may just strip out anything beyond ASCII and replace them with '?').
- If the file starts with a 16 bit encoding of the BOM (the usual kind 0xFEFF), it will treat the file as a UTF-16 file and correct it for endianness, internally storing everything as UTF-16LE.
- If the file starts with an 8 bit encoding of the BOM (0xEF 0xBB 0xBF), then it treats the file as a UTF-8 file and not an ANSI file. So those who desire to store their scripts in UTF-8, it's fine as long as it starts with a UTF-8 BOM. I understand that it's not usual for UTF-8 files to have a BOM, but since in the Windows world ANSI/ASCII files are more prevalent than UTF-8, this is what I chose. If people want UTF-8 to be the default, I'm open to that. Just let me know what you opinion is. Incidentally, notepad.exe, when saving files as UTF-8 will add a BOM to the start of the file for you.
The way I would prefer codepage detection to work is like this:
BOM Present: Use the corresponding encoding/codepage.
No BOM present: Check to see if the file can be fully parsed as UTF-8 (that is, no invalid byte sequences exist). If this succeeds, then it is very safe to assume that the file is indeed UTF-8. If it fails, fall back to ANSI/system codepage. Although we could, at least in theory, try to figure out UTF-16/UTF-32 without a BOM, due to the nature of the files, I suggest not doing so (since they are exceedingly rare, unlike BOM-less UTF-8).
To use this information efficiently, MakeNSISW should be able to perform this check (not only the actual MakeNSIS command-line compiler), and the command-line compiler should have a parameter to tell it the codepage in advance (or, at the very least, a parameter that tells it to skip the "valid UTF-8" check if no BOM is present). The parameter would probably be a good idea anyway, as it would more easily allow for a "Always assume UTF-8 if encoding unknown" option in MakeNSISW.
BOM Present: Use the corresponding encoding/codepage.
No BOM present: Check to see if the file can be fully parsed as UTF-8 (that is, no invalid byte sequences exist). If this succeeds, then it is very safe to assume that the file is indeed UTF-8. If it fails, fall back to ANSI/system codepage. Although we could, at least in theory, try to figure out UTF-16/UTF-32 without a BOM, due to the nature of the files, I suggest not doing so (since they are exceedingly rare, unlike BOM-less UTF-8).
To use this information efficiently, MakeNSISW should be able to perform this check (not only the actual MakeNSIS command-line compiler), and the command-line compiler should have a parameter to tell it the codepage in advance (or, at the very least, a parameter that tells it to skip the "valid UTF-8" check if no BOM is present). The parameter would probably be a good idea anyway, as it would more easily allow for a "Always assume UTF-8 if encoding unknown" option in MakeNSISW.
Well, there is no BOM for ANSI. There never has been and never will be. Basically, what we can do is make Unicode NSIS never work with ANSI with the exception of ASCII only scripts. If there is no BOM, assume UTF-8. If there is a BOM, assume UTF-16. This is the only other option in my mind.
Older unix tools might not support BOM for UTF-8, but that's not our problem 😉
If you really want UTF-8 without BOM, maybe makensis could check the first line for a comment like #NSIS: encoding=UTF-8
If you really want UTF-8 without BOM, maybe makensis could check the first line for a comment like #NSIS: encoding=UTF-8
Well, my guess is, if they don't like putting 3 bytes in front of their file, they will like having to put "#NSIS: encoding=UTF-8" even less.
but the header is just ascii text that any editor can write, you don't need any special support
I think a lot of these guys are scripting their NSI files and so it's not a big deal to emit three bytes at the front. If they are writing their scripts via a text editor, they may be able to simply save as UTF-8 and it may embed the BOM for them (e.g. notepad.exe does). Or they may have a way to type hex codes: EF BB BF (decimal: 239 187 191). For example in vim, I just do this command:
Or paste this guy: 
And then I hit 'i' to insert text and type their ctrl-k b: ctrl-k o: ctrl-k m:. And there I have it.
:dig b: 239 o: 187 m: 191
Or paste this guy: 
Long post ahead...
That's why I prefer not having to choose between "allow ANSI, but require UTF-8 BOM" or "disallow ANSI, always assume UTF-8", instead getting the best of both worlds by checking for UTF-8 validity if there is room for doubt: it generates the highest possible amount of backward compatibility, while still allowing people to save their UTF-8 the same way they've always been doing (That doesn't mean we can't issues a warning or something if they use an ANSI file, but that's still a hell of a lot better than temporarily breaking all existing scripts by forcing a conversion). Yes, it requires a bit of extra work to read the file into memory and checking it before starting the compilation, but I think the value in that feature would be pretty great compared to the time it takes to develop it. (Of course, that's easy for me to say, since I'm not likely to be the one programming it. 😛 )
Forcing people to do this also means forcing them to change their usual editing routines beyond just having to select a different encoding - they need to know "does my editor add a BOM" (and how they can add it if it doesn't), and I think that could potentially put some people off from going with Unicode NSIS.
This sort of thing could be more useful if extended to allow specifying non-Unicode code pages, such as sjis or big5, in which case Unicode NSIS would convert from that particular codepage, since that would allow Unicode NSIS compilation of an ANSI script on a random system - but I'm not convinced this is a relevant feature for very many people.
Originally posted by jimparkWell, no, but there doesn't need to be. I've yet to encounter an ANSI file (with characters > 128) that could be mistaken for a BOM-less UTF-8 file, because the odds of an ANSI file not containing any invalid UTF-8 character sequences are astronomically low, due to the way UTF-8 works on a byte level: not only do all bytes > 128 have to be placed together, but all bytes in the range 128-192 must be after a valid lead byte (194-244), and there has to be a very specific amount of high bytes following - it can be expressed as a very simple state machine that checks each byte (worst case executions-wise is that the file is UTF-8, so we end up running through the entire file, but even so, that process shouldn't take more than a second).
Well, there is no BOM for ANSI. There never has been and never will be.
That's why I prefer not having to choose between "allow ANSI, but require UTF-8 BOM" or "disallow ANSI, always assume UTF-8", instead getting the best of both worlds by checking for UTF-8 validity if there is room for doubt: it generates the highest possible amount of backward compatibility, while still allowing people to save their UTF-8 the same way they've always been doing (That doesn't mean we can't issues a warning or something if they use an ANSI file, but that's still a hell of a lot better than temporarily breaking all existing scripts by forcing a conversion). Yes, it requires a bit of extra work to read the file into memory and checking it before starting the compilation, but I think the value in that feature would be pretty great compared to the time it takes to develop it. (Of course, that's easy for me to say, since I'm not likely to be the one programming it. 😛 )
Basically, what we can do is make Unicode NSIS never work with ANSI with the exception of ASCII only scripts.I'd certainly prefer this to not supporting BOM-less UTF-8 (partially because I no longer use Notepad for editing scripts, but gVim, and having to remember to add the BOM will be a pain - particularly since not getting these useless BOMs is one of the reasons I switched), but see above.
If there is no BOM, assume UTF-8. If there is a BOM, assume UTF-16.I assume you mean "If there is a UTF-16 BOM". 😉
This is the only other option in my mind.
Originally posted by AndersExcept NSIS can do cross-compilation on *NIX systems and, to the best of my knowledge, most *NIX editors don't place a BOM unless explicitly told to (the only advantage is for identification, and most Unicode-aware tools try UTF-8 anyway, so no real benefit is observed).
Older unix tools might not support BOM for UTF-8, but that's not our problem 😉
Forcing people to do this also means forcing them to change their usual editing routines beyond just having to select a different encoding - they need to know "does my editor add a BOM" (and how they can add it if it doesn't), and I think that could potentially put some people off from going with Unicode NSIS.
If you really want UTF-8 without BOM, maybe makensis could check the first line for a comment like #NSIS: encoding=UTF-8It's not really logical to have to force a Unicode-aware application to use Unicode like this. You don't have to use files with signatures for Notepad to recognize UTF-8, to give an example.
This sort of thing could be more useful if extended to allow specifying non-Unicode code pages, such as sjis or big5, in which case Unicode NSIS would convert from that particular codepage, since that would allow Unicode NSIS compilation of an ANSI script on a random system - but I'm not convinced this is a relevant feature for very many people.
Originally posted by jimparkJust a comment on this: check out :h bomb.
For example in vim, I just do this command: <snip>
Or paste this guy: If you use the same codepage as Jim, that is. 😉
Just a comment on this: check out :h bomb.Wow. I did not know that. Very cool. Vim rocks. Now, is there a universal font that is available in Vim that can work on a lot of different scripts? For example, I'd love to see Arial Unicode work for me but I can't seem to choose that font for my guifontwide setting. Is there a font like that out there that I can download and have it work for Vim or somehow get Arial Unicode to work?
If you use the same codepage as Jim, that is. 😉True but everyone should have Latin-1 as their codepage! What else could we possibly need? 😛
Originally posted by jimparkThe help file states that all GUI versions of Vim, with the sole exception of the GTK2 version (you might be able to compile a GTK2 version for yourself and use that, but even there), only allows monospaced fonts. Personally, since my editing is pretty much restricted to Danish, English and Japanese, I use MS Gothic: it contains all the characters I need (although not all of the non-CJK characters are particularly pretty). A Chinese font like SimHei would probably give better Kanji/Hanzi support, though, since the Chinese use a much larger set of characters (I haven't tested this, though...)
Wow. I did not know that. Very cool. Vim rocks. Now, is there a universal font that is available in Vim that can work on a lot of different scripts? For example, I'd love to see Arial Unicode work for me but I can't seem to choose that font for my guifontwide setting. Is there a font like that out there that I can download and have it work for Vim or somehow get Arial Unicode to work?
We're getting pretty off-topic, though, so let's try to get back to NSIS... 😞
Problem with non-Unicode InstallerOptions INI files
Another problem which we are facing in order to use Unicode NSIS in Mozilla is about InstallOptions INI files. We use WriteINIStr, which seems to write the INI file as ANSI and convert to a Windows codepage on the fly.
Is there any way to write Unicode INI files from within the Unicode NSIS, or any other similar effects? Without this, our custom installer pages will not benefit from being Unicode...
Thanks!
Ehsan
Another problem which we are facing in order to use Unicode NSIS in Mozilla is about InstallOptions INI files. We use WriteINIStr, which seems to write the INI file as ANSI and convert to a Windows codepage on the fly.
Is there any way to write Unicode INI files from within the Unicode NSIS, or any other similar effects? Without this, our custom installer pages will not benefit from being Unicode...
Thanks!
Ehsan
Your best bet is to move to nsDialogs
IIRC, NT will write unicode ini files if the .ini already has a UTF-16LE BOM
IIRC, NT will write unicode ini files if the .ini already has a UTF-16LE BOM
http://blogs.msdn.com/michkap/archiv...15/754992.aspx
..so I guess you can use the nsis FileOpen/FileWriteByte commands to write the unicode BOM before you use the ini functions
..so I guess you can use the nsis FileOpen/FileWriteByte commands to write the unicode BOM before you use the ini functions
Well, it actually wouldn't be too hard to support WriteINIStrUTF16LE. And after thinking about Pidgeot's idea, and taking a moment to write the ValidateUTF8 function myself, I think it's probably best to not require a UTF-8 BOM. I'm starting to see a potential for 2.42.2 already.
I wonder if I shouldn't just make the INI files it generates as UTF-16LE instead of creating a new function. I think Windows supports INI files as UTF-16LE with no problems.
I dug a little deeper about WriteINIStr and this is what I found.
WriteINIStr uses WritePrivateProfileString() in kernel32.lib. If you look at the documentation for this function it states: "If the file was created using Unicode characters, the function writes Unicode characters to the file. Otherwise, the function writes ANSI characters."
WriteINIStr uses WritePrivateProfileString() in kernel32.lib. If you look at the documentation for this function it states: "If the file was created using Unicode characters, the function writes Unicode characters to the file. Otherwise, the function writes ANSI characters."
did I not already say this?
You may have. This thread is long and my memory is short. Ah, I see your post now. I just missed it.
I've semi-secretly released a prototype to 2.42.2 which can read UTF-8 NSI files. It does not require a UTF-8 BOM. If it finds a BOM in the beginning of the file, it uses the BOM as a cue to how to read the file. If it does not find a BOM, it checks the file to see if it looks like a valid UTF-8 file. If it's valid UTF-8, the file is read as UTF-8 and internally converted to UTF-16LE so that it can call the Win32 API. If it does not have a BOM and it does not validate as UTF-8, then it is opened as ANSI. But if this latter thing happens, anything that is > 0x7f probably gets converted to question marks.
So basically this version of NSIS officially supports:
UTF-8
UTF-16LE
It may work with UTF-16BE with the BOM (I'm relying on Microsoft on this one). But it does not work with UTF-32 of any endian flavor. Not sure there's a big demand for it anyway.
Let me know if you run into any problems. If it looks solid, I will release it to the general public some time next week or so.
So basically this version of NSIS officially supports:
UTF-8
UTF-16LE
It may work with UTF-16BE with the BOM (I'm relying on Microsoft on this one). But it does not work with UTF-32 of any endian flavor. Not sure there's a big demand for it anyway.
Let me know if you run into any problems. If it looks solid, I will release it to the general public some time next week or so.
Now that it can use UTF-8, wouldn't it be best to use that everywhere instead of having ANSI and Unicode versions of almost every file? If so, please be sure to strip the BOM character from the beginning of each UTF-8 file.
${NSIS_CHAR_SIZE} sounds like a bad idea, nsis shouldn't assume any specific size for characters - each character in UTF-8 can be multiple bytes long and same for UTF-16, that can have characters that are more than two bytes long. Only UCS-2 and UTF-32 have constant-sized characters.
${NSIS_CHAR_SIZE} sounds like a bad idea, nsis shouldn't assume any specific size for characters - each character in UTF-8 can be multiple bytes long and same for UTF-16, that can have characters that are more than two bytes long. Only UCS-2 and UTF-32 have constant-sized characters.
you are missing the point with NSIS_CHAR_SIZE, some windows api structures have hardcoded buffer sizes (GetVersionEx etc.)
Pabs, NSIS_CHAR_SIZE is the internal char size representation. You absolutely need it. Unicode NSIS does NOT internally store things as UTF-8. It can read UTF-8 files but internally it works with strings as UTF-16LE which is the native Windows encoding of Unicode.
Also UTF-8 is not a superset of ANSI. UTF-8 is a superset of ASCII but as soon as you hit codepages, UTF-8 and ANSI are foreign to each other. So anything with localizations cannot be shared. But a lot of the NSH files and samples CAN be reduced. You still have to read the code very carefully to see if they are strictly the same. If it uses the System plugin, for example, the strings you allocate needs to be adjusted for Unicode vs. ANSI. Unicode should be double the width. They must call the appropriate API -- the wide versions vs. ANSI. They must use the right messages -- sometimes there are two messages with the same #macro but different values for ANSI and Unicode because one message ID returns ANSI string values while the other returns UTF-16LE values. Using things like System::StrAlloc, ${NSIS_CHAR_SIZE}, and ${NSIS_UNICODE} can help you write code that will port easily between the ANSI and Unicode NSIS but it will require quite a bit of care to make sure it is done right.
Here's an example where it's not so simple to share the same code for both Unicode and ANSI NSIS.
Albeit, if you do the basic stuff only in your installer, you probably won't see these kinds of problems and keeping your installer just UTF-8 may be quite doable. (If you don't have any localized strings in the NSI script and rely solely on the Language Files distributed by NSIS, then even non-Latin installer may be able to go this route.)
If you really want to give it a try, please feel free. One thing I've noted is that the further you stray from the trunk, the harder it is to merge the changes for each release.
BTW, I definitely appreciate any help I can get. So I do value your input (and enthusiasm).
Also UTF-8 is not a superset of ANSI. UTF-8 is a superset of ASCII but as soon as you hit codepages, UTF-8 and ANSI are foreign to each other. So anything with localizations cannot be shared. But a lot of the NSH files and samples CAN be reduced. You still have to read the code very carefully to see if they are strictly the same. If it uses the System plugin, for example, the strings you allocate needs to be adjusted for Unicode vs. ANSI. Unicode should be double the width. They must call the appropriate API -- the wide versions vs. ANSI. They must use the right messages -- sometimes there are two messages with the same #macro but different values for ANSI and Unicode because one message ID returns ANSI string values while the other returns UTF-16LE values. Using things like System::StrAlloc, ${NSIS_CHAR_SIZE}, and ${NSIS_UNICODE} can help you write code that will port easily between the ANSI and Unicode NSIS but it will require quite a bit of care to make sure it is done right.
Here's an example where it's not so simple to share the same code for both Unicode and ANSI NSIS.
Are you a developer who uses NSIS to distribute your application? Are you a Winamp plug-in developer who wants to use NSIS to distribute your plug-in? Have suggestions for other people like you? This is the place.
Albeit, if you do the basic stuff only in your installer, you probably won't see these kinds of problems and keeping your installer just UTF-8 may be quite doable. (If you don't have any localized strings in the NSI script and rely solely on the Language Files distributed by NSIS, then even non-Latin installer may be able to go this route.)
If you really want to give it a try, please feel free. One thing I've noted is that the further you stray from the trunk, the harder it is to merge the changes for each release.
BTW, I definitely appreciate any help I can get. So I do value your input (and enthusiasm).
OK, fair enough on the size thing.
Are there any changes that can be merged now? Perhaps the conversion of the plugins/makensisw/etc to TCHAR instead of char?
Is there a need to duplicate the .nsh, .nlf etc files? This creates a maintenance headache IMO.
For example, the Unicode/ANSI versions of COPYING and nsisconf.nsh are identical after conversion to UTF-8. Same for the following directories containing Unicode & ANSI versions: Contrib/zip2exe/ Contrib/InstallOptions/ Contrib/Splash/ Contrib/Banner/ Contrib/AdvSplash/ Contrib/BgImage/ Contrib/VPatch/ Contrib/Modern UI/ Contrib/MultiUser/ Contrib/UserInfo/ Contrib/StartMenu/ Contrib/nsDialogs/ Contrib/Modern UI 2/.
I think it would be best to have one version of them (encoded in UTF-8 for compatibility with legacy text editors and Unix tools).
The differences due to System::Call or structure/string sizes can be wrapped in !if ${NSIS_UNICODE} or similar.
makensis can be made to convert .nlf & .nsh strings to ANSI/UTF-16LE at runtime.
Not sure how to deal with the Contrib/UIs/ differences, presumably you could set the class to RichEdit20, use a define of some sort or makensis could set the class at installer creation time.
I think the differences in due to registry key names and stuff are gratuitous and not necessary.
Are there any changes that can be merged now? Perhaps the conversion of the plugins/makensisw/etc to TCHAR instead of char?
Is there a need to duplicate the .nsh, .nlf etc files? This creates a maintenance headache IMO.
For example, the Unicode/ANSI versions of COPYING and nsisconf.nsh are identical after conversion to UTF-8. Same for the following directories containing Unicode & ANSI versions: Contrib/zip2exe/ Contrib/InstallOptions/ Contrib/Splash/ Contrib/Banner/ Contrib/AdvSplash/ Contrib/BgImage/ Contrib/VPatch/ Contrib/Modern UI/ Contrib/MultiUser/ Contrib/UserInfo/ Contrib/StartMenu/ Contrib/nsDialogs/ Contrib/Modern UI 2/.
I think it would be best to have one version of them (encoded in UTF-8 for compatibility with legacy text editors and Unix tools).
The differences due to System::Call or structure/string sizes can be wrapped in !if ${NSIS_UNICODE} or similar.
makensis can be made to convert .nlf & .nsh strings to ANSI/UTF-16LE at runtime.
Not sure how to deal with the Contrib/UIs/ differences, presumably you could set the class to RichEdit20, use a define of some sort or makensis could set the class at installer creation time.
I think the differences in due to registry key names and stuff are gratuitous and not necessary.
I agree with you Pabs. I'd like to see that done as well. When they are the same, we should keep them the same. Only fork them if they need to be different like the Language Files.
One thing about the !if ${NSIS_UNICODE} checks are that I'm afraid it might unnecessarily make the scripts harder to read. I know I hate it when I see a lot of #ifdef's in the C/C++ code. Also, the !if ${NSIS_UNICODE} checks may bloat the resulting installer with extra code as well. I'm not sure I like that.
As for the NSIS source code, I'd still like to be able to generate both the Unicode and ANSI builds of NSIS until everyone decides that ANSI is dead. Then we can do what the guys at PortableApps are thinking [1] -- eventually, wrap up a final build of ANSI NSIS for those writing installers for legacy systems and continue on with Unicode only. 🙂
[1] http://portableapps.com/node/17291
One thing about the !if ${NSIS_UNICODE} checks are that I'm afraid it might unnecessarily make the scripts harder to read. I know I hate it when I see a lot of #ifdef's in the C/C++ code. Also, the !if ${NSIS_UNICODE} checks may bloat the resulting installer with extra code as well. I'm not sure I like that.
As for the NSIS source code, I'd still like to be able to generate both the Unicode and ANSI builds of NSIS until everyone decides that ANSI is dead. Then we can do what the guys at PortableApps are thinking [1] -- eventually, wrap up a final build of ANSI NSIS for those writing installers for legacy systems and continue on with Unicode only. 🙂
[1] http://portableapps.com/node/17291
I was under the impression that !if was an installer-build-time statement like #ifdef in C, if it isn't, I mean whatever is available for installer-build-time statement conditionals.
Looking at the documentation, !if and !ifdef are exactly what is needed; they are conditional compilation, the ignored bits don't end up in the executable.
There aren't that many differences between the Unicode and ANSI examples and include files in the Unicode NSIS for you to be worried about making them harder to read.
There aren't that many differences between the Unicode and ANSI examples and include files in the Unicode NSIS for you to be worried about making them harder to read.
UAC + Unicodebuilt
Hi
its my first post here 😉
Anders + jimpark
you did both a great job 😉
BUUUUUUUUUUUUUT
i use Anders UAC plugin together with your unicode nsis
with the ANSI build everything works
but in unicode mode...
during install for all users:
${UAC.RunElevatedAndProcessMessages}
only opens an adminpassworddialog at first run of the setup 🙁
if u start the setup again for all users u wont see that dialog anymore 🙁
next problem is:
if i call the uninstaller from the unicodebuild this line makes troubles:
${UAC.U.Elevate.AdminOnly} "${UNINSTALLER_NAME}"
error pops up:
unable to elevate, error 05536
hope u can help me 🙁
ty
Software:
OS: XP Pro
NSIS: 2.42.1 ANSI + UNICODE (jimpark)
UAC: v0.0.10a - 20081004 (Anders)
Hi
its my first post here 😉
Anders + jimpark
you did both a great job 😉
BUUUUUUUUUUUUUT
i use Anders UAC plugin together with your unicode nsis
with the ANSI build everything works
but in unicode mode...
during install for all users:
${UAC.RunElevatedAndProcessMessages}
only opens an adminpassworddialog at first run of the setup 🙁
if u start the setup again for all users u wont see that dialog anymore 🙁
next problem is:
if i call the uninstaller from the unicodebuild this line makes troubles:
${UAC.U.Elevate.AdminOnly} "${UNINSTALLER_NAME}"
error pops up:
unable to elevate, error 05536
hope u can help me 🙁
ty
Software:
OS: XP Pro
NSIS: 2.42.1 ANSI + UNICODE (jimpark)
UAC: v0.0.10a - 20081004 (Anders)
"if u start the setup again for all users u wont see that dialog anymore" does not make any sense, the UAC plugin does not save any state, so it should work the same every time. Can you explain what you mean by "for all users"?
Could you post a minimal example script with these problems?
Could you post a minimal example script with these problems?
Originally posted by Anders
"if u start the setup again for all users u wont see that dialog anymore" does not make any sense, the UAC plugin does not save any state, so it should work the same every time. Can you explain what you mean by "for all users"?
Could you post a minimal example script with these problems?
I took your UAC RealWorld example script
there u show a dialog where u can choose between single user and ALL USER installation
All user means -> NEED ADMIN RIGHTS
if a normal user choose that
the admin PWD dialog pops up
if i try this with ANSI build everything works
I can start the setup as often as i want and i get allways this ADMINPWD dialog
if i try the same script build with the UNICODE NSIS
the dialog will only be showen at first start 🙁
UAC::IsAdmin returns $0 >=1
if i run it as normal user!
thats the strange thing for the installation
maybe you can contact me in skype
ing30er
than i can show u my script