I'm hoping that someone can help me with this simple problem.

I'm using NASM 2.07 on winxp x64 trying to create a 64 bit ASM exe and
I am getting this message:
"Thie program or feature" "xxxxx" cannot run or start due to
incompatibility with 64-bit versions or Windows....."

I have tried 32 bit and 64 bit mode and linking with gcc, but whatever
I do i get this message.

Here is the helloworld code:

; tiny.asm
  BITS 64
  GLOBAL main
  SECTION .text
  main:
                mov     eax, 42   ;; this has also been tried with mov
rax, 42 the equiv 64 bit instr
                ret

Compiled with
nasm -f win64 -o tiny.exe tiny.asm

Please tell me what simple mistake I'm making as the program does
attempt to execute under win32??

Also Windows7 x64 produces the same error?

On 12/21/2009 06:20 PM, oraclerob wrote:
> 
> Compiled with
> nasm -f win64 -o tiny.exe tiny.asm
> 

That's not linking...

	-hpa

oraclerob wrote:
> I'm hoping that someone can help me with this simple problem.
> 
> I'm using NASM 2.07 on winxp x64 trying to create a 64 bit ASM exe and
> I am getting this message:
> "Thie program or feature" "xxxxx" cannot run or start due to
> incompatibility with 64-bit versions or Windows....."
> 
> I have tried 32 bit and 64 bit mode and linking with gcc, but whatever
> I do i get this message.
> 
> Here is the helloworld code:
> 
> ; tiny.asm
>   BITS 64
>   GLOBAL main
>   SECTION .text
>   main:
>                 mov     eax, 42   ;; this has also been tried with mov
> rax, 42 the equiv 64 bit instr
>                 ret
> 
> Compiled with
> nasm -f win64 -o tiny.exe tiny.asm
> 
> Please tell me what simple mistake I'm making

You don't want "-o tiny.exe" here. You want Nasm to produce "tiny.obj" 
(which it will do by default, you don't need the "-o" switch unless you 
want a different name). Then, you should be able to link this with "gcc 
-o tiny.exe tiny.obj". I'm not familiar with win64, so there *may* be 
more to it, but I think that'll solve it.

> as the program does
> attempt to execute under win32??

Win32 probably thinks it's a .com file. If executing the COFF header 
doesn't crash it, it might even work!

> Also Windows7 x64 produces the same error?

Yeah, "-f win32" and "-f win64" both produce linkable object files... 
which need to be linked into an .exe. It is possible to produce an .exe 
directly by writing your own executable header and assembling with "-f 
bin", but you don't want to do it (probably).

Best,
Frank

On Dec 22, 11:13=A0am, Frank Kotler <fbkot...@MUNGED.microcosmotalk.com>
wrote:
> oraclerob wrote:
> > I'm hoping that someone can help me with this simple problem.
>
> > I'm using NASM 2.07 on winxp x64 trying to create a 64 bit ASM exe and
> > I am getting this message:
> > "Thie program or feature" "xxxxx" cannot run or start due to
> > incompatibility with 64-bit versions or Windows....."
>
> > I have tried 32 bit and 64 bit mode and linking with gcc, but whatever
> > I do i get this message.
>
> > Here is the helloworld code:
>
> > ; tiny.asm
> > =A0 BITS 64
> > =A0 GLOBAL main
> > =A0 SECTION .text
> > =A0 main:
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 =A0 eax, 42 =A0 ;; this has als=
o been tried with mov
> > rax, 42 the equiv 64 bit instr
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret
>
> > Compiled with
> > nasm -f win64 -o tiny.exe tiny.asm
>
> > Please tell me what simple mistake I'm making
>
> You don't want "-o tiny.exe" here. You want Nasm to produce "tiny.obj"
> (which it will do by default, you don't need the "-o" switch unless you
> want a different name). Then, you should be able to link this with "gcc
> -o tiny.exe tiny.obj". I'm not familiar with win64, so there *may* be
> more to it, but I think that'll solve it.
>
> > as the program does
> > attempt to execute under win32??
>
> Win32 probably thinks it's a .com file. If executing the COFF header
> doesn't crash it, it might even work!
>
> > Also Windows7 x64 produces the same error?
>
> Yeah, "-f win32" and "-f win64" both produce linkable object files...
> which need to be linked into an .exe. It is possible to produce an .exe
> directly by writing your own executable header and assembling with "-f
> bin", but you don't want to do it (probably).
>
> Best,
> Frank

