Well it was on the site before, but the time has come for me to make an official announcement: Twickret is officially RELEASED on Windows operating systems from XP to Windows 7 as of this morning.

Check it out on the Download page.

Latest news: A twickret version for iPhone is currently pending approval from Apple, watch this space for more info, I’m expecting it to be available on the App Store shortly.

Listen do you want to know a Twickret? Promise not to tell?
Twitter something secret to specific friends and have everyone else guessing what you said! They’ll never know unless you tell them – with Twickret – a secret messaging system that turns your Tweets into uncrackable* spy code. What couldn’t you get away with? It’s up to you, but use the power of Twickret wisely – or just for laughs – whatever works for you. This is a fun application for entertainment purposes only – 007 please use your usual methods – not recommended for state secrets.
 

Key features:

- Strong, custom designed text cipher secures your updates so only those you choose can read them

- Intuitive easy to use interface

- Encode, update and receive tweets from one place – no need to use the browser

- Only those who know the codeword will be able to decode

Twickret main screen on Windows

Twickret timeline view on Windows

* Resultant data is not 100% secure – those with the right resources and a lot of time will be able to crack it. Please be responsible.

This post was written in(dd-mm-yyyy hh:mm) 27/10/2009 00:39 PM (-3 GMT)

I’ll try to put here a step-by-step of what you should do on your Windows XP machine  in order to install Eclipse to use it as a Python IDE.

DOWNLOADING

You’ll need the following – software to be downloaded and installed – in the exact order that follows beneath:

After you’re logged into your machine as an administrator you should download the softwares from 2-3.

Eclipse:

1. Extract and run Eclipse.
2. Go to the menu “Help” > “Find and Update” > “Find and Install…”.
3. Select the option “Search for new features to install” and click “Next”.
4. Click the button “New Remote Site” and fill the “Name:” field with the name PyDev and the “URL:” field with the following URL: http://pydev.org/updates
5. Click “Finish”.
6. Select the entire PyDev package or the packages you want “PyDev” and/or “PyDev Mylnyn Integration (optional)”.
7. Click “Next”.
8. “I accept the terms in the license agreements”.
9. Click “Next” and “Finish”.
10. After a while click “Install all”.
11. Eclipse will ask you if it’s ok to restart click “Yes”.

PyDev 1.5.0 will take ~21,96 Mb.

CONFIGURING THE INTERPRETER

Now you should do the following inside Eclipse:

1. Click in “Window” > “Preferences…” > “PyDev”.
2. Click in the option “Interpreter - Python” and click in the upper right button named “New”.
3. Click in the “Browse” button to search for your “python.exe” file and after that click “Ok” three times.

Done! If you did everything correctly you’ll have by now Python and Eclipse working together. For further information check the PyDev Documentation site. Enjoy!

Some time ago, I wanted to see if the simulated mouse moves generated via calls to the WIN32 API mouse_event function would prevent the screen-saver from triggering.

In the current version of XP ( and some older versions of Windows ) these events do indeed keep the screen-saver from activating.

Please refer to the source below.

busy_mouse.c

// Generate mouse events to prevent the screen-saver from
// activating.
//
// License: MIT / X11
// Copyright (c) 2009 by James K. Lawless
// jimbo@radiks.net http://www.radiks.net/~jimbo
// http://www.mailsend-online.com
//
// Permission is hereby granted, free of charge, to any person
// obtaining a copy of this software and associated documentation
// files (the "Software"), to deal in the Software without
// restriction, including without limitation the rights to use,
// copy, modify, merge, publish, distribute, sublicense, and/or sell
// copies of the Software, and to permit persons to whom the
// Software is furnished to do so, subject to the following
// conditions:
//
// The above copyright notice and this permission notice shall be
// included in all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
// EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
// OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
// NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
// HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
// WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
// FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
// OTHER DEALINGS IN THE SOFTWARE.

// check the state of the Scroll Lock or Caps Lock keys.  Return a
// 1 if the requested key is active/on.

#include <windows.h>
#include <stdio.h>
#include <string.h>

#pragma comment(lib,"user32.lib")

void process_messages(void);

