These instructions probably also work with Windows NT, but I have no way to test.
After the printer device has been created, right-click on its icon and select Properties. Select the Postscript tab, and set the "Postscript output format" to "Encapsulated Postscript (EPS)". Click the Advanced button, and make sure the "Send CTRL-D" boxes are not checked. See the pictures below for an illustration.
Put one figure per document page, and to write the EPS, print the current page to the printer device. I'm not sure whether this is absolutely necessary, but I advise orienting your page as portrait rather than landscape, or you might end up with a rotated figure.
Unfortunately, the postscript produced is still unsuitable as EPS. There are two problems:
To deal with the clipping region problem in LaTeX2e (perhaps it also works in standard LaTeX?), you can use the \epsfig command as follows:
\usepackage{epsfig}
...
\epsfig{figure=foo.epsi,clip=}
There are other options to \epsfig for scaling and rotating; see the
documentation for more details.
Unfortunately, this solution only works for LaTeX, and not for other programs that incorporate EPS. Another problem is that ps2epsi seems to be a tiny bit too aggressive in computing the bounding box. If the edge of your figure contains text, a tiny (but noticeable) portion of it may be shaved off due to the overly-tight clipping region.
To solve this problem, Michael Hemy has written a program based on ps2epsi that computes the bounding box and adds the clipping region, adding a little bit of slack to account for the aggressive clipping. It can be found in /afs/cs/user/mhemy/public/ps2eps.1.4.tar.gz . I invoke it on "foo.ps" as "ps2eps -c -b 2 -o foo.eps foo.ps". This adds the clipping region, and adds a slack of 2 points around the boundary.
One final problem I've run into. Sometimes when your figure contains a "non-postscript" TrueType font (e.g., the "MT Extra" font that contains additional math symbols), ps2epsi (and Michael's ps2eps) will crash on the input file. The problem seems to be that the Microsoft-generated postscript is incomplete. ps2epsi tries to collect a list of fonts used in the document by querying the FontName property of each font, but the temporary font created by the Microsoft printer driver neglects to implement the FontName property.
The fix is the following. Copy the ps2epsi.ps file (from wherever it is in the ghostscript distribution) to the current directory. Search for the line containing the string "/setfont", and comment it out with the % character. When you next run ps2epsi (or ps2eps), the ps2epsi.ps file in the current directory will be used instead.
For Microsoft Office products (e.g., powerpoint, word, excel), use the custom installation to install the "EPS filter", allowing you to import EPS pictures into your document. There's no magic here, unfortunately; powerpoint won't show you what your EPS picture is going to look like. To get this functionality, you need to use a tool that adds a Microsoft-compatible preview image to the EPS file.
A tool to do this is epstool. I invoke it as "epstool -b -t6p -zppmraw -ofoo.eps foo.ps". These options cause it to compute the bounding box, and to provide a preview that is capable of showing color. If you want a lower-resolution preview (and hence an EPS file that consumes less disk space), add the "-rXXX" option, where XXX is the desired dpi (default is 72).
If you now print to a postscript printer device, the postscript part of the EPS file will be inserted into the output as you would expect. If you print to a non-postscript device, it will use the (low-res) preview image instead.
One final note: I've seen some postscript that caused problems when following these instructions; e.g., Matlab. When I ran the Matlab-generated postscript through ps2epsi before going through epstool, it worked fine.