Thansk for the quick response, yep a I mentioned I did try this
already with gcc but produces the same result. I'm aware of the
linking need for assembled objects.

d:\cygwin\bin\gcc-3 tiny.o -o tiny.exe

Can someone give me step by step instructions to let me know what
mistakes I'm making?

Sorry guys I haven't done this since 16 bit MASM under DOS so am very
rusty on the specifics of producing an EXE,
As I said in my first post, that is exactly what I did. I produced an
obj file and did try to link using gcc-3 like this:
nasm -f win64 -o tiny.o tiny.asm
d:\cygwin\bin\gcc-3 tiny.o -o tiny.exe

This should have produced a runnable exe I would have thought, but no,
the same error occurs. I know I'm missing a lot of stuff here so
please be kind and lead me in the write direction.



On Dec 22, 11:13=A0am, Frank Kotler <fbkot...@MUNGED.microcosmotalk.com>
wrote:
> oraclerob wrote:
> > I'm hoping that someone can help me with this simple problem.
>
> > I'm using NASM 2.07 on winxp x64 trying to create a 64 bit ASM exe and
> > I am getting this message:
> > "Thie program or feature" "xxxxx" cannot run or start due to
> > incompatibility with 64-bit versions or Windows....."
>
> > I have tried 32 bit and 64 bit mode and linking with gcc, but whatever
> > I do i get this message.
>
> > Here is the helloworld code:
>
> > ; tiny.asm
> > =A0 BITS 64
> > =A0 GLOBAL main
> > =A0 SECTION .text
> > =A0 main:
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 =A0 eax, 42 =A0 ;; this has als=
o been tried with mov
> > rax, 42 the equiv 64 bit instr
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret
>
> > Compiled with
> > nasm -f win64 -o tiny.exe tiny.asm
>
> > Please tell me what simple mistake I'm making
>
> You don't want "-o tiny.exe" here. You want Nasm to produce "tiny.obj"
> (which it will do by default, you don't need the "-o" switch unless you
> want a different name). Then, you should be able to link this with "gcc
> -o tiny.exe tiny.obj". I'm not familiar with win64, so there *may* be
> more to it, but I think that'll solve it.
>
> > as the program does
> > attempt to execute under win32??
>
> Win32 probably thinks it's a .com file. If executing the COFF header
> doesn't crash it, it might even work!
>
> > Also Windows7 x64 produces the same error?
>
> Yeah, "-f win32" and "-f win64" both produce linkable object files...
> which need to be linked into an .exe. It is possible to produce an .exe
> directly by writing your own executable header and assembling with "-f
> bin", but you don't want to do it (probably).
>
> Best,
> Frank

Ok, so I figured out how to create an win32 exe but still having
problems linking x64. Code as such for win32
; tiny.asm
  BITS 32
  GLOBAL main
  SECTION .text
  main:
                mov     eax, 42
                ret

nasm -fwin32 -o tiny.o tiny.asm

Then used cygwin ld as such (I also used alink which also works)
d:\cygwin\bin\ld -o tiny.exe tiny.o


Ok, so now have a properly linked runnable exe but only 32bit. I have
tried changing the BITS 64 directive and creating an object file
successfully but I'm not sure which linker I could use to produce a
pure 64 bit executable. Anyone know if there is a directive to the
linker or another linker I could use as alink and cygwin ld seem to be
only 32 bit?




