I can run my instance of windz.exe on Win7 64bit sucessfully from cmd.exe.
Note that Win7 64bit offers 2 variants of cmd.exe:
The default 64bit instance, located at C:\Windows\System32 (or wherever you installed windows).
And yes, it is located in the "System32" folder for backwards compatibility, although IMHO it better should
live in "System64". You can determine that it's this 64bit instance you're running by issuing the "set" command
and look at the PROCESSOR_ARCHITECTURE environment variable. It will display some 64ish setting within
the 64bit version of cmd.exe.
And there's the 32bit instance, located in C:\Windows\SysWOW64. This strange folder name means
"Windows on Windows 64", meaning that it contains all 32bit executables, for "emulating" a 32bit Windows
on a 64bit Windows. A strange folder name choice again: you'll find 32bit stuff in here, and the folder name
ends with "...64". Sigh. However, when you fire up the cmd.exe there and look at the PROCESSOR_ARCHITECTURE
environment variable via "set", you'll find it it to be set to "x86".
I am running WINDZ 0.1.0, and for it, I had archived the release notes, here they are:
The commandline that works for me is:
I've attached my instance of windz.exe to this post.
Note that Win7 64bit offers 2 variants of cmd.exe:
The default 64bit instance, located at C:\Windows\System32 (or wherever you installed windows).
And yes, it is located in the "System32" folder for backwards compatibility, although IMHO it better should
live in "System64". You can determine that it's this 64bit instance you're running by issuing the "set" command
and look at the PROCESSOR_ARCHITECTURE environment variable. It will display some 64ish setting within
the 64bit version of cmd.exe.
And there's the 32bit instance, located in C:\Windows\SysWOW64. This strange folder name means
"Windows on Windows 64", meaning that it contains all 32bit executables, for "emulating" a 32bit Windows
on a 64bit Windows. A strange folder name choice again: you'll find 32bit stuff in here, and the folder name
ends with "...64". Sigh. However, when you fire up the cmd.exe there and look at the PROCESSOR_ARCHITECTURE
environment variable via "set", you'll find it it to be set to "x86".
I am running WINDZ 0.1.0, and for it, I had archived the release notes, here they are:
Code:
Windz Release 0.1.0
NAME
windz
SYNOPSIS
windz [ options ] filename
OPTIONS
-d
Debug mode.
Windz will expand the dat file. It will only contain triangles
and quads with three colors:
Green: The polygon was not modified;
Red: The polygon was modified;
Blue: Windz couldn't figure out what is the correct winding for this polygon.
-n Initials
When correcting parts, windz includes one line of the type:
0 2002-08-31 ZAN Modified with WINDZ for BFC compliance
Use this option to make windz put your initials in this line.
For instance, if your name is Ole Kirk Christiansen, you can put the
option -nOKC and windz will generate a line like this:
0 1932-08-16 OKC Modified with WINDZ for BFC compliance
-h
Prints help.
OUTPUT
All Windz output will be sent to the standard output, so,
if you want to see what windz is doing, use the '>' to redirect the
standard output to a file.
Ex: windz 3001.dat > z3001.dat
TERMS OF USE
Windz is a free program. The only requirement is that you
submit the part with the information line that it generates:
0 2002-08-31 ZAN Modified with WINDZ for BFC compliance
You can change the initials in the line using the -n option.
TODO
0001 Improve performace: Some kind of bounding-box algorithm needs to be implemented.
0002 Output to file: Create a new option that enables windz to send
the output directly to a file without using '>'.
KNOWN BUGS
0001 Incorrect output when handling files that contain bad vertex sequence or concave quads.
---------------------------------------------------------------------
Windz Copyright (C) 2002 by Ildefonso Junior Zanette <[email protected]>
The commandline that works for me is:
Code:
windz.exe input.dat > output.dat