Posted tagged ‘Windows’

Notes on installing the MDaemon BlackBerry Enterprise Server component under Windows 7

January 15, 2013

Recently, I decided to try and install a demo version of Alt-N’s MDaemon Messaging Server for Windows, out of curiosity.

It seems that the main server component installation completes successfully – although I didn’t try to use any of the newly-installed components, immediately.

Unfortunately, installation of the optional BlackBerry Enterprise Server component fails with:

According to a page on the FalconView Wiki; and an MS KnowledgeBase article, this error relates to a permissions issue on a non-existent directory (C:\Documents and Settings\NetworkService\Application Data\Microsoft\Protect).

Under Windows 7, the equivalent directory is supposed to exist at C:\Windows\ServiceProfiles\NetworkService\AppData\
Roaming\Microsoft\Protect
– but I had to manually create it, after gaining permission to access C:\Windows\ServiceProfiles\NetworkService\.

It seems that a similar error that occurred whilst trying to install a slightly older version of MS SQL Server under Windows XP, has also been reported.

I also ended up uninstalling some existing MS SQL Server 2008 components that were supplied as with other software.

Afterwards, I re-launched the installation process, and got a little further – only to encounter another error:

It appears that rebooting Windows is the favoured workaround for this issue (that apparently relates to a (Microsoft.SqlServer.Setup.Chainer.Workflow.
ActionExecutionException
) being triggered)  – which worked for me, in this scenario, and meant that I was able to successfully use the product.

Unsurprisingly, the official product support KnowledgeBase has limited information regarding installation failures.

That said, others have reported seeing a related error under Windows XP – despite using an Administrator account; and it appears that the problem also occurred with earlier releases of MS SQL Server.

Anyway, I hope that this belated, short post is vaguely useful.

Advertisements

Decoding SkypeIdentityList Clipboard Data Using Qt

August 23, 2011

Whilst working on SocialClient (one of my numerous projects), I decided that I wanted to provide users with the ability to import Skype contact usernames from the clipboard (or via drag-and-drop), whilst using the Contact Builder dialogue:

Contact Builder UI

After briefly spending time searching the Web, I stumbled across an old post on the Skype fora (which happens to be the sole Google search result for “SkypeIdentityList“, at the moment), where someone requested information regarding the content of clipboard data generated by the Skype client – and provided some useful pointers for my own exploration.

With that knowledge in mind, I then obtained a copy of the Microsoft ClipBook Viewer (which doesn’t ship with Windows 7), and had a look at its “View” menu, after copying a random contact from the client’s contact list:

ClipBook Viewer

Saving the file, and then opening it with a hex editor (I used PSPad’s “Open in Hex Editor” feature – but any will suffice) revealed that the clipboard data was UTF-16-encoded text:

I initially planned to utilise QString‘s fromUtf16() method. However, further investigation lead me to believe that it was worse than useless in this case – since all that I had was the aforementioned opaque blob of data, which consisted of a header denoting the size of the following text payload, and I couldn’t find a way to convert it into the necessary format (a pointer to an unsigned, short integer; and a standard integer).

After much deliberation, and testing various potential solutions (some of which involved extracting the length data, and using it whilst iterating over the rest of the payload) that often resulted in dismal failure – involving either receiving C++ runtime assertions after attempting to access non-existent data within an array, or simply obtaining too little data to be useful, I settled upon a variant of the following solution:

QString Skype::FetchUsernameFromClipboard() {

QClipboard *clipboard = QApplication::clipboard();

if (clipboard->mimeData(QClipboard::Clipboard)
     ->data("SkypeIdentityList").length() != 0) {
QByteArray mimeData =
clipboard->mimeData(QClipboard::Clipboard)
     ->data("SkypeIdentityList");
return Skype::ParseClipboardData(mimeData);
}

else

{
return "";
}
}

QString Skype::ParseClipboardData(QByteArray aRawData) {
QByteArray workingData = aRawData;
int stringSize = aRawData.at(0);
int pos = 0;

QString round1Data, round2Data;
char tempChar;

QMap charMap;

qDebug() << "Got data:" << aRawData.toHex() <<
    "of internal length" << QString::number(stringSize);
qDebug() << "Size of array after filling is" << aRawData.size();

for (pos = 0; pos < aRawData.length() - 5; pos++) {
tempChar = workingData.at(pos + 2 + 2);
qDebug() << pos << tempChar;
round1Data = round1Data + tempChar;
}

qDebug() << "Processed data is " << round1Data.size();

for (pos = 0; pos < round1Data.size() ; pos++) {
int notNull;

if (!round1Data.at(pos).isNull()) {
notNull = pos;
qDebug() << "NOT A NULL: " << round1Data.at(pos)
   << "AT: " << pos;
charMap.insert(notNull, round1Data.at(pos));
}
}

foreach (QChar value, charMap)
round2Data = round2Data + value;

return round2Data.simplified();
}

The aforementioned implementation produces the following output, when used in conjunction with the demo method:

Got data: "070000006500630068006f00310032003300" of
    internal length "7"
