Mr N

NSIS is an open source installer builder which works under Windows and Unix. One of the problems with using macros/push/pop is that the quotes can conflict with each other. To avoid this I’ve found that standardising your quoting is important in order to avoid problems especially with nested calls. The example below shows how a perfectly reasonable piece of NSIS code might unexpectedly not compile. Can you spot the mistake?

Name "NsExec Function Test"
OutFile "nsexecTest.exe"

!macro doMessage WHAT
  MessageBox MB_OK '${WHAT}'
!macroend
!define doMessage '!insertmacro doMessage' 

Section
  ${doMessage} "hello it's me"
SectionEnd

The doMessage is a macro which is substituted and not called, so the translations go thus:

${doMessage} “hello it’s me”

!insertmacro doMessage “hello it’s me”

MessageBox MB_OK ‘hello it’s me’

As you can see we have an invalid call to MessageBox because there are unmatched quotes. In order to overcome this problem the caller must know the nature of the quotes inside the code which is being used, and delimit the quote in such a way that it survives the invocation. In this case we must add an additional backslash which itself must be delimited to survive the first set of parsing. The section must be changed to:

Section
  ${doMessage} "hello it$\'s me"
SectionEnd

so that by the time it gets translated we have:

MessageBox MB_OK ‘hello it\’s me’

Most people use double quotes to surround text because it allows you to use single quotes more easily. However, there is a big problem if you are using NSIS and Windows. Bill in all his wisdom created DOS which has the most ridiculously complicated syntax when it comes to handling quotes [try typing cmd /? if you don’t believed me!]. Then he said you could have spaces in file names which you can only delimit by wrapping in double quotes. Anyway what the hell does this have to do with anything? Glad you asked. In order to create an NSIS macro that leads to the ability to run a program under Windows you need to preserve double quotes all the way to the end, which means you can’t use double quotes as a parameter wrapper. So consider this code:

Name "NsExec Function Test"
OutFile "nsexecTest.exe"

!macro doAction WHAT
  nsexec::exectolog '${WHAT}'
!macroend
!define doAction'!insertmacro doAction' 

Section
  ${doAction} '"c:\fc.exe" "c:\some file1" "c:\some file2" > "c:\some file.out"'
SectionEnd

If you standardise your delivery quotes to always be a single quote and wrap out going calls in single quotes you should be able to avoid a lot of the headaches associated with un-terminated quotes.

I wanted to set up my new Nokia N900 to switch between networks depending on where I was. The mobile operator’s 3G network is a billed limited network with a top speed of about 3Mb/s, whereas at home my broadband is always on, has a top network speed of 50Mbps and is already paid for. The plan is to set up the phone to use the mobile operator’s 3G network when I was wandering the cursed earth but when I got home (or to a mates house) it would automatically connect me to the local free access point.

1. From the main application window, select Settings.
2. Scroll down to the Connectivity section and click Internet Connections.
3. Use the connection wizard under the Connections button, to define a WLAN connection.
4. Create as many connections profiles as you like.
5. After creating the connection profile you will be returned to the Internet Connections menu.
6. Set Connect automatically to Any connection
7. Check Switch to WLAN when available.
8. Click the Save button.

I wasn’t looking forward to the arduous job of transferring my contacts, calendar and notes from my old N95 to my new N900. As it turned out it was really easy.

1. Activate Bluetooth on both phones and make sure they are both visible.
2. On Nokia N95 press the menu button to take you to the main desktop.
3. Go into the Applications folder.
4. From there go into the Welcome application.
5. Select Switch.
6. Select the icon from the bottom of the screen to synchronise data in one direction.
7. Select Bluetooth and follow the instructions.
8. Once the N95 is happily connected to the N900, it will just transfer across all your information.

It was a wireless - application-less pleasure!

Occasionally you may find that a nasty virus changed your desktop and removed your ability to run regedit.exe.

There are several ways to re-enable it which depend on your operating system and set up.

1. Start -> Run -> gpedit.msc -> User Configuration -> Administrative Templates -> System -> Prevent access to registry editing tools -> Right Click Properties -> Disabled
2. Run the following command:

   REG add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System /v DisableRegistryTools /t REG_DWORD /d 0 /f

3. Create a .reg file that contains the changes to switch on the registry editor then run it.

   Windows Registry Editor Version 5.00
   
   [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System]
   "DisableRegistryTools"="0"

The rules for the size of a ThreadPoolExecutor's pool are generally miss-understood, because it doesn't work the way that you think it ought to or in the way that you want it to.

Take this example. Starting thread pool size is 1, core pool size is 5, max pool size is 10 and the queue is 100.

Sun's way: as requests come in threads will be created up to 5, then tasks will be added to the queue until it reaches 100. When the queue is full new threads will be created up to maxPoolSize. Once all the threads are in use and the queue is full tasks will be rejected. As the queue reduces so does the number of active threads.

User anticipated way: as requests come in threads will be created up to 10, then tasks will be added to the queue until it reaches 100 at which point they are rejected. The number of threads will rename at max until the queue is empty. When the queue is empty the threads will die off until there are corePoolSize left.

The difference is that the users want to start increasing the pool size earlier and want the queue to be smaller, where as the Sun method want to keep the pool size small and only increase it once the load becomes to much.

Here are Sun's rules for thread creation in simple terms:

1. If the number of threads is less than the corePoolSize, create a new Thread to run a new task.
2. If the number of threads is equal (or greater than) the corePoolSize, put the task into the queue.
3. If the queue is full, and the number of threads is less than the maxPoolSize, create a new thread to run tasks in.
4. If the queue is full, and the number of threads is greater than or equal to maxPoolSize, reject the task.

The long and the short of it is that new threads are only created when the queue fills up, so if you're using an unbounded queue then the number of threads will not exceed corePoolSize.

For a fuller explanation, get it from the horses mouth: ThreadPoolExecutor API documentation.

There is a really good forum post which talks you through the way that the ThreadPoolExecutor works with code examples: http://forums.sun.com/thread.jspa?threadID=5401400&tstart=0

More info: http://forums.sun.com/thread.jspa?threadID=5224557&tstart=450

Most people want it the other way around, so that you increase the number of threads to avoid adding to the queue. When the threads are all in use the queue starts to fill up.

Using Sun's way, I think you are going to end up with a system that runs slower when the load is light and a bit quicker as the load increases. Using the other way means you are running flat out all the time to process outstanding work.

I just don't see why they have done it this way. So far I have not seen a satisfactory explanation of why Sun's implementation works the way it does. Does anyone out there know?