Windows Services For Unix (SFU) Interix RSHD / REXEC and CMD.exe interoperability (no such device)

I thought I'd better post this as I've just spent a good few hours banging my head against my keyboard trying to get a batch file to execute (i.e. via CMD.exe) on a Windows box running SFU Interix RSHD via RSH from a BSD box.
No matter what I tried I was getting "no such device" errors, in the end I figured it was down to the file descriptors (i.e. stdin/out/err).
So if you want to execute a windows command/batch file (via CMD.exe) via Interix RSH daemon:-

(unix land)
$ rsh  "runwin32 <windows style path to exe/bat> </dev/null | cat"

e.g.
$ rsh x0 "runwin32 e:\wrcheck\wrcheck.bat </dev/null | cat"

What this does is re-direct stdout/stderr via the pipe so you see the output via cat, stdin is redirected from /dev/null, obviously this can be changed to suit your individual needs.
You could of course also redirect stdout/err seperately via >stdout.txt 2>stderr.txt.

I hope this saves someone a headache :)

Vista BSOD (blue screen) when uninstalling VMWare Workstation v5.5

If like me you get a BSOD when uninstalling VMWare 5.5.x under Vista then do the following:-

• Boot Vista into safe mode with command prompt
• cd to \windows\system32\drivers
• del vmx86.sys

Now boot back into Normal mode and un-install again.

Toshiba ESTUDIO 120 (Windows GDI) under BSD/UNIX (LPR)

As you may already know, there are a lot of "Windows Printers" out there. These printers by their very definition are designed solely for Microsoft's ubiquitous operating system..

As with most things of this ilk, there's usually some work around / port / open source solution, and so is the case when wishing to print to a Toshiba ESTUDIO 120 from (in my case) a FreeBSD 6.2 box.

Without wanting to get buried in the intricacies of why this printer (and others) can only be printed to via a Windows machine I'll give a brief overview:-

A "Windows Printer" has reduced hardware as it only expects to recieve its data in one format (GDI), since this format is a graphical format (GDI = Graphics Device Interface) then the printer effectively receives the image data pre-rendered by the Windows GDI subsystem. Due to this, the printer takes the data (a bitmap) and just prints it without any formatting or parsing.

As you'd expect these printers are cheaper, but not multi-platform friendly!!

If the GDI standard was open source, or even properly documented / licensed then suitable drivers could be written natively for *nix, however this is not the case (nice one Microsoft), so let us proceed!

(Thankfully these GDI/Windows printers are now being phased out in favour of a new emerging format similair in method to Postscript called XPS.)


Anyway, back to the point. Here's how to get your Toshiba ESTUDIO 120 / Windows printer working from a BSD/unix box.

You will need:-

• A Windows machine (acting as a print server with a shared printer (SMB/etc.))
• Some software which will take a Postscript input and produce a GDI output.
• A pseudo printer port (think virtual LPT:) which will pass the incoming Postscript to the above said software.

In a nutshell, you print Postscript from the unix box to an SMB/etc. shared Windows virtual printer, the virtual printer (software) parses the postscript via external utils and renders this as graphics (GDI). This is then sent to the real printer port through the Windows spooler and bingo, you've just killed some trees.

For the virtual LPT port and Postscript "middleman" functionality you will need Redmon. For the Postscript processing/parsing/rendering you will need Ghostscript
and GSView. All of which are installed on the Windows print server machine.

For a more practical implementation (step by step) guide, see this excellent site:-
http://mywebpages.comcast.net/heretrythis/hp3100/psemunt.html

mozilla / firefox 2 / bonecho build under FreeBSD 6.2

BonEcho!

I thought I'd share my experiences of building a fresh BonEcho/Firefox/2.0 from the Mozilla sauces on a cleanly built FreeBSD 6.2 system.

The reason for this entry is so I can help other people who may be hitting the same issues I did..

Here goes..

Firstly, I'll detail the steps I took to gather all the required data before we begin to think about building.

This link to the official mozilla build guide is invaluable, closely reading the pages there will help make your life easier.

I fetch'd the latest source from:- ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/latest-2.0/source.

You should now have a 35mb (ish) bz2 file, make sure you untar this to a mount point with at least 500mb free as this is how much space you'll need for a full build (as of 2.0 anyway)..

Before we proceed any further; the Mozilla build system has been developed with GNU make, so make sure you have that installed on your system (ports/devel/gmake).

Next step is to configure your individual make files, before going ahead and executing "./configure" you need to create a .mozconfig file (see the official build guide for more info).

There are various places you can stick the .mozconfig file, I put mine in the root of my home dir.
Here is mine for reference:-

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@
. $topsrcdir/browser/config/mozconfig
ac_add_options --enable-optimize
ac_add_options --enable-default-toolkit=gtk2
ac_add_options --enable-xft
ac_add_options --disable-tests

Now go to the root of your fresh sauce dir and run ./configure.

If you get error messages at this point, then go Google, because I didn't :-).

You should now have a new dir called obj-i386-unknown-freebsd6.2/ (or similair).

There's a couple of BSD type things to do before we build:-

Number 1; The nsprpub tree won't build correctly under 6.2 kernel, if you look into devel/nspr under ports you'll notice a patch file (/usr/ports/devel/nspr/files/patch-.._pr_include_md__freebsd.h). You can apply this, or you can do as I did and manually edit the _freebsd.h file under your mozilla source tree (pr/include/md/_freebsd.h) and make sure the following two #defines are actually defined:-

#define _PR_HAVE_GETPROTO_R
#define _PR_HAVE_5_ARG_GETPROTO_R

What this basically does is force the use of the reentrant versions of getprotobyname() / etc. which in a nutshell means certain functions are then thread safe, and thus our final build can be as optimised as possible..

Number 2; The generated makefiles (via ./configure) only link against the re-entrant lib c and not the standard lib c, thus if you try and build you'll get lots of undefined references to memcpy() / etc. The easy fix for this is to edit obj-i386-unknown-freebsd6.2/config/autoconf.mk and change the OS_LIBS variable so it contains -lc:-

OS_LIBS = -lm -lc_r -lc

If you already have this data, then your ./configure worked differently to mine -- congratulations.

Now as per the build instructions go to the root of your sauce dir and execute the following command:-

gmake -f client.mk build

Depending on your box, the time taken for the build will obviously vary. I'd say leave it for a bit and come back!

Assuming success you should now have a working binary!

Follow the build instructions for proper installation, but to test it out make sure you've got an X session running, cd to obj-i386-unknown-freebsd6.2/dist/bin, and execute:-

./firefox

Nicely done!