Size of array after filling is 18
0 e
1
2 c
3
4 h
5
6 o
7
8 1
9
10 2
11
12 3
Processed data is 13
NOT A NULL: 'e' AT: 0
NOT A NULL: 'c' AT: 2
NOT A NULL: 'h' AT: 4
NOT A NULL: 'o' AT: 6
NOT A NULL: '1' AT: 8
NOT A NULL: '2' AT: 10
NOT A NULL: '3' AT: 12
"echo123"

Of course, code that triggers FetchUsernameFromClipboard() (or ParseClipboardData() itself) is also necessary – and the FetchUsernameFromClipboard() demo function doesn’t even exist within the SocialClient codebase; but that should give a good idea as to how I implemented this.

It probably isn’t the most efficient technique ever, either…

Still, as always, please feel free to comment and make alternative suggestions.

Reverse-engineering an IrDA/USB Multiplexing Protocol : Part 1

August 1, 2010

Last month, I acquired a USB IrDA transceiver based upon a chipset from a seemingly defunct vendor (either the S110 or S110-SG1 from Tanic Electronics Ltd.), since it was fairly cheap (just under £12), and I had a spare phone with a washed-out display and an IrDA port sitting in my drawer to test it against.

Unfortunately, it seems that not only does this chipset/device not comply with the USB IrDA Bridge Device spec, but there is also no public data sheet, which makes writing a driver for non-Windows operating systems difficult. Theoretically, the Windows driver could be used under a modified version of NDISWrapper, or a similar NDIS API/ABI implementation – although that’s suboptimal in many ways (which should be obvious to some readers).

Those caveats aside, the device works fairly well when coupled with Windows XP’s primitive IrDA stack and associated utilities…

However, being the curious sort; and since the state of IrDA and USB debugging/tracing under Windows is dire, I decided to use Wireshark for analysis, coupled with the USB tracing functionality in recent versions of LibPCap and the Linux kernel – but in order to keep this post concise, I’ll provide more details in a follow-up post.

Playing with WiTango Server 5.5 and Apache 2.2.15 under Windows XP

March 28, 2010

I don’t particularly have a need to use this stuff; and the WiTango software itself is prehistoric (the last release for Windows was made in 2006, and the last release for UNIX clones/relatives was made in 2005), but I felt like a challenge.

After obtaining and unpacking the approximately 9MB Witango_App_Server_for_Win_5.5.020.zip archive; I preceded to run the installer, and followed most of the instructions provided – stopping only to obtain a “Lite” licence key using a spare GAfYD GMail account, as well as a copy of the Apache installer.

During the installation process, I ended up having to answer “Other” to a prompt regarding HTTP daemons; since Apache wasn’t installed, and I’ve been burnt previously by the outdated and otherwise dodgy WiTango Apache modules (the Linux ones don’t even work with Apache 2.2 as supplied by Fedora, and most of the supporting tools in the Linux package are broken – but that’s by-the-by).

Eventually, I was greeted with a dialogue with rather useless (incomplete) information, and peeked inside the directory at C:\Program Files\WitangoServer\5.5, to discover a Witango.exe executable that did nothing whatsoever when invoked, a rough ReadMe file, and various other DLLs, configuration files and directories.

I then installed Apache – ensuring that it wasn’t started as a service, and operated on TCP port 8080 by default, before returning to WiTango’s ReadMe file to look for the magic httpd.conf lines that would supposedly make things work.

Said ReadMe file recommends using the following – which wouldn’t work, unless you copied a ton of DLLs around:

# Witango Apache Plug-in configuration

# This loads the Witango 5.5 client for Apache 2.2 to
# enable communication with the Witango Application Server
LoadModule WitangoModule modules/mod_witango55_apache22.so
WitangoModule mod_witango55_apache22.so
AddType application/witango-application-file taf tml thtml tcf

As an initial compromise, I resorted to appending the following to the bottom of the httpd.conf file, and restarting Apache:

#WiTango Bits

LoadModule WitangoModule "C:\Program Files\WitangoServer\5.5\PlugIns\mod_witango55_apache22.so"

WitangoModule mod_witango55_apache22.so

AddType application/witango-application-file .taf .tml .thtml .tcf

After creating an empty file at C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\test.thtml, and navigating to http://localhost:8080/test.thtml in Chrome, I was greeted with this:

The lights are on, but no-one's home.

I resorted to altering the WitangoModule path to refer to the absolute path of the module’s DLL file (““C:\Program Files\WitangoServer\5.5\PlugIns\mod_witango55_apache22.so”” – a single pair of double quotes are used within httpd.conf), and restarting Apache yet again, only to receive the same “Client Error” message again.

According to the installation guide – which doesn’t even ship with the WiTango Server product, a Windows service (“Witango Server 5.5“) is supposed to be running (although it was never started in my case).

Unfortunately, the ReadMe never stated that, but I’m sure that it was obvious to the developers…

That aside, after starting the aforementioned service, I was greeted with this:

I guess that I can call it a success, given that I’m unfamiliar with the Tango/WiTango language, and haven’t got around to trying the associated developer tools yet…