On Dec 22, 7:16=A0pm, oraclerob <rob.masc...@MUNGED.microcosmotalk.com>
wrote:
> Sorry guys I haven't done this since 16 bit MASM under DOS so am very
> rusty on the specifics of producing an EXE,
> As I said in my first post, that is exactly what I did. I produced an
> obj file and did try to link using gcc-3 like this:
> nasm -f win64 -o tiny.o tiny.asm
> d:\cygwin\bin\gcc-3 tiny.o -o tiny.exe
>
> This should have produced a runnable exe I would have thought, but no,
> the same error occurs. I know I'm missing a lot of stuff here so
> please be kind and lead me in the write direction.
>
> On Dec 22, 11:13=A0am, Frank Kotler <fbkot...@MUNGED.microcosmotalk.com>
> wrote:
>
> > oraclerob wrote:
> > > I'm hoping that someone can help me with this simple problem.
>
> > > I'm using NASM 2.07 on winxp x64 trying to create a 64 bit ASM exe an=
d
> > > I am getting this message:
> > > "Thie program or feature" "xxxxx" cannot run or start due to
> > > incompatibility with 64-bit versions or Windows....."
>
> > > I have tried 32 bit and 64 bit mode and linking with gcc, but whateve=
r
> > > I do i get this message.
>
> > > Here is the helloworld code:
>
> > > ; tiny.asm
> > > =A0 BITS 64
> > > =A0 GLOBAL main
> > > =A0 SECTION .text
> > > =A0 main:
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 =A0 eax, 42 =A0 ;; this has a=
lso been tried with mov
> > > rax, 42 the equiv 64 bit instr
> > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret
>
> > > Compiled with
> > > nasm -f win64 -o tiny.exe tiny.asm
>
> > > Please tell me what simple mistake I'm making
>
> > You don't want "-o tiny.exe" here. You want Nasm to produce "tiny.obj"
> > (which it will do by default, you don't need the "-o" switch unless you
> > want a different name). Then, you should be able to link this with "gcc
> > -o tiny.exe tiny.obj". I'm not familiar with win64, so there *may* be
> > more to it, but I think that'll solve it.
>
> > > as the program does
> > > attempt to execute under win32??
>
> > Win32 probably thinks it's a .com file. If executing the COFF header
> > doesn't crash it, it might even work!
>
> > > Also Windows7 x64 produces the same error?
>
> > Yeah, "-f win32" and "-f win64" both produce linkable object files...
> > which need to be linked into an .exe. It is possible to produce an .exe
> > directly by writing your own executable header and assembling with "-f
> > bin", but you don't want to do it (probably).
>
> > Best,
> > Frank
>
>

"oraclerob" <rob.mascaro@MUNGED.microcosmotalk.com> wrote in message 
news:4b30d447$0$4941$9a6e19ea@unlimited.newshosting.com...

> Ok, so now have a properly linked runnable exe but only 32bit. I have
> tried changing the BITS 64 directive and creating an object file
> successfully but I'm not sure which linker I could use to produce a
> pure 64 bit executable. Anyone know if there is a directive to the
> linker or another linker I could use as alink and cygwin ld seem to be
> only 32 bit?

I don't think cygwin has gone the 64-bit route as yet.  Instead,
there are a couple of toolchains that have a 64-bit capable ld.exe:

There is the MinGW 64 project:

http://sourceforge.net/projects/mingw-w64/

Also there is someone who builds g++ and gfortran for x64:

http://www.equation.com/

This last link seems to provide tools that work more consistently.

You can also get link.exe from Microsoft when you download their
toolset.  You might have to download more than one toolset to get
what you want, but link.exe is perhaps the easiest to use linker.

Also GoAsm comes with a linker, GoLink.exe:

http://www.jorgon.freeserve.co.uk/

Good luck in 64 bits!

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

"oraclerob" <rob.mascaro@MUNGED.microcosmotalk.com> wrote in message 
news:4b30d447$0$4941$9a6e19ea@unlimited.newshosting.com...

<--
Ok, so I figured out how to create an win32 exe but still having
problems linking x64. Code as such for win32
; tiny.asm
  BITS 32
  GLOBAL main
  SECTION .text
  main:
                mov     eax, 42
                ret

nasm -fwin32 -o tiny.o tiny.asm

Then used cygwin ld as such (I also used alink which also works)
d:\cygwin\bin\ld -o tiny.exe tiny.o


Ok, so now have a properly linked runnable exe but only 32bit. I have
tried changing the BITS 64 directive and creating an object file
successfully but I'm not sure which linker I could use to produce a
pure 64 bit executable. Anyone know if there is a directive to the
linker or another linker I could use as alink and cygwin ld seem to be
only 32 bit?

-->

Cygwin's ld is only 32-bits.


possibilities:
getting MinGW-w64, which has a 64 bit version of the tools;
getting the Windows SDK (formerly Platform SDK), and using LINK.


as-is, I am mostly using the Windows SDK for 64-bit code, as, at the time I 
had looked at MinGW-w64, the compiler seemed to have a few codegen bugs, 
although likely the situation will have improved since then...

