Just got back from a business trip and have made it through my mail...
One other potential option *might* be to use a combination of Cygnus'
Win32 tools and Microsoft's? I don't know a lot about it, but there is
the objcopy utility in the binutils package. In the Win32 version, it
appears to know both of the relevant object formats. I don't know a lot
about all of the various tools, but it seems that it might be possible
to use cygwin to compile the assembly portions and then convert to the
appropriate object format using objcopy. From there, VC++ could be used
to compile the rest and link it. Does this sound crazy? Is there
anyone that knows more about this? If that is even possible, we are
going to need to have anything that might not be compilable by VC++
placed into separate source files and handled differently by the make
files.
Craig
"Kevin P. Lawton" wrote:
>
> Sid Karnik wrote:
> >
> > does that imply that we will need to use a different code base for the win32
> > port? or can we get by by simply a #ifdef WIN32 thingie.
> >
> > we would certainly get into trouble with any assembly stuff, since both vc++
> > as well as masm use 'intel' style instructions.
> >
> > i guess the only way to find out if mingw32 does the job is to actually try
> > and compile a driver and see if it works ok on an nt box.
>
> There should only be a reasonably small amount of assembly code
> needed. For the small snippets, perhaps we could use macros.
>
> For whole functions in assembly, maybe some #ifdefs.
>
> Anyways, for now, gcc/asm is fine. Function is more
> important than portability currently.
>
> -Kevin
