[Outdated] Unicode NSIS Portable 2.46 Development Test 5 (et al)

107 posts / 0 new

Topic locked

Last post

December 13, 2009 - 10:03am

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

[Outdated] Unicode NSIS Portable 2.46 Development Test 5 (et al)

Outdated: this has been released.

Application: Unicode NSIS
Category: Development
Description: Unicode NSIS is the Nullsoft Scriptable Installer System with unicode support packaged as a portable app. NSIS is the language used to write all of the launchers at PortableApps.com. Unicode NSIS contains the capabilities to deal with unicode utf-16LE.

Unicode NSIS Portable 2.46 & PortableApps.com InstallerU now have an official release !
(Unicode)NSIS Portable
PortableApps.com Installer

Unicode NSIS Portable 2.46 Development test 5 Online [960KB download / 8.88MB installed]
(MD5: 2162b7e0354b347321d4d12077cf9582)

PortableApps.com InstallerU 1.0.3 Development Test 3 [1.38MB download / 5.63MB installed]
(MD5: 58f1fedee25bf9b8f44b541ea3f0f889)

PortableApps.com AppCompactorU 1.1 Development test 1 [0.8MB download / 0.8MB installed] 2010/04/19
(MD5: c80bce11d2cb0e19bad688f832f8b790)

Release Notes for Unicode NSIS Portable 2.46:

Development Test 5 (2010-05-25):

features added:
Updated the Registry.nsh to include 'nsExec::ExecToStack reg.exe'

Development Test 4 (2010-05-24):

features added:
Updated the Registry plug-in
Updated launcher to PAL HG-tip 2010-05-24

bug fix:
This should fix the registry restore issues on Wine

Note:
To make full use of the new Registry plug-in you'll need to update PAL with the latest HG-tip

Development Test 3 (2010-05-15):

features added:
Updated Unicode NSIS to 2.46 (Binaries are identical with 2.46 rc 2)
Updated launcher to PAL HG-tip 2010-05-15

bug fix:
This should fix the launcher bug for vista / Windows 7
And I included my fix for TrimWhite.nsh

Development Test 2 (2010-04-20):

features added:
Updated Unicode NSIS to 2.46 rc2 & PAL beta 4
No more moving about of nsisconf.nsh, linking directly to the data\settings folder

Development Test 1 (2010-04-16):

features added:
Updated Unicode NSIS to 2.46 rc1

Release Notes for Unicode NSIS Portable 2.45.1:
Development Test 7 (2010-04-16):

features added:
Used latest PAL 2.0 beta 3
Include the new update of the registry plug-in what should fix an issue with XPsp2

Development Test 6 (2010-03-27):

features added:
Used latest PAL 2.0 beta 2, pulled of Development repository 2010-03-27
Added PortableApps.comLauncherCustom.nsh, to check if ansi NSIS Portable or a local makensisw.exe is running.

Notes:
NSIS Portable (ansi) is not checking if Unicode NSIS Portable or even makensisw.exe is running.
And due to the both NSIS packages using the same executable names, if run at the same time, each launcher will be waiting for them to both be ended !
So then the NSIS registry key won't get cleaned up on exit

Development Test 5 (2010-03-07):
Development Test 4 (2010-02-04):

features added:
Done away with all the alternative macros
Most standard used plugins are now included
~~Fully compatible, no need any more to modify your scripts from Ansi to unicode~~[edit:almost fully...]

Development Test 3 (2009-12-25):
Development Test 2 (2009-12-19):
Development Test 1 (2009-12-13): Initial release

Release Notes for PortableApps.comInstallerU 1.0.3:

Development Test 3 (2010-03-28):

features added:
converted the language files with the proper code-pages
converted the 'InstallerWizard.nsi' to utf-16 to deal with the '®' not showing
included the recompiled executable which shows the '®'

Development Test 2 (2010-02-27):

bugs fixed: The install paths are working. I updated all files in the 'nsis\include' folder, what fixed it.

Development Test 1 (2010-02-26): Initial release

features:
Converted all languages to UTF-16 LE, but there could be some mistakes as I couldn't verify them all !

known bugs:
The install path within the actual compiled installer is messed up!
NSISunz can not deal with wide-chars in the file path.(probably isn't a big issue thought)

The Unicode NSIS plug-ins List: (beta means: I recompiled and tested them)

TextFunc.nsh     (beta: TextFunc_2010_07_01.zip)
RealProgress     (beta: RealProgress.zip)Original source
nsisunz          (beta: NSISunzU.zip)Original source NsisUnzU can't handle foreign characters within the extraction/ZIP-file path !
Registry         (beta: RegistryU.zip)Original source this includes the new _RestoreKey function !
EnumINI          (beta: EnumINI.7z) Original source is included
NewTextReplace   (beta: NewTextReplace)Original source
EmbeddedLists    (solved: EmbeddedLists.zip)
newadvsplash     (solved: newadvsplashu.zip)Note: Play sound doesn't work, for now !
inetc            (solved: inetc-unicode.zip )
ExecDos          (solved: execdosunicode.zip)
FindProcDLL      (solved: FindProcDLL Unicode bin.zip)
md5dll           (solved: Md5dll.zip)
MoreInfo         (solved: MoreInfo.1.0.1.2.zip)translated into C by KJD (PerditionC)
DialogsEx        (solved: DialogEx for Unicode)
UAC              (solved: UAC plug-in)

A few important notes ! (Read the Unicode NSIS manual for more info)

The Unicode NSIS compiler reads all included scripts as utf-8, if it can't find a utf-16 bom. Overall this won't give major problems as most scripts just use latin characters, but specific symbols could get wrongly converted !
For the same reason it is strongly recommended to convert the EULA's to utf-16LE! Like that it will be more obvious if this EULA accidentally gets included into an ansi installer !

This does NOT count for the run-time commands.
'Read/WriteINIStr' depending on the existence of a utf-16le BOM, it will read/write as utf-16 or ANSI
'FileRead' will read as ANSI
'FileWrite' will write as ANSI
'FileReadUTF16LE' will read as utf-16
'FileWriteUTF16LE' will write as utf-16
${registry::StrToHex/HexToStr} are behaving differently then the ansi commands, probably I should include additional *UTF16LE commands soon, for compatibility !

For any 'system::call' commands you should just remove the A, the plug-in should call the right API (A / W):

System::Call 'kernel32::CreateMutexA(i 0, i 0, t "${NAME}") i .r1 ?e'
System::Call 'kernel32::CreateMutex(i 0, i 0, t "${NAME}") i .r1 ?e'

To keep your script compatible, when experiencing additional behavior differences between the two NSIS packages, use:
```
!ifdef NSIS_UNICODE
;Unicode NSIS script (in utf-8)
!else
;NSIS script (in ansi)
!endif
```

BTW: BOM (Byte Order Mark), the first few bytes of a file to identify the files encoding. UTF-16LE = FF, FE or as word FEFF

December 13, 2009 - 11:02am

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

Unicode NSIS

Please rename this to Unicode NSIS Portable and change all references of NSIS Unicode to Unicode NSIS (or for short versions, NSIS -> NSISu) as that's what it is.

What are those alternative instructions you mention? What are they there for? And I presume they should be in a <pre> block.

I think one of the things I'm most concerned about in upgrading our applications from NSIS to NSISu is the registry thing; we need to be able to convert REGEDIT4 files to the newer format; this should just be convert ANSI to UTF-8 and change REGEDIT4 to RegistryEditor v5.00 or whatever it is on the first line, but I imagine we'll need to do it (preferably in the installer I think - with the Unicode plugin or can NSISu do it itself?). We can't just make users lose their settings or worse also have their application not run properly the first time after upgrade for all registry-using applications.

Edit: also, the one thing we must all remember for forwards-compatibility is !ifdef NSIS_UNICODE (seems to me it'd also be useful to have something like this in the header (it'd be more useful in NSIS and NSISu themselves but it's not there, so ah well))

!ifdef NSIS_UNICODE
  !define UNICODE_AW W
!else
  !define UNICODE_AW A
!endif

Then you could just have System::Call 'Kernel32::SetEnvironmentVariable${UNICODE_AW}(t, t) i("USERPROFILE", "$SETTINGSDIRECTORY\UserProfile").n', System::Call 'kernel32::CreateMutex${UNICODE_AW}(i 0, i 0, t "$NAME") i .r1 ?e' etc. (I think I'll implement it in the launcher for simplicity of upgrade, it's also then only one minor change per active line rather than an !ifdef around each such line of System::Calliness.)

Also useful at times is that the 1024 character string limit is 8096 with NSISu.

Edit: actually it seems it's fine to just drop off the A or W on almost all functions (the ones that don't have A or W start with a lowercase character) and it'll resolve it to the correct one (we'll need to test it though).

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