On 22 Dec, 14:14, oraclerob <rob.masc...@MUNGED.microcosmotalk.com>
wrote:

> Ok, so I figured out how to create an win32 exe but still having
> problems linking x64. Code as such for win32
> ; tiny.asm
> =A0 BITS 32
> =A0 GLOBAL main
> =A0 SECTION .text
> =A0 main:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 =A0 eax, 42
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret
>
> nasm -fwin32 -o tiny.o tiny.asm
>
> Then used cygwin ld as such (I also used alink which also works)
> d:\cygwin\bin\ld -o tiny.exe tiny.o
>
> Ok, so now have a properly linked runnable exe but only 32bit. I have
> tried changing the BITS 64 directive and creating an object file
> successfully but I'm not sure which linker I could use to produce a
> pure 64 bit executable. Anyone know if there is a directive to the
> linker or another linker I could use as alink and cygwin ld seem to be
> only 32 bit?

For Windows-64 it looks like there are two good options. Though I've
not tried either of them they appear to be complete.

1. Win64 SDK linker
2. Go linker <http://www.jorgon.freeserve.co.uk/#64>

I'm surprised to hear that ld under Cygwin produces Windows
executables.

BTW, top posts are unusual in Usenet and should be avoided.

James

On Dec 23, 8:42=A0am, James Harris
<james.harri...@MUNGED.microcosmotalk.com> wrote:
> On 22 Dec, 14:14, oraclerob <rob.masc...@MUNGED.microcosmotalk.com>
> wrote:
>
>
>
> > Ok, so I figured out how to create an win32 exe but still having
> > problems linking x64. Code as such for win32
> > ; tiny.asm
> > =3DA0 BITS 32
> > =3DA0 GLOBAL main
> > =3DA0 SECTION .text
> > =3DA0 main:
> > =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 mov =3DA0 =3DA0 eax, 42
> > =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 ret
>
> > nasm -fwin32 -o tiny.o tiny.asm
>
> > Then used cygwin ld as such (I also used alink which also works)
> > d:\cygwin\bin\ld -o tiny.exe tiny.o
>
> > Ok, so now have a properly linked runnable exe but only 32bit. I have
> > tried changing the BITS 64 directive and creating an object file
> > successfully but I'm not sure which linker I could use to produce a
> > pure 64 bit executable. Anyone know if there is a directive to the
> > linker or another linker I could use as alink and cygwin ld seem to be
> > only 32 bit?
>
> For Windows-64 it looks like there are two good options. Though I've
> not tried either of them they appear to be complete.
>
> 1. Win64 SDK linker
> 2. Go linker <http://www.jorgon.freeserve.co.uk/#64>
>
> I'm surprised to hear that ld under Cygwin produces Windows
> executables.
>
> BTW, top posts are unusual in Usenet and should be avoided.
>
> James

Thanks James (and all other posters), I ended up using MinGW64 linker
and got it working successfully with the following helloworld

; tiny.asm
  BITS 64
  GLOBAL main
  SECTION .text
  main:
                mov     rax, 42
                ret

nasm -fwin64 -o tiny.o tiny.asm

x86_64-w64-mingw32-ld.exe -o tiny.exe tiny.o

Great, finally got to test pure 64 bit assembled and linked code. I
also had Visual Studio 2008 installed which has a link.exe but I
haven't been able to figure out how to enable a pure 64 bit compile as
i think I'm missing some runtime 64 framework tools. That's another
story...

For James being surprised at cygwin ld working? I've always found the
cygwin gcc port to be first class and see no reason why the ld should
be any different, but for all others out there this is also a good
option if like me, you might be moving between unix and windows. Guys
thanks for all the help.

"oraclerob" <rob.mascaro@MUNGED.microcosmotalk.com> wrote in message 
news:4b3180e8$0$4968$9a6e19ea@unlimited.newshosting.com...

