"Bernard Helyer" <b.hel...@gmail.com> wrote in message news:nlzougvwvlvnmjbuf...@forum.dlang.org... > > No one thinks that's a bad idea. The trouble is the amount of developers > that actually understand the backend enough to implement another object > format (which is what's needed to support the VisualC linker) is very > small. > > What's needed is someone to take the time to learn it then do it. Someone > motivated, and smart. Not unlike yourself! :P >
The problem isn't really the backend - there are currently _three_ full object file generators in dmd and it should be possible to use the same interfaces these do without caring what most of the backend is really doing. Generating Microsoft coff objects means deciphering the spec to see what everything should look like, generating every kind of entry with msvc to see what it _actually_ does, then translating all the record/fixup/section types from omf to the coff equivalents. With this (and maybe updates to the runtime to use msvc's instead of dmc's c runtime) you have 32 bit coff on windows. To get from there to 64bit, you need the following: - 64 bit coff (I think these are closely related) - 64 bit c runtime (just use microsofts?) - 64 bit d runtime (eh, io with a different runtime, etc) - 64 bit codegen (hopefully not much more than some calling convention stuff) - 64 bit linker (Again, just use ms?) Just generating coff is a pretty big step, it requires learning how object formats work (I don't think many people already have the depth of understanding required), how coff works and how dmd generates object files (which probably means understanding omf/elf/mach). The only person I can think of who would even know how long it would take to learn all this is Walter, and considering that he's hasn't done it already, I'd guess it's quite a huge task. Walter, how big is it really? Small enough to be done as, say, a gsoc project? Would you be interested in mentoring such a project?