December 13, 2009 - 12:01pm

(Reply to #2) #3

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Updated the main topic to Unicode NSIS....

but for the launcher I need some time, cause my internet connection is that bad. It already took me 2 times of failer and waiting ages to get this 1.9 MB uploaded.
Should I delete the link till it's fixed ?

Registry.nsh, Registry.dll, TextReplace.nsh & FindProcDLL.dll are missing in Unicode NSIS.
Myself I couldn't find any additional plugins for this on internet !
ReadEnvStr $APPLANGUAGE "PortableApps.com????" I just didn't get to work properly.

So I made some alternative scripts what do the same trick.

I think upgrading is a long way head, as a lot of Unicode NSIS plugins aren't available. But at least maybe this is a small start. My experience with this edition is that it uses mainly utf-16LE, so as well for the registry files.
There again, since you are worried about registry files, the way it is setup at the moment, the following line didn't have to be modified:

nsExec::ExecToStack `"$WINDIR\system32\reg.exe" import "$SETTINGSDIRECTORY\NSIS_portable.reg"`

I just tested it and the launcher does it already ! I compiled the script with execwait NSIS.exe deleted and just added a messagebox, launched it and when the launcher finished the file is saved/converted to Registry Editor v5.00 utf-16LE format.
[edit: converted from REGEDIT4 ANSI format to Registry Editor v5.00 utf-16LE format, I just copied the registry file from NSIS Portable over to Unicode NSIS Portable settings directory !]

Formerly Gringoloco
Windows XP Pro sp3 x32

December 13, 2009 - 12:11pm

(Reply to #3) #4

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

Languages inside platform

Good, I'm glad about the regsitry stuff.

What's not working with ReadEnvStr? Are you running it from inside the PortableApps.com Platform? PortableApps.comLang* are only set from inside the Platform (they'll be not set and thus an empty string in NSIS when run outside the Platform or some other special thing set up by the end user to do the same thing).

We'll see if Jim Park comments on the things you say are missing... I'll see if I can find an email address if he doesn't (I think he will notice it though, I guess he's got a Google Alert on as how he spotted the last thread discussing it).

Don't bother taking down the link in the meantime, it's just a name, the functionality won't be changing.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

December 13, 2009 - 12:42pm