On Dec 23, 8:42 am, James Harris
<james.harri...@MUNGED.microcosmotalk.com> wrote:
> On 22 Dec, 14:14, oraclerob <rob.masc...@MUNGED.microcosmotalk.com>
> wrote:
>
>
>
> > Ok, so I figured out how to create an win32 exe but still having
> > problems linking x64. Code as such for win32
> > ; tiny.asm
> > =A0 BITS 32
> > =A0 GLOBAL main
> > =A0 SECTION .text
> > =A0 main:
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 =A0 eax, 42
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret
>
> > nasm -fwin32 -o tiny.o tiny.asm
>
> > Then used cygwin ld as such (I also used alink which also works)
> > d:\cygwin\bin\ld -o tiny.exe tiny.o
>
> > Ok, so now have a properly linked runnable exe but only 32bit. I have
> > tried changing the BITS 64 directive and creating an object file
> > successfully but I'm not sure which linker I could use to produce a
> > pure 64 bit executable. Anyone know if there is a directive to the
> > linker or another linker I could use as alink and cygwin ld seem to be
> > only 32 bit?
>
> For Windows-64 it looks like there are two good options. Though I've
> not tried either of them they appear to be complete.
>
> 1. Win64 SDK linker
> 2. Go linker <http://www.jorgon.freeserve.co.uk/#64>
>
> I'm surprised to hear that ld under Cygwin produces Windows
> executables.
>
> BTW, top posts are unusual in Usenet and should be avoided.
>
> James

<--
Thanks James (and all other posters), I ended up using MinGW64 linker
and got it working successfully with the following helloworld

; tiny.asm
  BITS 64
  GLOBAL main
  SECTION .text
  main:
                mov     rax, 42
                ret

nasm -fwin64 -o tiny.o tiny.asm

x86_64-w64-mingw32-ld.exe -o tiny.exe tiny.o

Great, finally got to test pure 64 bit assembled and linked code. I
also had Visual Studio 2008 installed which has a link.exe but I
haven't been able to figure out how to enable a pure 64 bit compile as
i think I'm missing some runtime 64 framework tools. That's another
story...
-->

if it is "Visual Studio Express 2008" (rather than simply "Visual Studio 
2008"), then it can be noted that VS Express does not support 64 bits (I 
suspect as a ploy to get people to pay money for it).

what was in question was the Windows SDK, which typically comes with tools 
and libraries for 64-bit devel, but the only interface it gives is the CMD 
prompt (AKA: DOS prompt, except that it modern Windows no DOS need be 
involved).

with a little fudging, I was able to make most of the Cygwin tools 
accessible from the CMD shell (since notably MS's tools don't exactly work 
via BASH), and this turned out reasonably well.


<--
For James being surprised at cygwin ld working? I've always found the
cygwin gcc port to be first class and see no reason why the ld should
be any different, but for all others out there this is also a good
option if like me, you might be moving between unix and windows. Guys
thanks for all the help.
-->

yeah, I use Cygwin some as well, but I switch between Cygwin, MinGW, and 
MSVC, depending on what it is I am doing.

I use Cygwin usually for tools, such as command-line tools, ...
I use MinGW mostly for 32-bit apps (since Cygwin introduces a few "issues" 
when used for apps);
I use MSVC mostly for 64-bit devel, since it does this fairly well 
(nevermind its optimizer...).


as for 32 vs 64 bits:
64 bits is good for messing with, and also gives a big expansive address 
space, ...
however, at the present moment, 32-bits is probably still better as far as 
performance goes.

