Is the Latest Release of Cygwin supported on Windows Server 8/2012

Andrew DeFaria
Sat May 19 03:26:00 GMT 2012

On 05/18/2012 07:39 PM, JonY wrote:
>> I was under the impression that the instruction size matches the natural
>> word size of the machine. Therefore they would be 64 bit instructions.
> No, we are talking about x86, not MIPS/ARM type RISC.
Really? OK - Show me! Because the first mention of even CISC was *your* 
posting two posts ago. Just because you were talking about x86 does not 
mean that I was talking about x86.
> Which do not apply to CISC CPUs, whatever implementation underneath is
> tangent to the user code ISA, the opcodes did not double in size. Please
> at least look at the x86 opcode, they are known to have variable lengths.
I was not talking about your x86 - you were.
>> I still don't understand what having a 64 bit version of ls or grep will
>> do for ya...
> Since 64-bit mode cannot be avoided,
Excuse me but it seems to me that right now it is being avoided quite 
successfully. Cannot be avoided? Really?
> there is simply no reason to keep
> legacy mode applications and all that baggage if you can easily rebuild
> and move to 64-bit mode.
If a 32 bit executable will run on a 64 bit machine, but a 64 bit 
executable will not run on a 32 bit machine, there's no good 
justification to have to maintain two different builds and sets of bits.
> You don't keep 16-bit programs lying about when there are 32-bit
> programs doing the same thing right?
When 32 bit just came around, you betcha I did - and so did you.

All that said, I'd like to see it all move to 64 bit and I know it will, 
eventually. But I can understand the rational for not doing it at this time.
Andrew DeFaria <>
I'm not into working out. My philosophy is no pain, no pain.

Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list