(Reply to #4) #5

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Don't be that glad a bout the registry.

It is done really crud for now, epecially the registry::movekey instruction.
Cause I do not have any knowledge about coding dll's, I have just made some NSIS script what saves the key to a temp. file, then uses some kind of ReplaceInFile script, writes back the key to the registry and deletes the temp files.
So definitly I need some input to find more proper ways of doing this !

I have tested and test the ReadEnvStr over and over again. it does work (I think to remember) for getting the drive letter. For now, I made ${ReadEnvStr}, which reads the ini and language files from the PortableApps.com folder, which does the same trick.

All these issues I like to get developed in a better way, through this tread.

Ps.: Another failure with uploading ! I have to go to an internet cafe to do this.

[Edit:
By standard, (Unicode)NSIS has it's own basic registry instructions which I used, but they are just not sufficient enough. The problem I had with coding a registry::move script was, that there is only an instruction to read a value and search values and keys(EnumRegKey/Value). So the script had to got through all the separated values and subkeys to be able to move them all. It seems a simple code, but I gave up half way down and found the above mentioned solution]

Formerly Gringoloco
Windows XP Pro sp3 x32

December 13, 2009 - 12:39pm

(Reply to #5) #6

John T. Haller

Offline

Last seen: 3 hours 8 min ago

Joined: 2005-11-28 22:21

Plugins

A few of the plugins we use have been recompiled for NSIS Unicode. Most have not. We should start a topic with the full list and start working through them. I'd like to switch over the PA.c Installer, Backup Utility and AppCompactor to Unicode and then do the launchers for each app as we do new releases (which would require NSIS Portable switching to NSIS Unicode as well). For the launchers that do the registry, we'll need a solid way of switching from old to new registry files standardized as a simple function call we can include. I think this is a good beginning to the conversation and process.

Sometimes, the impossible can become possible, if you're awesome!

December 14, 2009 - 12:14am

(Reply to #6) #7

jimpark

Offline

Last seen: 13 years 5 months ago

Joined: 2009-12-07 21:51

RE: Plugins

Yes, a list should be made. I've noticed that most plugin writers have been pretty good about making a Unicode version when asked.

December 14, 2009 - 12:13am

(Reply to #7) #8

jimpark

Offline

Last seen: 13 years 5 months ago

Joined: 2009-12-07 21:51

TCHAR

Yes, it's mostly fine to remove the A or the W. It will resolve it fine. The only ones that currently have problems -- and we are looking into possible solutions -- are those that are kernel functions but mimic stdlib functions like strlen. These functions have non-A, non-W functions which are the same as the A functions -- I believe Microsoft did this for backward compatibility. Those are the only functions I've seen that have this issue.

The only other gotcha to look for are memory allocations and pointer manipulations with strings. Remember Unicode in Windows is UTF-16LE, i.e. 16-bits. So you should make use of the ${NSIS_CHAR_SIZE} macro which is 1 for ANSI and 2 for Unicode.

December 13, 2009 - 3:01pm

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Solution for registry::MoveKey !

We just have to make more use of Reg.exe (+parameters).
We can copy a key from any source to any target by:

nsExec::ExecToStack `"$WINDIR\system32\reg.exe" COPY "$R9" "$R8" /s`
Pop $R0 ;0=Succes / 1=Error
Pop $R1 ;This just gives some text saying succesfull or not

And then delete the key !
Have to test more, it seems to get 'stuck' when a target key already exists !

Downside is, that I expect these commands to not work on WIndows 98. But is really anybody still using that ???

Ps.: Internet cafe was closed (sunday evening)

Formerly Gringoloco
Windows XP Pro sp3 x32

December 13, 2009 - 3:06pm

(Reply to #9) #10

John T. Haller

Offline

Last seen: 3 hours 8 min ago

Joined: 2005-11-28 22:21

Some Issues

nsexec can not be used in anything we release. Two different major software firewall products have issues with it. It's better to avoid using reg.exe if at all possible as some PCs will have rights that disallow access to it. If unavoidable, the ExecDOS plugin can get around it.

Sometimes, the impossible can become possible, if you're awesome!

December 14, 2009 - 5:30am

(Reply to #10) #11

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Just against any mis understandings !

But isn't every Portable App (which uses the registry) of this site currently using nsexec & reg.exe to restore the key before launching the app ?

  RestoreTheKey:
    IfFileExists "$WINDIR\system32\reg.exe" "" RestoreTheKey9x
      nsExec::ExecToStack `"$WINDIR\system32\reg.exe" import "$SETTINGSDIRECTORY\${APPNAME}.reg"`

Formerly Gringoloco
Windows XP Pro sp3 x32

December 14, 2009 - 12:18am

(Reply to #11) #12

jimpark

Offline

Last seen: 13 years 5 months ago

Joined: 2009-12-07 21:51

registry API

How about simply using the windows API using the System plugin? For example: RegistryCopyTree() might be useful. It might be best to just write your own helper macros that use the Win32 API directly. That way you'll have one less plugin to worry about.

December 14, 2009 - 1:49am

(Reply to #12) #13

John T. Haller

Offline

Last seen: 3 hours 8 min ago

Joined: 2005-11-28 22:21

Good Point

That's a good point, Jim. Actually, it would make sense if we did a full set of macros that handle the same things as the registry plugin but use the Windows API. We can put it together and release it under BSD (unlike our usual GPL for our stuff) like we do for our other NSIS add-ons and post it to NSIS so that others can use it as well.

Sometimes, the impossible can become possible, if you're awesome!

December 14, 2009 - 12:10pm

(Reply to #13) #14

wraithdu

Offline

Last seen: 10 years 3 months ago

Joined: 2007-06-27 20:22

I'd be interested in playing

I'd be interested in playing around with that. We would need a list of what functions are needed first. Windows registry API is a PITA... however this method would make cooking in unicode support easier I think.

December 22, 2009 - 4:23am

(Reply to #14) #15

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Any ideas...

Do you have any ideas for the ${registry::CopyKey}, ${registry::MoveKey} & ${registry::SaveKey}?

I am modifying the following script by AxelMock, REG_MultiSZ.nsh !
To read / write individual values, slowly I am getting it work with all value types !

Hopefully in the end we could use it to copy/move whole trees ???

Formerly Gringoloco
Windows XP Pro sp3 x32

December 22, 2009 - 9:44am

(Reply to #15) #16

wraithdu

Offline

Last seen: 10 years 3 months ago

Joined: 2007-06-27 20:22

I know about all that stuff.

I know about all that stuff. I looked through the original source back when I was developing something similar for AutoIt. It's going to be a PITA in NSIS I think.

I'd like to see a list of what's needed / wanted for PApps before committing any time to this. For example, I doubt anyone uses the registry search functions in the registry plugin. And there a built-in registry functions that can be used for individual keys and such. So... what is really needed here? Just the copy / move / recursive stuff?

December 22, 2009 - 1:54pm

(Reply to #16) #17

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

For the moment...

${registry::MoveKey} and ${registry::SaveKey} are the most important !

As John mentioned, we shouldn't use any 'nsExec::ExecToStack' or 'reg.exe'!

nsexec can not be used in anything we release. Two different major software firewall products have issues with it. It's better to avoid using reg.exe if at all possible as some PCs will have rights that disallow access to it. If unavoidable, the ExecDOS plugin can get around it.

About ${registry::MoveKey}:
JimPark advised:

How about simply using the windows API using the System plugin? For example: RegistryCopyTree() might be useful. It might be best to just write your own helper macros that use the Win32 API directly. That way you'll have one less plugin to worry about.

But the information I found on internet says RegCopyTree only works for Vista and newer ???
For now I got it working by using 'SHCopyKey'. (see dev. test 2 registry.nsh source)
Till now, it does the job just as well as the original version of the Registry plugin. Both of them don't seem to copy values containing unicode data !
But I consider this a problem ! Anything compiled with Unicode NSIS should be able to deal with unicode registry keys/values !

About ${registry::SaveKey}:
Uses 'nsExec::ExecToStack reg.exe export' for now !
I just didn't have time to find another solution for this.
JimPark send us a link for a ExecDos unicode plugin, which I tried and works. But still John rather doesn't have us using reg.exe anyway.
Probably using 'system::call RegSaveKey' could do the job ? But as I said I didn't get around playing with it jet !

At the moment I made a script to read / write individual values. Not that they are needed by the standard PA launchers, but because I am learning to use the 'system::call reg***key' stuff and have the hope that I can combine the read & write functions to construct a proper way of copying whole registry trees ?!?!
I'll include the ${registry::Read} & ${registry::Write} soon, in the next dev.test. As I still have to thoroughly test & cleanup the script.

Formerly Gringoloco
Windows XP Pro sp3 x32

December 22, 2009 - 2:49pm

(Reply to #17) #18

wraithdu

Offline

Last seen: 10 years 3 months ago

Joined: 2007-06-27 20:22

Sounds like you don't need my

Sounds like you don't need my help for anything! You've got it covered. I don't think there a built-in function to export keys to file. You'll have to read the keys and write the correct format I think. I'll look into the source of the old registry plugin to see how he did it.

Use SHCopyKeyA (Ansi) or SHCopyKeyW (Unicode). The Ansi version of NSIS will call the Ansi function if not specifically told to do otherwise. The Unicode version of NSIS *should* call the Unicode version of the function.

December 22, 2009 - 3:03pm

(Reply to #18) #19

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

I've given the 'SHCopyKeyW' a try,

but it didn't change behavior !

Googling on the web I crossed some forums stating it doesn't work for unicoded values due to a Microsoft bug.

Anyway, as I got a bit more experience now, I will give it another go !

Formerly Gringoloco
Windows XP Pro sp3 x32

December 22, 2009 - 3:45pm

(Reply to #19) #20

wraithdu

Offline

Last seen: 10 years 3 months ago

Joined: 2007-06-27 20:22

Interesting. You might have

Interesting. You might have to do it manually then. According to Microsoft, the Reg functions will automatically convert between Ansi and Unicode for you. This is from RegGetValue:

If the data has the REG_SZ, REG_MULTI_SZ or REG_EXPAND_SZ type, and the ANSI version of this function is used (either by explicitly calling RegGetValueA or by not defining UNICODE before including the Windows.h file), this function converts the stored Unicode string to an ANSI string before copying it to the buffer pointed to by pvData.

I've written AutoIt recursive reg functions, it's not too hard. I'll have to refresh myself a little on NSIS and System calls. And it will definitely be a bit harder without the abstractions provided by an interpreted language like AutoIt. NSIS, unfortunately, does not really provide the required information in their readreg / writereg functions (like returning the value type and allowing you to specify a value type when writing).

December 25, 2009 - 11:44am

(Reply to #20) #21

jimpark

Offline

Last seen: 13 years 5 months ago

Joined: 2009-12-07 21:51

${NSIS_CHAR_SIZE}

I just took a look at the REG_MultiSZ.nsh script. This makes a lot of calls to the system. And not only that, it uses integer operations to work on pointers to internal buffers. In order to make this work with Unicode strings, we need to realize that all the IntOp calls that are trying to move a pointer forward or backward by a character needs to be do so by TWO bytes for Unicode and ONE byte for ANSI. To accomodate this, Unicode NSIS and ANSI NSIS built by me, have an NSIS_CHAR_SIZE macro which is 1 for ANSI and 2 for Unicode. Also, when allocating strings, always use StrAlloc because it will do the right thing for the string length.

So basically, make sure the pointer arithmetic is correct and you'll get it to work pretty well. That's pretty much the trickest part of the whole conversion.

December 26, 2009 - 5:20am

(Reply to #21) #22

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

I got it done, just updating the page !

Got the hang of it a bit!
Made my own script to copy keys, instead of using SHCopyKey !

The above info, I got to take in account for next update, but the way I got it done for now seems to work pretty well.

Thanx for your interest !

[EDIT :
For now all the script just assumes it will be compiled in Unicode NSNS,
The Read / Write macros, are made to use the IntOp * 2 for the text value types. I'm probably going to need the Read/Write for the SaveKey & RestoreKey macros, will have a go on this soon !

The CopyKey doesn't deal with this, it just reads the value-data into the buffer, then writes the buffer into the value in the target path !

I will have a look if and how I would implement NSIS_CHAR_SIZE, cause I'm not sure if this Registry.nsh is any use in th ANSI version of NSIS !

I have to have a look into what StrAlloc can do ( not much time these days, Christmas!)

Merry Christmas to you as well !]

Formerly Gringoloco
Windows XP Pro sp3 x32

December 15, 2009 - 3:29pm

#23

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

I found a registry.nsh what makes use of the system plugin.

I included a link in the main topic.

So far it looks like it will solve our main problem !

Formerly Gringoloco
Windows XP Pro sp3 x32

December 19, 2009 - 8:28am

#24

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Updated to dev. test 2

I have changed and added a lot to the registry.nsh script.

But really the 'system::call' stuff is all new to me, so it takes me time to get the hang of it all !

Formerly Gringoloco
Windows XP Pro sp3 x32

December 21, 2009 - 10:19am

#25

jimpark

Offline

Last seen: 13 years 5 months ago

Joined: 2009-12-07 21:51

FindProc & ExecDos

I found FindProc was one of those functions that was really useful so FindProc is built-in to Unicode NSIS. (Open the User Manual and search for "FindProc".) This works just like the FindProc plugin by Sunil Kamath. This has been there since day one.

The ExecDos plugin also has a Unicode variant: http://forums.winamp.com/showthread.php?threadid=181442

If there are bugs, you can emit concerns at the forum above and he can help you.

December 22, 2009 - 3:53am

(Reply to #25) #26

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Thanx

a lot Jim !

Formerly Gringoloco
Windows XP Pro sp3 x32

December 22, 2009 - 3:48pm

#27

wraithdu

Offline

Last seen: 10 years 3 months ago

Joined: 2007-06-27 20:22

Ya know, another option might

Ya know, another option might just be to recompile a unicode version of the Registry plugin... it might be easier than trying to reinvent the wheel in native NSIS.

December 23, 2009 - 12:44am

(Reply to #27) #28

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

If you could do that !!!

I'm just a newbie on computers and programing, and for now c or c++ are just a step to far for me. (that's what the plugins are written in, I believe)

I tried getting in contact to the author of the registry plugin about this, but no luck so far.
But if you could do this yourself, recompiling would be the ideal solution !

Formerly Gringoloco
Windows XP Pro sp3 x32

December 23, 2009 - 12:46am

(Reply to #28) #29

wraithdu

Offline

Last seen: 10 years 3 months ago

Joined: 2007-06-27 20:22

I'll be out of two until

I'll be out of two until after Christmas, but I'll have my laptop with me. If I get a chance to check it out I will, otherwise I'll get to it early next week.

December 23, 2009 - 1:49am

(Reply to #29) #30

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Still take in acount, that it should be able to .....

copy or move values containing unicode data.

I just tested the newest version (v3.6) of the registry plugin, and it doesn't.
Maybe cause it's being used in ANSI NSIS, but I consider this to be a bug. It has the potential to mess up the local registry this way !

As well I tried SHCopyKey again and added a 'W' after all the registry instructions, without any luck !

Both of the tests left the registry values full of question marks instead of the unicode text, after copying/moving the keys !

Formerly Gringoloco
Windows XP Pro sp3 x32

December 25, 2009 - 7:35pm

#31

BuddhaChu

Offline

Last seen: 6 years 10 months ago

Joined: 2006-11-18 10:26

Since I'm not an über c0der

Since I'm not an über c0der like you guys, I'll turn cheerleader and say, "Good work guys! Keep it up!"

Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!

December 26, 2009 - 2:21am

#32

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Testing !!!

Could people PLEASE test:

${Registry::MoveKey} or
${Registry::CopyKey}

In Vista, Windows 7 and 64 bit operating systems ???

There is a 'test.reg' in 'Source\AdditionalFiles', which consists all possible value types and unicode characters !

This because it's a whole new script, making lots of system calls !

Ps.: Windows 98, 2000 and Millennium edition tests are also welcome.

Formerly Gringoloco
Windows XP Pro sp3 x32

December 29, 2009 - 6:57am

#33

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

I've got quite a problem with SaveKey !

IT IS TO SLOW!

I've written a NSIS code, which saves a key just like the Registry Editor v5.00 format ! It reads every separate value through system::call and writes it to a file.

For the 7ZipPoratble.reg it takes about 2.2 seconds to save.
For REGEDIT4 this file contains 13KB,
but converted to Registry Editor v5.00 it's 26KB (2.2seconds!!!)

The main problem is that, except for REG_SZ, all value types are saved as hexadecimal, example:

[HKEY_CURRENT_USER\Software\Skype\PluginManager]
"PluginManagerDir"="D:\\PortableApps\\SkypePortable\\Skype\\Plugin Manager\\"
"Plugins Root"="D:\\PortableApps\\SkypePortable\\Data\\Skype\\Plugins"

[HKEY_CURRENT_USER\Software\Skype\ProtectedStorage]
"0"=hex:01,00,00,00,d0,8c,9d,df,01,15,d1,11,8c,7a,00,c0,4f,c2,97,eb,01,00,00,\
  00,a5,b7,b0,23,cf,e0,bf,49,9d,a7,6b,31,e1,c6,ca,29,00,00,00,00,02,00,00,00,\
  00,00,03,66,00,00,a8,00,00,00,10,00,00,00,7e,be,d5,1b,68,65,14,2c,7c,70,dc,\
  3b,dd,a9,d9,3a,00,00,00,00,04,80,00,00,a0,00,00,00,10,00,00,00,0b,64,ba,8f,\
  a2,c5,9f,0e,e4,90,2a,8b,c3,94,fc,ac,20,00,00,00,4d,11,18,3e,3d,d3,cf,20,2e,\
  0c,e9,44,b8,84,0c,ac,01,2b,4f,c5,f6,cf,d9,16,02,b9,e7,47,9d,75,25,72,14,00,\
  00,00,04,e6,a0,ac,fa,97,7f,cb,9f,a2,cb,e2,a8,b9,4c,c1,90,54,88,b5

The script needs a lot of time to make this format.

My idea is to use a new format(and new extention), just for portable apps, which saves these values in a faster way, for example:

[HKEY_CURRENT_USER\Software\Skype\PluginManager]
"PluginManagerDir"="D:\PortableApps\SkypePortable\Skype\Plugin Manager\"
"Plugins Root"="D:\PortableApps\SkypePortable\Data\Skype\Plugins"

[HKEY_CURRENT_USER\Software\Skype\ProtectedStorage]
"0"=hex:0100000d08c9ddf0115d1118c7a00c04fc297eb01000000a5b7b023cfe0bf499da76b31e1c6ca290000000002000000........

This good potentially be much faster, and I do not see a problem with this, since REG_SZ values basacilly keep the same format !
Ps.: I do not understand why .reg files have a double backslash in REG_SZ folder paths, they aren't written this way to the registry?

Let me know if anybody has a problem with this ?

Formerly Gringoloco
Windows XP Pro sp3 x32

December 30, 2009 - 12:10am

(Reply to #33) #34

BuddhaChu

Offline

Last seen: 6 years 10 months ago

Joined: 2006-11-18 10:26

I believe the double

I believe the double backslash is because the first one is the escaping character to tell the system the second slash should be taken as a literal slash.

Read under "Listing 2":

http://www.geekgirls.com/windows_registry03.htm

Cancer Survivors -- Remember the fight, celebrate the victory!
Help control the rugrat population -- have yourself spayed or neutered!

December 31, 2009 - 11:08pm

(Reply to #34) #35

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

\ = escape

The backslash is the escape character. I think you can have \r and \n but I've never tried it; so also you'd use \" to escape " in a value name. So, you must escape the \ as \\ (it's standard programming practice).

I say that you should just use a plugin - NSIS code is inherently slow and we'd really be better off with straight C for the whole launcher (but we're using NSIS, at the moment at least).

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

January 2, 2010 - 8:23am

(Reply to #35) #36

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Hopefully Wraithdu can help for this one !

or somebody else, who has knowledge about writing NSIS plugins.
I've tried contacting the developer of the registry plugin, but no reply !

For now I'm probably better off to leave it as it is. Executing reg.exe through the ExecDos plugin.
Any other instructions, like CopyKey/MoveKey, I consider being fast enough .

About writing a plugin, I'd like to learn, and had a look at the source of the registry plugin. The SaveKey part basically does the same as my NSIS script, just has to be modified to write wide chars. RestoreKey has to be rewritten, cause it just executes regedit.exe .

~~But I can't even get to recompile registry.dll . I'm using DevC++, but get a "[link error] undefined reference to 'WinMain@16'". Probably this has something to do with it being a .dll ?~~

[edit: got it to recompile, but modifying the code myself will probably take me months !]

Formerly Gringoloco
Windows XP Pro sp3 x32

December 30, 2009 - 7:28am

#37

nguyenlc

Offline

Last seen: 13 years 3 months ago

Joined: 2009-12-30 07:25

No show splash.jpg

Apps run but no splash. full plugin. Help me, thks alots

December 30, 2009 - 10:59am

(Reply to #37) #38

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Have a look at UnicodeNSISPortable.nsi

as an example, to modify your ANSI based script!

the splash plugins uses a slightly different command, and myself I just got it to work with .bmp files !

Formerly Gringoloco
Windows XP Pro sp3 x32

December 30, 2009 - 7:25pm

(Reply to #38) #39

nguyenlc

Offline

Last seen: 13 years 3 months ago

Joined: 2009-12-30 07:25

.bmp files

i don't work with .bmp files. I tested

UnicodeNSISPortable: ok
but
Notepad++Portable: bad

huhu.....

January 2, 2010 - 5:45am

(Reply to #39) #40

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

If you can get .jpg to work, I would be happy !

But as you can see in the source folder of UnicodeNSISPortable, it does use a .bmp file !

Just convert your .jpg to .bmp ! You can even just convert it using Paint.

Formerly Gringoloco
Windows XP Pro sp3 x32

January 16, 2010 - 5:23pm

#41

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

I should have done this a while ago.

But better late then never.

I believe the plugins mentioned on the top are the missing ones still needed by PA.c.
Not sure what the 'EmbeddedLists plugins' are ???

Anyway, I gave up on the idea to script this in NSIS, it's just to slow.
Therefor I've been learning some C, and it all doesn't seem that hard.

Had some experience on the newtextreplace plugin for ansi NSIS, and even got one function working of the registry plugin for unicode NSIS.

It's a (small) start !

Formerly Gringoloco
Windows XP Pro sp3 x32

January 19, 2010 - 8:24am

#42

Devo

Offline

Last seen: 1 year 3 days ago

Joined: 2007-09-04 14:55

Disable Splash

I just noticed that the ini doesn't have the line to disable the splash screen. If I add that line, the splash still shows up. It seem that the launcher doesn't have the ability to disable the splash.

Hopefully you get the last few plugins figured out, this will be perfect when PortableApps moves to unicode for its launchers.

January 21, 2010 - 7:08am

#43

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Added NewTextReplace.

My first plugin compiled for Unicode NSIS, published !

I'm quite far with doing the registry one. I got all the functions working (& tested) which we use in standard launchers. Just want to do some more testing for the other functions, but will send a link soon!

NewTextReplace doesn't make use of the 'TCHAR' stuff, cause that way it would break functionality for standard files. So I just made 2 separated sets of 'pop-' & 'pushstring'.

The registry plugin will be recompiled with making use of the 'TCHAR' stuff.

I will try to get in contact with JimPark this weekend, for additional advise about recompiling.

[edit: EnumIni recompiled, done some extensive testing so it should be fine]

Formerly Gringoloco
Windows XP Pro sp3 x32

January 21, 2010 - 11:32am

(Reply to #43) #44

wraithdu

Offline

Last seen: 10 years 3 months ago

Joined: 2007-06-27 20:22

Don't get confused / hung up

Don't get confused / hung up on char vs wchar_t vs TCHAR. TCHAR is a compile time only macro that uses either char or wchar_t based on whether the source is compiled with unicode support. Once compiled, TCHAR doesn't exist anymore.

January 21, 2010 - 1:16pm

(Reply to #44) #45

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Yes, I know !

I did a lot of investigation about all of it!
This is what you mean I believe:

#define _UNICODE
#define UNICODE

If I implement this TCHAR becomes, wchar_T. Otherwise it becomes char.
Like that the scripts could be compiled for either Unicode NSIS & Ansi NSIS !

The way I did the EnumINI plug-in, I used the TCHAR. The same way jimpark uses it. And the other stuff like _T("***") & sizeof(TCHAR).

Just I had a problem implementing this for NewTextReplace, as it destroyed functionality for doing the replace in ANSI & UTF-8 files. So instead I used WideCharToMultiByte() and reversed it just to use CreateFileW(). This is the only way I got NewTextReplace working for now. And it does the job as it should ! (At least in my testing it did)

Maybe, after I have more experience I can get it done using the TCHAR stuff.

[edit: Have a look at the source, if you got time]

Formerly Gringoloco
Windows XP Pro sp3 x32

January 22, 2010 - 12:10am

(Reply to #45) #46

wraithdu

Offline

Last seen: 10 years 3 months ago

Joined: 2007-06-27 20:22

That's cool. It wasn't clear

That's cool. It wasn't clear from your other comment you had it all straight. I'm not familiar with the source, but I could see where there could be issues reading and writing data to/from the file. You're correct, you need to use the proper versions of functions based on the file encoding.

However, and I'm just speculating here at the moment, ReadFile just reads binary data. It doesn't matter if the file is opened with CreateFileA or CreateFileW. It would be up to you how to interpret the data and how to write it back. So technically, you could open all files with CreateFileW then branch to ANSI/UTF-8/Unicode parsing/writing functions. I'm blabbering...

Carry on!

January 30, 2010 - 6:31pm

#47

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Registry plugin done !

Will update the package later, no time anymore today!

The bug for ${Registry::WriteExtra} only counts for use with REG_MULTI_SZ values.

As this isn't important for portable apps and I expect for the installer. Anyway probably there will be some additional moddifications to be made.

Ps.: As I tried to contact the specific plun-in developers, one has replied finally !
He will do the MD5dll plug-in this weekend !

[edit: Bug is fixed!]

Formerly Gringoloco
Windows XP Pro sp3 x32

January 24, 2010 - 10:01am

#48

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

NewAdvSplashU available!

By Takhir.
The launcher plugins are complete!

Also I done FindProcDll, so if you change the name of NewTextReplace.nsh to ReplaceInfileWithTextReplace.nsh , the launcher scripts should be compatible for ansi & unicode

Formerly Gringoloco
Windows XP Pro sp3 x32

February 4, 2010 - 5:43pm

#49

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Updated....

Formerly Gringoloco
Windows XP Pro sp3 x32

February 6, 2010 - 1:25pm

#50

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

I'm a bit confused here, it

I'm a bit confused here, it looks like some mod. has altered some of the list of plugins needed.
But I thought moreinfo (& md5dll) are needed for the installer, as I can see in the 'PortableApps.comInstaller' folder.
And the time plugin (which has just dissapeared some how) should be needed for the 'PortableApps.comUpdater'???

Anyway, md5dll plugin is added. Really seeing an end to this, now.

Nsisunz, is almost done!
Just 'moreinfo' is written in Delphi, so I won't be burning my hands on that one.

[Edit: Nsisunz added, just has a problem that 'zlib' isn't written for unicode, so it won't be possible to unzip files with odd characters in the name/path. But same seems to be for 'untgz' plugin which uses 'zlib' aswell ]

Formerly Gringoloco
Windows XP Pro sp3 x32

February 11, 2010 - 11:37am

#51

Devo

Offline

Last seen: 1 year 3 days ago

Joined: 2007-09-04 14:55

Something happened with the launcher

Setting DisableSplashScreen=true does nothing.

February 11, 2010 - 1:05pm

(Reply to #51) #52

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

This is because, the launcher

This is because, the launcher is the same script as of NSIS Portable. Which doesn't have this option as well.

I'm not developing the launcher, I just want to get all the plugins working properly !

Formerly Gringoloco
Windows XP Pro sp3 x32

February 11, 2010 - 1:09pm

(Reply to #52) #53

John T. Haller

Offline

Last seen: 3 hours 8 min ago

Joined: 2005-11-28 22:21

No Splash

NSIS doesn't have a splash screen. That thing that comes up is the NSIS menu that you then pick what you want to do (read docs, check out examples, compile something).

Sometimes, the impossible can become possible, if you're awesome!

February 11, 2010 - 1:17pm

(Reply to #53) #54

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Yes, but I added the splash,

Yes, but I added the splash, for last dev tests. As an example for people how to use the advsplash plugin.

Anyway, we are in need of some one having a look at MoreInfo plugin.
I believe it written in delphi. Any ideas ???

And yes I did try to contact the developer of the plugin, a while ago.

Formerly Gringoloco
Windows XP Pro sp3 x32

February 11, 2010 - 1:28pm

(Reply to #54) #55

Devo

Offline

Last seen: 1 year 3 days ago

Joined: 2007-09-04 14:55

I was actually talking about

I was actually talking about the Dev Test splash screen. The ini options in UnicodeNSISPortable.ini don't do anything.

March 2, 2010 - 11:20am

(Reply to #55) #56

Devo

Offline

Last seen: 1 year 3 days ago

Joined: 2007-09-04 14:55

I was looking at the code for

I was looking at the code for the launcher and there is a section in there to disable the splash screen, but it doesn't work properly. Maybe you could take a look at it and see if you can fix it. Either that or remove the splash screen since it is just a dev test anyways.

March 2, 2010 - 11:38am

(Reply to #56) #57

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Just use the NSISPortable.exe

Just use the NSISPortable.exe launcher instead, and rename it to UnicodeNSISPortable.exe

or comment out the following: (just as in the original launcher)

			;InitPluginsDir
			;File /oname=$PLUGINSDIR\splash.jpg "${NAME}.jpg"	
			;newadvsplash::show /NOUNLOAD 1500 0 0 -1 /L $PLUGINSDIR\splash.jpg

and recompile it.... (you do have to rename it first thought)

I'm really not intending to develop the launcher it self. But I should include the the dev.test splash as it's not an official release !

Formerly Gringoloco
Windows XP Pro sp3 x32

March 2, 2010 - 12:04pm

(Reply to #57) #58

Devo

Offline

Last seen: 1 year 3 days ago

Joined: 2007-09-04 14:55

Sorry for the long response

I understand what you're saying, and maybe it's because I like all my apps to be the same, but if it does become an official app (which it likely will since John wants to move towards unicode) either there needs to be a way to disable the splash or it needs to be removed.

I understand that the splash in the case is important to let people know that it is a dev test, but most people who download apps from the beta forum know what dev tests are and that they may contain bugs. These people probably don't need a splash to remind them of that each time they launch the app.

Sorry for being long winded, I just think it would be worthwhile to fix the launcher. Maybe a fix would be rather than commenting out the necessary code, set the default for DisableSplashScreen = true.

This way it would be disabled by default, but end users could enable the splash screen if they wanted to. The splash screen functionality would still be there, but could be toggled on and off just like all the other apps.

For the dev test DisableSplashScreen = true, but for the official release DisableSplashScreen = false.

I guess I just see no reason for the functionality to be completely removed.

February 18, 2010 - 4:22pm

#59

jimpark

Offline

Last seen: 13 years 5 months ago

Joined: 2009-12-07 21:51

Dropping off A and W

Yes, it's fine to drop off the A and W for most functions. The only ones that are trouble are those API where the function without the A or W actually resolves to a function. For example, lstrlen is such a function. The Unicode version is lstrlenW. The only functions like these are Windows API that are named just like the C standard library functions which aren't many. So as you said, if you see a function that is not camel-cased i.e. all lowercased, make sure to add the W for Unicode.

[Edit] I hadn't realized that I remarked on this before. There may be some changes coming which may even make this even more automatic. Sorry about the sudden case of amnesia and the repeated post. I'm glad to see this project making progress. Please let me know when it's all done and rolled out!

February 18, 2010 - 7:12pm

(Reply to #59) #60

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

But very few

I know you know this, but I'll restate it in this thread so we can make sure people realise it; it's (almost) only the C-style functions that may have a sans-A version as the ANSI function - viz, if it is lower case, check it up on MSDN.

In the PortableApps.com Launcher I've been dropping A in every instance of a System::Call (and successfully). The probability that you'll use a sans-A function in any of our coding is very low indeed.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

February 27, 2010 - 3:05am

#61

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

I posted the PortableApps.com

I posted the PortableApps.com Installer for unicode.
No modifications have been made to the actual script!

I done some small testing for the languages and online installers which is working as expected.

~~Just I could find the problem with the path, which the installer assumes you like to install your portable app.~~
[Edit:I think I fixed it, see main topic for details]

Formerly Gringoloco
Windows XP Pro sp3 x32

February 26, 2010 - 10:39pm

#62

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

No need to convert to UTF16-LE?

In your DT4 notes you've said "Fully compatible, no need any more to modify your scripts from Ansi to unicode". How does this work? Automatic execution of a2u on a copy or something, or something else?

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

February 27, 2010 - 3:27am

(Reply to #62) #63

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

a2u isn't needed in the first

a2u isn't needed in the first place. It's possible to compile any script with an ansi code-page. Unicode NSIS will look for a BOM, if it finds it, assumes the file is UTF-16, if it doesn't it assumes the file is UTF-8, which converts the same as an ansi file, as scripts are done in latin letters

And, for now there shouldn't be no more need to implement any:

!ifdef NSIS_UNICODE
!else
!endif

I'm trying to keep it that way

As well for the .reg files. The registry plugin uses regedit.exe to restore the .reg files(it has always used regedit.exe). So the .reg files are backwards- and forwards compatible(on my XP anyway), between the RegistryEditor v5.00 and the REGEDIT4 formats !

[edit: cleared up the a2u part]

Formerly Gringoloco
Windows XP Pro sp3 x32

February 27, 2010 - 4:02am

(Reply to #63) #64

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Another remark.... It doesn't

Another remark....

For the PortableApps.com InstallerU, it didn't seem to be flawless...
In 'PortableApps.comInstaller.nsi', the '®' in:

BrandingText "PortableApps.com - Your Digital Life, Anywhere®"

Didn't get through right, so I had to convert this script to UTF-16 LE.

As well, some how I had to use all .nsh files from Unicode NSIS in the 'nsis\include' folder. Which are in UTF-16. And it fixed the issue with finding the portableapps path within the compiled installer!

Last issue, trying to recompile PAL I got some problems, but I have to wait till you do away with SimpleSC plugin, before I can be sure what's wrong !

Formerly Gringoloco
Windows XP Pro sp3 x32

February 27, 2010 - 5:39am

(Reply to #64) #65

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

May work now

I just committed changes in PAL which should make it work better with NSISu; services are disabled, and plug-ins are separated into Plugins\A and Plugins\U depending on whether NSIS_UNICODE is defined or not. If you update your checkout of the repository you might even find it works (you'll get three warnings due to services being disabled).

I just tested it and found a problem with my use of !searchparse to get the version from appinfo.ini...

File '..\..\App\AppInfo\appinfo.ini' has no BOM but validates as UTF-8.
Opening '..\..\App\AppInfo\appinfo.ini' as UTF-8.
!searchparse: starting string "PackageVersion=" not found in file!
Error in script "V:\portableapps\launcher\Other\Source\PortableApps.comLauncher.nsi" on line 48 -- aborting creation process

For want of a better way to fix it (any ideas?) I put in /noerrors and fall back to 1.0.0.0.

Still can't compile though, but I'll get to that. Shouldn't your language files be UTF-16LE? I'm getting lots of warnings like this:

File 'Z:\home\chris\Downloads\portableapps\UnicodeNSISPortable\App\NSIS\Contrib\Language files\French.nlf' has a BOM marked as UTF-16LE.
Opening 'Z:\home\chris\Downloads\portableapps\UnicodeNSISPortable\App\NSIS\Contrib\Language files\French.nlf' as UTF-16LE.
File 'Languages\French.nsh' has no BOM and does not validate as UTF-8.

The reason it's failing to compile though is that it's just getting things wrong. I have a !ifmacrondef ${Segment}_${Hook}, and the compiler is evaluating both sides of the expression, both before and after the !else. And so it decides the macro Core_.onInit doesn't exist (!?), and yet it continues on and tries (and fails) to insert the macro. It's wacky. I'm giving up on it now before I get further confused

It's possible that the fact I'm using Wine has some bearing on the issue. If Unicode NSIS doesn't work properly in Wine it's evil and will cause me no end of trouble.

(Wait, something just occurred to me; all the files I've created since running gVim in Ubuntu will be ff=unix rather than ff=dos and thus LF rather than CR LF; I'll try making them all dos and see if that does anything.)

Edit: getting somewhere. !searchreplace is going crazy, utterly ruining a string whether the file is latin1 or UTF-16LE (with BOM). Can't do anything until !searchreplace is fixed (and also it'd be good if !searchparse had worked in appinfo.ini, an ANSI file).

Jim Park: could you please help fix !searchreplace?

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

February 27, 2010 - 7:00am

(Reply to #65) #66

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

!searchreplace will be

!searchreplace will be working if you remove the newlines out if the ini file ! No-matter it is ansi or utf-16, I think this problem is due to it being version 2.45 (but not sure anymore)

[Format]
Type=PortableApps.comFormat
Version=1.0
[Details]
Name=PortableApps.com Launcher
AppID=PortableApps.comLauncher
Publisher=PortableApps.com
Homepage=PortableApps.com/development
Category=Utilities
Description=The PortableApps.com Launcher is a universal launcher, configured by INI options, to make almost anything portable.
Language=Multilingual
[License]
Shareable=true
OpenSource=true
Freeware=true
CommercialUse=true
[Version]
PackageVersion=0.9.9.4
DisplayVersion=1.0 Alpha 4
[Control]
Icons=1
Start=PortableApps.comLauncher.exe

I will do testing for today, but I had the same errors on the segments, I had a feeling it was due to some plugins.
I will let you know!

About the languages, I can convert them and send them to you, but their is just no way I can check if japanese and chinese are done properly !

Formerly Gringoloco
Windows XP Pro sp3 x32

February 27, 2010 - 8:34am

(Reply to #66) #67

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Your 'warnings' about the

Your 'warnings' about the languages, they aren't really warnings. Unicode NSIS just tells you for every file if it did find a BOM, and on what way it will open the file. I even believe it internally converts it if it doesn't find a BOM, but just from utf-8 to utf-16. But anyway, here is an example folder with the PortableApps.comLauncher languages converted UTF-16, for when you want to implement them. Just they should be over looked by some Japanese/Chinese person !
And I've included an appinfo.ini file what works (for me anyway)
http://www.mediafire.com/?dfngdyiywyo

I'm also getting the error: 'macro named "Core_.onInit" not found!' For for both compilers !
That's new, didn't have that in Alpha 4

But, for Unicode NSIS compiling, I need to use 'UAC v0.0.11d' instead of 'UAC v0.2.2b'. Otherwise it fails before the 'Core_.onInit' error:

Opening 'Segments\RefreshShellIcons.nsh' as UTF-8.
!macro: macro named "敒牦獥卨敨汬捉湯sSegmentUnload" already found!
!include: error in script: "Segments\RefreshShellIcons.nsh" on line 9

This last error is just really odd, are you using the UAC plugin for 'RefreshShellIcons.nsh' ???

I'm afraid I can't really help you for the script, cause for me it's just too complicated to follow the code.

Ps.: How do I download the files from the 'Mercurial repositories'. I ended up copy/pasting, but had to delete all the line-number by hand! (never want to do that again)

Formerly Gringoloco
Windows XP Pro sp3 x32

February 28, 2010 - 4:47pm

(Reply to #67) #68

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

The problem with those weird

The problem with those weird characters is that !searchreplace is broken; it's nothing to do with the UAC plug-in

!searchparse gets something from a file. This isn't working with an ANSI file appinfo.ini; I suspect it's just not coping with multi-byte characters properly.
!searchreplace does find/replace in a string. I tried taking it down to the simplest form replacing a in bc with d (clearly no matches) and it ends up with a badly broken string. Multi-byte character problems again, I suspect.

As for updating the hg repo, hg pull and then hg up.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

March 25, 2010 - 6:11am

#69

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

New location

As per our discussion I created an FTP account for you and sent you the details. I also downloaded, uploaded and updated the links for your two main packages on this page, UNP and PAIU, so now they're direct links to downloads on gringoloco.portableapps.chrismorgan.info. Hope you can manage to upload other things there with your connection.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

March 26, 2010 - 1:05pm

#70

scriptdaemon

Offline

Last seen: 3 years 10 months ago

Joined: 2008-10-10 17:40

Not sure if someone already

Not sure if someone already mentioned this, or if this is an otherwise known bug, but when using the unicode build of the installer, if there is an EULA.txt in the source folder, some things don't look correct when it is displayed to the user during the install process:

“Revo Uninstaller” -> �Revo Uninstaller�
USER’S -> USER�S

March 26, 2010 - 1:13pm

(Reply to #70) #71

John T. Haller

Offline

Last seen: 3 hours 8 min ago

Joined: 2005-11-28 22:21

Encode It

If EULA.txt is Ansi, I don't think it will show up right. So be sure it is set for Unicode. You can do this in Notepad++ Portable, for example.

Sometimes, the impossible can become possible, if you're awesome!

March 26, 2010 - 1:19pm

(Reply to #71) #72

scriptdaemon

Offline

Last seen: 3 years 10 months ago

Joined: 2008-10-10 17:40

Forgot to mention: I did do

Forgot to mention: I did do that. Same results with ANSI and UTF-8.

EDIT: lol. I selected the wrong option, oops. I did "Encode in UTF-8" instead of "Convert to UTF-8."

March 27, 2010 - 11:01am

#73

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

EmbeddedLists plug-in is

EmbeddedLists plug-in is re-compiled for Unicode NSIS

I tested it with all the example files, no issues !

Note: The original, so also this, version apparently has a bug what will be fixed any time soon by AfroUK.

http://forums.winamp.com/showthread.php?t=311949

Formerly Gringoloco
Windows XP Pro sp3 x32

March 27, 2010 - 11:17am

(Reply to #73) #74

John T. Haller

Offline

Last seen: 3 hours 8 min ago

Joined: 2005-11-28 22:21

Nice! Another Bug

Nice! That's awesome news. I'll get working on incorporating it.

Once bug... Disabling sort by columns in options doesn't work. The columns are always click-sortable if you have sort enabled by one of the columns. This bug is present in the original Ansi version as well. Any idea where the author accepts bugs?

Sometimes, the impossible can become possible, if you're awesome!

March 27, 2010 - 7:51pm

(Reply to #74) #75

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

There doesn't seem to be a

There doesn't seem to be a dedicated forum topic for this specific plugin !

Probably it's best to comment to the same (recent) forum topic I linked to just above.

Formerly Gringoloco
Windows XP Pro sp3 x32

March 29, 2010 - 11:10pm

#76

vf2nsr

Offline

Last seen: 6 years 11 months ago

Joined: 2010-02-13 17:10

A delay in Download of Code?

Is it possible to delay the time out longer in the paf installer for this, I missed my firewall warning asking me to allow the download which caused the first install to abort, after I allowed the second attempt at install worked without a hitch? Just a thought

“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss

March 29, 2010 - 11:24pm

(Reply to #76) #77

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

Not possible

It's in the plug-in used by the PortableApps.com Installer. It can't handle things like that at all.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

April 15, 2010 - 1:58pm

(Reply to #77) #78

xuesheng

Offline

Last seen: 1 year 4 months ago

Joined: 2008-03-21 15:34

I found that adding

I found that adding /TIMEOUT=20000 to the inetc call in my installer gave users enough time to respond to firewall prompts.

April 14, 2010 - 4:13pm

#79

jimpark

Offline

Last seen: 13 years 5 months ago

Joined: 2009-12-07 21:51

2.46 Unicode NSIS RC1 Test Request

There is a 2.46 Unicode NSIS RC1 that's been released for testing. It looks pretty good and it might stand as is for 2.46 but I wanted to make sure PortableApps works fine with the release first. Can someone take a quick look to make sure it's okay?

http://code.google.com/p/unsis/downloads/list

April 14, 2010 - 5:04pm

(Reply to #79) #80

John T. Haller

Offline

Last seen: 3 hours 8 min ago

Joined: 2005-11-28 22:21

nice

I'll give it a workout with some launchers and installers within a few hours.

Do you know offhand if this fixes the !searchparse issue that Chris Morgan was having?

Sometimes, the impossible can become possible, if you're awesome!

April 14, 2010 - 6:49pm

(Reply to #80) #81

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

!searchparse

Details of the !searchparse issue: reading from files with blank lines (such as our appinfo.ini files) failed. There was also an issue with !searchreplace being completely broken due I believe to a multibyte-offset problem. I don't have time to test these today but if no-one's reported about it I'll try to check them tomorrow or Saturday.

I managed to work around using !searchreplace completely fairly easily, and replaced !searchparse by the Generator, using ReadINIStr and then passing it with /D. So neither of these issues affect us any more with the Launcher. (But they'd still be good fixed.)

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

April 15, 2010 - 7:59am

(Reply to #81) #82

Chris Morgan

Offline

Last seen: 8 years 3 months ago

Joined: 2007-04-15 21:08

${NSISDIR}

I just remembered another problem I've found with Unicode NSIS Portable. It's to do with how its components find itself.

In Wine, makensisw.exe doesn't work at all - it can never find makensis.exe (CWD is irrelevant).
In Windows, running makensis.exe from my set up of Command Prompt Portable causes a really weird problem: it somehow (I have been utterly unable to work out where it's getting it from) finds D:\PortableApps\NSISPortable\App\NSIS and sets ${NSISDIR} to that, instead of D:\PortableApps\UnicodeNSISPortable\App\NSIS. As you can imagine, this breaks things utterly. With PAL it makes compiling the Generator fail, as it then can't find a compatible version of RealProgress. With PAL itself though at one point it did compile something, which sat guzzling the CPU and never doing anything...
The strange thing with this issue is that it only affects it when running from my Command Prompt Portable installation. (I tried removing the relevant doskey macros, no change. I haven't dug as deeply as I could though.) Running it from PAP it works, running it from cmd works, but running it from cmd via PAP with my startup script it's hopelessly broken... (I've never had any such issues with NSIS Portable). And I did try completely removing NSISu and starting fresh.

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

April 16, 2010 - 1:45pm

#83

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Update with the new registry

Update with the new registry plug-in.

Personally I'm experiencing a problem with a secondary portable instance of Unicode NSIS Portable, which leaves HKCU\Software\NSIS behind.

Please let me know if you experience the same !

Formerly Gringoloco
Windows XP Pro sp3 x32

April 16, 2010 - 3:19pm

#84

scriptdaemon

Offline

Last seen: 3 years 10 months ago

Joined: 2008-10-10 17:40

This has probably been discussed before, but

Why exactly is NSISu using an online installer?

April 16, 2010 - 3:33pm

(Reply to #84) #85

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

No particular reason, besides

No particular reason, besides it's easier for me to upload and initially I done it to test the downloading & extracting of the unicode installer !

Formerly Gringoloco
Windows XP Pro sp3 x32

April 16, 2010 - 3:43pm

(Reply to #85) #86

scriptdaemon

Offline

Last seen: 3 years 10 months ago

Joined: 2008-10-10 17:40

Ah.

So when it's officially released, it'll be included with the installer?

April 16, 2010 - 4:15pm

(Reply to #86) #87

Mark Sikkema

Offline

Last seen: 12 years 1 week ago

Joined: 2009-07-20 14:55

Yes, I would think so ! Any

Yes, I would think so !

Any change in confirming the HKCU\Software\NSIS registry being left behind on a secondary portable instance ?

Formerly Gringoloco
Windows XP Pro sp3 x32

April 16, 2010 - 4:25pm

(Reply to #87) #88

scriptdaemon

Offline

Last seen: 3 years 10 months ago

Joined: 2008-10-10 17:40

Nope, sorry. =\

April 18, 2010 - 10:16pm

#89

jimpark

Offline

Last seen: 13 years 5 months ago

Joined: 2009-12-07 21:51

!searchreplace

I will look into the problem with !searchreplace. I'm looking at the code and I think I know where the bug is. I'll make sure this issue is resolved before 2.46 is released.

If you see anything else, please submit an issue or e-mail me.

April 18, 2010 - 10:18pm

(Reply to #89) #90

John T. Haller

Offline

Last seen: 3 hours 8 min ago

Joined: 2005-11-28 22:21

Thanks, ETA?

Thanks for this Jim. We're not using it anymore, but I'm sure someone is somewhere.

Also, do you have any sense of an ETA on this now? We're gonna be switching over our launchers, installers, utilities, updater, etc to Unicode NSIS this week and I was wondering which version we should be targeting. I'm tempted to use the RC for now, honestly, if we have no issues with it.

Sometimes, the impossible can become possible, if you're awesome!

April 19, 2010 - 4:33pm

(Reply to #90) #91

jimpark

Offline

Last seen: 13 years 5 months ago

Joined: 2009-12-07 21:51

2.46 RC2 Released

Well, I just released RC2 thinking you guys might still need it. It's been pretty quiet as far as bug reports go so I'll wait for you guys to do some cursory testing before I do a 2.46 release. If no changes are needed, 2.46 RC2 might just be renamed to the final release. But I would suggest that RC2 be used instead of RC1.

You are here

[Outdated] Unicode NSIS Portable 2.46 Development Test 5 (et al)

Pages

Please Help Support Us

Translate Page

Latest Releases & News

Join Our Community

Partner with PortableApps.com

About PortableApps.com

You are here

[Outdated] Unicode NSIS Portable 2.46 Development Test 5 (et al)

Pages

Please Help Support Us

Translate Page

User login

Latest Releases & News

Join Our Community

Partner with PortableApps.com

About PortableApps.com