int main(int argc,char **argv) {
   int i;
   printf("Busy Mouse v1.0 by Jim Lawless\n");
   printf("If CAPS LOCK is on, the mouse cursor will move around to prevent any screen-savers from activating.\n");
   for(;;) {
      while(GetKeyState(VK_CAPITAL)&1) {
         for(i=0;i<50;i+=2) {
            mouse_event( MOUSEEVENTF_MOVE,2,0,0,0 );
            process_messages();
         }
         Sleep(200);

         for(i=0;i<50;i+=2) {
            mouse_event( MOUSEEVENTF_MOVE,0,2,0,0 );
            process_messages();
         }
         Sleep(200);

         for(i=0;i<50;i+=2) {
            mouse_event( MOUSEEVENTF_MOVE,-2,0,0,0 );
            process_messages();
         }
         Sleep(200);

         for(i=0;i<50;i+=2) {
            mouse_event( MOUSEEVENTF_MOVE,0,-2,0,0 );
            process_messages();
         }
         Sleep(200);
      }
   }
   processMessages();
}

void process_messages(void) {
	MSG m;
	while( PeekMessage(&m,0,0,0,PM_REMOVE)) {
   	TranslateMessage(&m);
		DispatchMessage(&m);
	}
}

When you run busy_mouse.exe the program will loop indefinitely. The program checks the CAPS LOCK state. If CAPS LOCK is enabled, it will then move the mouse in a rectangular pattern via mouse_event().

When CAPS LOCK is off, the simulated mouse events halt.

I’ve used this to keep the screen visible so that I can watch for emails or processes that run long while I’m away from the mouse and keyboard.

The source and executable file for busy_mouse can be downloaded in a single archive at:
http://www.mailsend-online.com/wp/busy_mouse.zip

Save to del.icio.us
Digg it
Save to Reddit
Share on Facebook
Share on Twitter
More bookmarks

Unless otherwise noted, all code and text entries are Copyright © 2009 by James K. Lawless

Este es un programa que resuelve una de las pruebas del juego del MAME Puzzle & Action: Tant-R, en concreto la de la rana que tiene que ir pisando todas las casillas del tablero sin dejar ninguna sin pisar. Estas son algunas de las pantallas que te pueden salir:

El programa muestra un tablero como el del juego pero vacío. Si pinchas en una casilla sitúas la rana, y las siguientes que pinches serán las piedras. Cuando hayas terminado de poner piedras pulsas Solución. Si hay más de una solución te seguirán saliendo cada vez que pulses el botón hasta que ya no queden más:

Pincha aqui para bajar el ejecutable y el código

Puedes usar los casos que salen en el juego, como en las tres capturas de arriba, o probar otros.

Si vas a probar los tuyos propios muchas veces pasará que no haya ninguna solución, o que haya tantas que se te quede el programa prácticamente colgado pensando. Poniendo 5 o 6 piedras normalmente saca las soluciones rápido.

Realmente son dos programas separados:

Algumas explicações sobre formatos proprietários podem ser encontrados no Wiki do Ubuntu Br, na instalação dos codecs do windows (w32codecs) precisa da instalação do libstdc++.so.5 que está no pacote libstdc++5, é só digitar no synaptic que ele aparece,  no Ubuntu 9.04 ele está nos repositórios, já no Ubuntu 9.10 só tem o pacote libstdc++6 que não funciona, mas tem o pacote libstdc++5 pra baixar da versão anterior, o Ubuntu 9.04 jaunty.

In the .NET Framework version 1.0, the common language runtime (CLR) has a separate memory manager for the large object heap. Under some circumstances this memory manager does not return unused memory to the operating system, and in a few cases it does not make the memory available for garbage collection. This results in failure to allocate memory due to virtual address space fragmentation. In the .NET Framework versions 1.1 and 2.0, the large object heap is composed of contiguous areas of memory called heap segments, properly aligned to minimize virtual memory fragmentation. During garbage collection, the space reclaimed from large objects is consolidated and placed in a free list. Heap segments containing only free list items are freed and the memory is returned to the operating system. These changes to the large object heap have effectively eliminated memory allocation failures caused by this form of virtual address space fragmentation.

via Garbage Collection.