On Dec 24, 5:05=A0am, "BGB / cr88192"
<cr88...@MUNGED.microcosmotalk.com> wrote:
> "oraclerob" <rob.masc...@MUNGED.microcosmotalk.com> wrote in message
>
> news:4b3180e8$0$4968$9a6e19ea@unlimited.newshosting.com...
>
> On Dec 23, 8:42 am, James Harris
>
>
>
> <james.harri...@MUNGED.microcosmotalk.com> wrote:
> > On 22 Dec, 14:14, oraclerob <rob.masc...@MUNGED.microcosmotalk.com>
> > wrote:
>
> > > Ok, so I figured out how to create an win32 exe but still having
> > > problems linking x64. Code as such for win32
> > > ; tiny.asm
> > > =3DA0 BITS 32
> > > =3DA0 GLOBAL main
> > > =3DA0 SECTION .text
> > > =3DA0 main:
> > > =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 mov =3DA0 =3DA0 eax, =
42
> > > =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 ret
>
> > > nasm -fwin32 -o tiny.o tiny.asm
>
> > > Then used cygwin ld as such (I also used alink which also works)
> > > d:\cygwin\bin\ld -o tiny.exe tiny.o
>
> > > Ok, so now have a properly linked runnable exe but only 32bit. I have
> > > tried changing the BITS 64 directive and creating an object file
> > > successfully but I'm not sure which linker I could use to produce a
> > > pure 64 bit executable. Anyone know if there is a directive to the
> > > linker or another linker I could use as alink and cygwin ld seem to b=
e
> > > only 32 bit?
>
> > For Windows-64 it looks like there are two good options. Though I've
> > not tried either of them they appear to be complete.
>
> > 1. Win64 SDK linker
> > 2. Go linker <http://www.jorgon.freeserve.co.uk/#64>
>
> > I'm surprised to hear that ld under Cygwin produces Windows
> > executables.
>
> > BTW, top posts are unusual in Usenet and should be avoided.
>
> > James
>
> <--
> Thanks James (and all other posters), I ended up using MinGW64 linker
> and got it working successfully with the following helloworld
>
> ; tiny.asm
> =A0 BITS 64
> =A0 GLOBAL main
> =A0 SECTION .text
> =A0 main:
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 =A0 rax, 42
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret
>
> nasm -fwin64 -o tiny.o tiny.asm
>
> x86_64-w64-mingw32-ld.exe -o tiny.exe tiny.o
>
> Great, finally got to test pure 64 bit assembled and linked code. I
> also had Visual Studio 2008 installed which has a link.exe but I
> haven't been able to figure out how to enable a pure 64 bit compile as
> i think I'm missing some runtime 64 framework tools. That's another
> story...
> -->
>
> if it is "Visual Studio Express 2008" (rather than simply "Visual Studio
> 2008"), then it can be noted that VS Express does not support 64 bits (I
> suspect as a ploy to get people to pay money for it).
>
> what was in question was the Windows SDK, which typically comes with tool=
s
> and libraries for 64-bit devel, but the only interface it gives is the CM=
D
> prompt (AKA: DOS prompt, except that it modern Windows no DOS need be
> involved).
>
> with a little fudging, I was able to make most of the Cygwin tools
> accessible from the CMD shell (since notably MS's tools don't exactly wor=
k
> via BASH), and this turned out reasonably well.
>
> <--
> For James being surprised at cygwin ld working? I've always found the
> cygwin gcc port to be first class and see no reason why the ld should
> be any different, but for all others out there this is also a good
> option if like me, you might be moving between unix and windows. Guys
> thanks for all the help.
> -->
>
> yeah, I use Cygwin some as well, but I switch between Cygwin, MinGW, and
> MSVC, depending on what it is I am doing.
>
> I use Cygwin usually for tools, such as command-line tools, ...
> I use MinGW mostly for 32-bit apps (since Cygwin introduces a few "issues=
"
> when used for apps);
> I use MSVC mostly for 64-bit devel, since it does this fairly well
> (nevermind its optimizer...).
>
> as for 32 vs 64 bits:
> 64 bits is good for messing with, and also gives a big expansive address
> space, ...
> however, at the present moment, 32-bits is probably still better as far a=
s
> performance goes.

I figured out that the "default" install of Visual Studio 2008 does
not install x64 compiler, even though I'm running winxp x64. So popped
the disk back in and select 64 bit compiler and problem solved. I use
all the cygwin tools from the cmd.exe shell, including gcc and have
had no problems so far. Take your point completely about 64 bit asm
being complete overkill, I just wanted to prove to myself it can be
done.

If you have something other than the Express version of VS 2008, you
can have the C RTL source code installed.  It includes many asm files
for functions such as memset.  That can provide the information for
writing the framework to interface with the C/C++ compiler's output.

On 24 Dec 2009 01:52:29 GMT, oraclerob
<rob.mascaro@MUNGED.microcosmotalk.com> wrote:

>
>On Dec 24, 5:05=A0am, "BGB / cr88192"
><cr88...@MUNGED.microcosmotalk.com> wrote:
>> "oraclerob" <rob.masc...@MUNGED.microcosmotalk.com> wrote in message
>>
>> news:4b3180e8$0$4968$9a6e19ea@unlimited.newshosting.com...
>>
>> On Dec 23, 8:42 am, James Harris
>>
>>
>>
>> <james.harri...@MUNGED.microcosmotalk.com> wrote:
>> > On 22 Dec, 14:14, oraclerob <rob.masc...@MUNGED.microcosmotalk.com>
>> > wrote:
>>
>> > > Ok, so I figured out how to create an win32 exe but still having
>> > > problems linking x64. Code as such for win32
>> > > ; tiny.asm
>> > > =3DA0 BITS 32
>> > > =3DA0 GLOBAL main
>> > > =3DA0 SECTION .text
>> > > =3DA0 main:
>> > > =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 mov =3DA0 =3DA0 =
eax, 42
>> > > =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 =3DA0 ret
>>
>> > > nasm -fwin32 -o tiny.o tiny.asm
>>
>> > > Then used cygwin ld as such (I also used alink which also works)
>> > > d:\cygwin\bin\ld -o tiny.exe tiny.o
>>
>> > > Ok, so now have a properly linked runnable exe but only 32bit. I =
have
>> > > tried changing the BITS 64 directive and creating an object file
>> > > successfully but I'm not sure which linker I could use to produce =
a
>> > > pure 64 bit executable. Anyone know if there is a directive to the
>> > > linker or another linker I could use as alink and cygwin ld seem =
to be
>> > > only 32 bit?
>>
>> > For Windows-64 it looks like there are two good options. Though I've
>> > not tried either of them they appear to be complete.
>>
>> > 1. Win64 SDK linker
>> > 2. Go linker <http://www.jorgon.freeserve.co.uk/#64>
>>
>> > I'm surprised to hear that ld under Cygwin produces Windows
>> > executables.
>>
>> > BTW, top posts are unusual in Usenet and should be avoided.
>>
>> > James
>>
>> <--
>> Thanks James (and all other posters), I ended up using MinGW64 linker
>> and got it working successfully with the following helloworld
>>
>> ; tiny.asm
>> =A0 BITS 64
>> =A0 GLOBAL main
>> =A0 SECTION .text
>> =A0 main:
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 mov =A0 =A0 rax, 42
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret
>>
>> nasm -fwin64 -o tiny.o tiny.asm
>>
>> x86_64-w64-mingw32-ld.exe -o tiny.exe tiny.o
>>
>> Great, finally got to test pure 64 bit assembled and linked code. I
>> also had Visual Studio 2008 installed which has a link.exe but I
>> haven't been able to figure out how to enable a pure 64 bit compile as
>> i think I'm missing some runtime 64 framework tools. That's another
>> story...
>> -->
>>
>> if it is "Visual Studio Express 2008" (rather than simply "Visual =
Studio
>> 2008"), then it can be noted that VS Express does not support 64 bits =
(I
>> suspect as a ploy to get people to pay money for it).
>>
>> what was in question was the Windows SDK, which typically comes with =
tools
>> and libraries for 64-bit devel, but the only interface it gives is the=
 CMD
>> prompt (AKA: DOS prompt, except that it modern Windows no DOS need be
>> involved).
>>
>> with a little fudging, I was able to make most of the Cygwin tools
>> accessible from the CMD shell (since notably MS's tools don't exactly =
work
>> via BASH), and this turned out reasonably well.
>>
>> <--
>> For James being surprised at cygwin ld working? I've always found the
>> cygwin gcc port to be first class and see no reason why the ld should
>> be any different, but for all others out there this is also a good
>> option if like me, you might be moving between unix and windows. Guys
>> thanks for all the help.
>> -->
>>
>> yeah, I use Cygwin some as well, but I switch between Cygwin, MinGW, =
and
>> MSVC, depending on what it is I am doing.
>>
>> I use Cygwin usually for tools, such as command-line tools, ...
>> I use MinGW mostly for 32-bit apps (since Cygwin introduces a few =
"issues"
>> when used for apps);
>> I use MSVC mostly for 64-bit devel, since it does this fairly well
>> (nevermind its optimizer...).
>>
>> as for 32 vs 64 bits:
>> 64 bits is good for messing with, and also gives a big expansive =
address
>> space, ...
>> however, at the present moment, 32-bits is probably still better as =
far as
>> performance goes.
>
>I figured out that the "default" install of Visual Studio 2008 does
>not install x64 compiler, even though I'm running winxp x64. So popped
>the disk back in and select 64 bit compiler and problem solved. I use
>all the cygwin tools from the cmd.exe shell, including gcc and have
>had no problems so far. Take your point completely about 64 bit asm
>being complete overkill, I just wanted to prove to myself it can be
>done.