void create_zipped_folder(string & folder_name)
{
   if(CreateDirectory(folder_name.c_str(),NULL))
   {
      HANDLE hFile = CreateFile(folder_name.c_str(),
                        GENERIC_READ | GENERIC_WRITE,
                        NULL,
                        NULL,
                        OPEN_EXISTING,
                        FILE_FLAG_BACKUP_SEMANTICS,
                        NULL);

      DWORD dummy;
      USHORT format = COMPRESSION_FORMAT_DEFAULT;
      if(!DeviceIoControl(hFile, FSCTL_SET_COMPRESSION, &format, sizeof(USHORT), NULL, 0, &dummy, NULL))
      {
         ErrorExit(TEXT("DeviceIoControl Failed"));
      }

      CloseHandle(hFile);
   }
}

Python has it’s own logging. Twisted has it’s own logging. Unfortunatley, none of them have a convinient way to log to underlying operating system’s facilities (which is, syslog or Windows Event Log in my case). So, I had to wrote one myself. Here you go – this is MultiLog:

class MultiLog(object):
"""

class MultiLog(object):
    """
    Multiplatform logging component.
    (C) 2009 FHU KAGAMI <info@fhu-kagami.pl>

    Distributed under the terms of MIT License
    """
    def __init__(self, appname, interactive = None):
        self.hostname = socket.gethostname()
        self.appname = appname
        self.interactive = interactive
        if self.interactive is None:
            self.interactive = '--interactive' in sys.argv
        self.pid = os.getpid()

        fun = '_init_log_' + sys.platform
        getattr(self, fun)()

    def log(self, msg):
        if type(msg)==unicode:
            msg = msg.encode('utf8')
        fun = '_log_' + sys.platform
        return getattr(self, fun)(msg)

    __call__ = log

    def _log_interactive(self, msg):
        if self.interactive:
            msg = time.ctime() + ": " + self.hostname + " " + self.appname + "[" + str(self.pid) + "]: " + msg
            sys.stderr.write(msg)
            sys.stderr.write('\n')
            sys.stderr.flush()

    def _init_log_unix(self):
        from syslog import openlog
        openlog(self.appname + "[" + str(self.pid) + "]")

    def _log_unix(self, msg):
        from syslog import syslog
        syslog(msg)
        self._log_interactive(msg)

    _init_log_linux2 = _init_log_unix
    _log_linux2 = _log_unix

    def _init_log_win32(self):
        import win32evtlog
        import win32con
        self._win32_type = win32con.EVENTLOG_INFORMATION_TYPE
        self._win32_log = win32evtlog.OpenEventLog(None, self.appname)

    def _log_win32(self, msg):
        import win32evtlog
        win32evtlog.ReportEvent(self._win32_log, self._win32_type, 0, 0, None,
            (msg, 'PID: %s' % self.pid), None)
        self._log_interactive(msg)

if __name__ == "__main__":
    log = MultiLog('my application')
    log('this is a test')

On Ubuntu, look for /var/log/user.log. On Windows, run mmc.exe and open eventwvr – look for Application Logs.

A new version of the cfix unit testing framework is now ready for download.

Unlike the previous release, which was mainly a maintenance release, cfix 1.5 adds major new features: kernel mode multithreading and EXE-based unit tests.

EXE based unit tests

As I discussed in a previous post in the context of Visual Assert/cfix studio, cfix’ restriction to DLL based unit tests has turned out to be quite a limitation for certain kinds of projects.

In cfix 1.5, this restriction has been removed: cfix now supports both, unit tests compiled and linked into DLL modules and unit tests embedded into EXE modules.

Now, when I say embeded into an EXE module, I do not mean that you may merely leave out the /LD compiler switch — it means that you may compile and link unit tests into the actual application EXE module without impacting this application’s behavior or having to change the application’s main() routine: When you run the application direcly or through the debugger, it will behave as normal (e.g. launch GUI). Once you launch it via cfix32 -exe app.exe (or cfix64 -exe app.exe, respectively), however, the application’s main() routine will not execute and instead, your embedded unit tests will run.

This may seem awkward at first — but it offers a tremendous advantage: All of the application’s code now immediately becomes testable (i.e. accessible by unit test code) without having to do complex reorganization of your build process or source tree layout (although it is still a very good idea to enhance the build process s.t. the unit tests are stripped in the RTM builds and to make cfix.dll a delayload DLL). For many projects, relying on this feature will therefore make adopting cfix and maybe even unit testing in general much easier.

In almost all regards, EXE-embedded unit tests behave the same as their DLL counterparts. They are, however, slightly less handy when it comes to debugging (unless you use Visual Assert, which will shield you from this). For this reason, and their greater flexibility in general, it should be noted though that DLL-based unit tests will remain the preferred choice.

Kernel mode multithreading

Since its first release, cfix has featured support for multi-threaded test cases. Multi-threaded test cases are tests which spawn child threads and — and this is the important point — both, the “main” thread and the child threads may trigger assertions (i.e. use CFIX_ASSERT and friends). Regardless of the thread an assertion occurs on, it will be recognized by the framework and will lead to the test case being marked as having failed. In case this sounds trivial to you, be informed that not even JUnit properly supports this

And while this feature has been supported for user mode tests ever since, the infrastructure for kernel mode unit tests, which was added in version 1.1, has lacked support for this feature: There was no kernel mode counterpart of CfixCreateThread and thus, only single-threaded kernel mode tests were supported.

cfix 1.5 now finally introduces CfixCreateSystemThread: CfixCreateSystemThread is basically a wrapper for PsCreateSystemThread with the added functionality of registering the child thread with cfix. Thus, all threads spawned using CfixCreateSystemThread (rather than using PsCreateSystemThread directly) are allowed to make use of assertions.

Kudos to Matt Oh for beta-testing this feature.

Minor enhacements

Another enhancement related to multi threaded tests is Auto-joining of child threads: After a test routine completes, the framework will now automatically check whether any child threads were created. If this is the case and any of these threads are still running, they will be waited on — not before all threads have terminated will the test run resume. This feature both makes writing multi-threaded tests more convenient (you do not have to wait by yourself) and safer (No more runaway child threads).

Finally, another feature worth noting is that by specifying the -td command line switch, cfix can be directed to not capture a stack backtrace when an assertion fails. Although stack backtraces are usually very helpful, the symbol loading can make their creation quite expensive. Using this switch can therefore speed up the usage of cfix.

Download/Upgrade Now

You see, there are many good reasons to upgrade your cfix installation or — in case you are not using cfix yet — to give cfix a try.

Better yet, check out the Visual Assert AddIn for Visual C++ — it is based on the new cfix 1.5 release and seamlessly integrates with Visual Studio.

Download cfix 1.5.0 Installer
Download cfix 1.5.0 source code

In a previous post, we’ve seen how to wrap the diStorm disassembler library in Python, using ctypes. This still left us with the task of building the dynamic link library for our platform and installing it manually, which is not as easy as it may seem – among other small problems you may find, the new versions of Visual Studio try to force the use of the latest C++ runtime redistributables, which may not be present in most Windows installations.

Today, I’m introducing a new ctypes wrapper for diStorm, this time with all binaries prebuilt and packaged together. The installer script automatically detects the target platform and installs the right binary. It comes with the following prebuilt binaries:

• Windows on x86 and AMD64 processors
• Linux on x86 and AMD64 processors (built using Ubuntu, but should work in other distros)
• Mac OS X on x86 and PowerPC processors (untested, I don’t have a Mac to play with yet)

Since the installer code is pretty much generic, it should be easy to add new platforms by simply creating the corresponding subdirectory and placing the python code and prebuilt binary in it. Contributions are welcome!

Download

Python 2.x

• Source code (all platforms): distorm-1.7.30.zip
• Source code (all platforms): distorm-1.7.30.tar.gz
• Windows 32 bits installer: distorm-1.7.30.win32.exe
• Windows 32 bits MSI installer: distorm-1.7.30.win32.msi
• Windows 64 bits installer: distorm-1.7.30.win-amd64.exe
• Windows 64 bits MSI installer: distorm-1.7.30.win-amd64.msi

Python 3.x

• Source code (all platforms): distorm-1.7.30.zip
• Source code (all platforms): distorm-1.7.30.tar.gz
• Windows 32 bits installer: distorm-1.7.30.win32.exe
• Windows 32 bits MSI installer: distorm-1.7.30.win32.msi
• Windows 64 bits installer: distorm-1.7.30.win-amd64.exe
• Windows 64 bits MSI installer: distorm-1.7.30.win-amd64.msi

Thanks go to Alexandre Julliard at Crossover/WineHQ for this patch I believe.

I’ve been frustrated for a while now because of Sony’s SecuROM. For those that don’t know, it’s another kind of DRM malware, not as bad as Starforce, but that’s certainly not because they haven’t been trying.

Some games that are infected with SecuROM and other copy restriction malware install OK but crash Wine when you load the game, even though you have a perfectly legal copy, even if you put the original disc in the drive as it asks. It will keep saying “Please insert the original disc”, if it even starts without crashing Wine. Some older versions will see Wine and assume it’s a debugger or an attempt to bypass the copy restrictions, like YASU (integrated with Daemon Tools on Windows) uses to fool SecuROM infected games into mounting in the virtual disc drive it creates. (Side note: I think having to insert the disc is enough of an annoyance that these cracks actually abound on Windows when the user has actually bought the game)

Up til about last year, you could usually get the game installed and then go find a no-disc fixed EXE somewhere that would get the game you paid for and legally have the right to use, to work. I don’t even know how many laws that violates, and I don’t really care. I’ve never much appreciated Big Media pushing me around like some kind of software pirate just because I want to play the game I purchased on a non-Windows system.

Anyway, back to the issue, you could install but not play (unless you cracked the game’s EXE), but at least it installed. Then some greedy corporate fuck got the idea “What if we put SecuROM into the installer?”, so now you can’t even get it installed to later apply the fixed EXE.

The irony of it all is that you can still install the game then apply the no-disc EXE perfectly fine on Windows. This got me wondering if perhaps someone is merely doing this to crash Wine since it would have no affect at all on “software pirates”  on Windows (no copy restriction ever does hold them back for more than a few days, if that).

I say this because Bethesda Softworks certainly seems to be hostile to free software, they have a few decent games, but their engines always use like every feature of DirectX, their in-game music files are all MP3s (even Microsoft has been known to use the patent and royalty-free Ogg Vorbis in its in-game music!), and they’re getting to where they infect every title with some kind of customer-unfriendly DRM.

The original release of Oblivion didn’t even have copy protection at all though, mind you,  it would install and run just dandy, or at least as well as old pre-1.0 Wine could run it. Wine’s Direct3d 9 implementation has gotten much better lately and game texture details and performance rival the real DirectX 9 on Microsoft Windows in many cases.

So the only thing that was holding you back from playing the Game of the Year Edition (Knights of the Nine and Shivering Isles expansion packs included) that’s currently at every Walmart for $20 was the SecuROM infection that was introduced (actually this was in the installer for the standalone expansion disc pack earlier on).

I’m now happy to report that Oblivion GOTY Edition is working on Wine with no cracks and no Microsoft DirectX files. The installer takes a while to load, so be patient, and the second disc’s installer will throw an error that you can just click to get rid of and ignore.

I ran the game on High at 1680 x 1050 with show frames per second (HDR off, this still hurts performance more on Wine than Windows).

It’s not really a benchmark as much as a ballpark guess, but Wine performance seems about 5-10% slower than XP and about equal to Vista. This is pretty awesome considering just how visually heavy Oblivion is, that Wine is a compatibility layer on a totally foreign OS, and that Windows is poorly documented and has surely caused a lot of blood, sweat, and tears for the Wine folks.

Another thing that disturbs me:

ZeniMax, who owns Bethesda, also bought id Software, which in the past has always supported Linux with native versions of their games and didn’t use malicious or overly-invasive copy restrictions such as SecuROM. I have to wonder, with their new owners, if that Linux support will fade and if the damned filthy Sony DRM will encapsulate DOOM 4 and other future id Software titles. I would certainly hope that John Carmack would not let himself be pushed around in such a manner.

So you may want to pop the cork on the champagne and cancel your Cedega subscriptions:

About the only reason to keep Cedega around was because they licensed the copy protection compatibility modules and so problems like this didn’t affect them. Once you get past that, Cedega often does not run as well as Wine and while Wine is free, Cedega still costs something like $55 a year I believe.

Wine still does not run *every* Windows program out there. Some (like Winamp and its plugins) are so heavily dependent on the Win32 API that they’ll probably never work right, but seriously malfunctioning  programs on Wine are becoming more of the exception than the rule these days, and I think Wine 1.2 is shaping up to be a fair replacement option for XP holdouts and maybe even a few overburdoned Vista systems.

If anyone is interested, I think this patch is what finally turned the tide on SecuROM-the-Wine-killer:

“ntdll: Add a ret to DEFINE_REGS_ENTRYPOINT to make copy protections happy.” -source Wine 1.1.28 changelog

Get Wine for your distribution here.

Whenever Windows Installer’s built-in actions do not suffice to perform a specific task, a Custom Action needs to be written. Needless to say, Custom Actions, can be a bit tricky — not only can they be laborious to write and cumbersome to debug, they also run the risk of interfering with Windows Installer’s declarative, transactional way of performing installs.

It is not really surprising that Windows Installer therefore more or less discourages the use of Custom Actions unless it is absolutely necessary. Moreover, as a result of its declarative nature, it is understadable that Windows Installer prefers Custom Actions to be data-driven.

What this means in practice is that a Custom Action should not perform a hard-coded task — rather, it should query one or more (custom) tables containing the necessary information (in a declarative manner) about what is to be performed and should act accordingly.

Using WiX, creating custom tables turns out to be pretty easy. Let’s assume we create a Custom Action that, based on some condition, does something with a specific file. An appropriate table could look like this:

<CustomTable Id="MyCustomTable">
  <Column Id="Id" Type="string" PrimaryKey="yes"/>
  <Column Id="Path" Type="string"/>
  <Column Id="Condition" Type="string"/>

  <Row>
    <Data Column="Id">Foo</Data>
    <Data Column="Path">[INSTALLLOCATION]foo.txt</Data>
    <Data Column="Condition"><![CDATA[ &FeatureFoo=3 ]]></Data>
  </Row>
  <Row>
    <Data Column="Id">Bar</Data>
    <Data Column="Path">[INSTALLLOCATION]bar.txt</Data>
    <Data Column="Condition"><![CDATA[ &FeatureBar=3 ]]></Data>
  </Row>
</CustomTable>

To query this table, we have to open a view and fetch the records one by one:

PMSIHANDLE Database = MsiGetActiveDatabase( InstallHandle );
ASSERT( Database != NULL );

PMSIHANDLE View;
UINT Result = MsiDatabaseOpenView(
  Database,
  L"SELECT `Condition`, `Path`, FROM `MyCustomTable`",
  &View );
if ( ERROR_SUCCESS != Result )
{
  ...
}

Result = MsiViewExecute( View, NULL );
if ( ERROR_SUCCESS != Result )
{
  ...
}

for ( ;; )
{
  PMSIHANDLE Record;
  Result = MsiViewFetch( View, &Record );
  if ( Result == ERROR_NO_MORE_ITEMS  )
  {
    break;
  }
  else if ( ERROR_SUCCESS != Result )
  {
    ...
  }

  //
  // Read condition.
  //
  // N.B. Do not format -- this is done by
  // MsiEvaluateCondition itself.
  //

  WCHAR Condition[ 256 ];
  DWORD Length = _countof( Condition );
  Result = MsiRecordGetString(
    Record,
    1,
    Condition,
    &Length );
  if ( ERROR_SUCCESS != Result )
  {
    ...
  }

  if ( MSICONDITION_TRUE != MsiEvaluateCondition(
    InstallHandle,
    Condition ) )
  {
    //
    // This record can be skipped.
    //
    continue;
  }

  //
  // Read remaing fields.
  //

  WCHAR Path[ MAX_PATH ];
  Length = _countof( VszPath );
  Result = GetFormattedRecord(
    InstallHandle,
    Record,
    2,
    Path,
    &Length );
  if ( ERROR_SUCCESS != Result )
  {
    ...
  }

  ...
}

With GetFormattedRecord being the following utility routine:

static UINT GetFormattedRecord(
  __in MSIHANDLE InstallHandle,
  __in MSIHANDLE Record,
  __in UINT Field,
  __out PWSTR Value,
  __inout PDWORD Length
  )
{
  DWORD RecLength = *Length;
  UINT Result = MsiRecordGetString(
    Record,
    Field,
    Value,
    &RecLength );
  if ( ERROR_SUCCESS != Result )
  {
    *Length = RecLength;
    return Result;
  }

  PMSIHANDLE FormattingRecord = MsiCreateRecord( 1 );

  Result = MsiRecordSetString( FormattingRecord, 0, Value );
  if ( ERROR_SUCCESS != Result )
  {
    return Result;
  }

  return MsiFormatRecord(
    InstallHandle,
    FormattingRecord,
    Value,
    Length );
}

Some things are worth noting:

• I use PMSIHANDLE, which, as you probably already know, is not a typedef for MSIHANDLE* but rather a smart-pointer like class that automatically closes the handle when it goes out of scope.
• The use of backticks in the query.
• It must have been a Visual Basic programmer implementing MsiRecordGetString: Field Indexes start with 1, not 0. To make matters worse, reading from index 0 does not fail but returns arbitrary data. Finally, to confuse people further, indexes are 0-based for MsiRecordSetString.
• If the field contains formatted data, you have to MsiFormatRecord it yourself. For conditions, however, MsiEvaluateCondition handles that for you.

So far, so good. There is, however, one thing to notice: To access the installer database, the custom action must be a nondeferred action:

You cannot access the current installer session or all property data from a deferred execution custom action

The problem with nondeferred actions, however, is that they execute in user context — in contrast to deferred actions, which execute in system context. On pre-Vista platforms, a per-machine installer package can be expected to always be launched by an administrator (otherwise it will fail anyway) — in this case, the differences between user and system context may not be important — both, for example, have r/w access to files in %ProgramFiles%. On Vista and later OS, however, it is common to have a regular user launch an installation which causes an elevation prompt once it reaches the main install phase. In this case, the user context is significantly less privileged than system context.

For a hypothetical custom action that is intended to edit a file installed to %ProgramFiles%, this means that (disregarding rollback considerations and assuming proper scheduling) performing this action from within the nondeferred custom action will work fine on pre-Vista OS. When run on Vista, though, it is likely to fail due to lack of write access to %ProgramFiles%. In practice, this means that all system-changing tasks usually have to be performed by a deferred action.

To sum up: To be data-driven, you have to use nondeferred actions. To be able to perform any serious, system state-changing tasks, however, you have to use deferred actions.

Great.

As it turns out, however, there is a way to escape this catch-22, and it is carefully buried in the Windows Installer documentation:

[...] Actions that update the system, such as the InstallFiles and WriteRegistryValues actions, cannot be run by calling MsiDoAction. The exception to this rule is if MsiDoAction is called from a custom action that is scheduled in the InstallExecuteSequence table between the InstallInitialize and InstallFinalize actions. [...]

[From the Remarks section of MsiDoAction]

In fact, the way I came across this solution was by looking at the source code of the WiX XmlFile action, which I knew manages to both be data-driven (uses a custom table) and alter system state (edits XML files). The way it does this, and the point where the above remark comes into play, is as follows: In the nondeferred action, you do not perform any actions changing system state. Rather, you collect the information from the installer tables and stuff it (yuck) into the CustomActionData property. Then, leveraging MsiDoAction and passing said CustomActionData, you schedule another custom action — this time a deferred one — which parses the CustomActioData (yuck) and, based on this data, finally performs the actual modifications — in system context.

It really could not be easier and more intuitive, right?

Olá desenvolvedores,

O novo vírus afeta programas escritos em Delphi.

Descritivo:

Os desenvolvedores com as máquinas infectadas vão passar a infecção para todos os programas que estiverem criando. A Sonicwall e outras empresas de softwares antivírus já atualizaram seus programas para possibilitar a detecção e bloqueio do Win32.Induc.

Fonte: Baboo.

, abraço.

Caio Barbosa
Desenvolvedor Web