On Monday, September 26, 2011 16:07 Dmitry Olshansky wrote: > On 27.09.2011 2:33, Jonathan M Davis wrote: > > On Monday, September 26, 2011 14:53 Steven Schveighoffer wrote: > >> On Mon, 26 Sep 2011 17:35:20 -0400, Mehrdad<[email protected]> wrote: > >>> On 9/26/2011 2:30 PM, Mehrdad wrote: > >>>> On 9/26/2011 1:51 PM, Steven Schveighoffer wrote: > >>>>> AHA! > >>>>> > >>>>> Yes, there is a bug in snn.lib regarding pipes. And I fixed it, > >>>>> waiting for Walter to incorporate it :) I needed it for the new > >>>>> std.process. > >>>>> > >>>>> What it comes down to is, DMC's FILE * implementation does not expect > >>>>> some of the quirks of pipe HANDLEs. For instance, if you open a FILE > >>>>> * around a pipe handle, it still tries to do a seek on that handle, > >>>>> and crashes. Also, when the write end of a pipe is closed, reading > >>>>> from the read end results in EPIPE from ReadFile, but this is > >>>>> translated to EBADF by the runtime. Therefore, FILE * sets an error > >>>>> instead of EOF. > >>>>> > >>>>> Is the email address you have for this message correct? If so, I can > >>>>> send you a new version of snn.lib to try linking your code against > >>>>> (if you are willing to go through these steps), to see if it fixes > >>>>> your problem. > >>>>> > >>>>> Using the command line dmd to build should be sufficient (I think). > >>>>> > >>>>> -Steve > >>>> > >>>> Thanks for the email. > >>>> > >>>> It seems like it still crashes from SciTE, though. :( > >>>> When I try debugging, I see it's doing so inside _close() which is > >>>> /immediately/ above kernel32.dll!@BaseThreadInitThunk@12() -- in other > >>>> words, it seems to be called directly from the entrypoint of the > >>>> program, assuming it hasn't undergone optimizations. The error is: > >>>> 0xC0000008: An invalid handle was specified. > >>>> > >>>> Is there any other place in which this can happen? > >>> > >>> Also, now that we're on the topic... this might or might not sound > >>> silly, but why not just use msvcrt.dll (if not the whole library, at > >>> least the I/O functions)? It's not like it introduces a new dependency > >>> (it's already in every version of Windows) and it's also proven to > >>> work. Not to mention that it reduces code size as well... > >> > >> I think the reason Walter always gives is that dmd would then have to > >> output COFF objects, whereas it currently outputs OMF. OPTLINK also does > >> not accept COFF objects. > >> > >> I think a lot of people would very much welcome this change, but it's > >> somewhat of an underwhelming change. Instead of using DMC's runtime for > >> C functions, you are using VC++'s runtime. But who cares? I want D's > >> runtime to be better :) > > > > The gain in switching to COFF would be _huge_, because then D code would > > be properly interoperable with most of the C code on Windows - and in > > particular C code compiled with Microsoft's compiler. The only thing > > saving the current situation from being a complete disaster is that you > > can still use dlls. > > It's not that easy. I mean to gain this level of compatibility we'd have > to do both: switch to MS runtime and use COFF object format. Linking > together two C runtimes is *ehm* tricky. > > But most importantly newer versions of VC++ use newer runtimes, I'm not > sure how compatible they are, but judging by my previous experience - > you still has to keep things separated like in DLLs and never mix > allocation/FILE* stuff between them.
That may be, but the fact that I can't just link C code built with Visual Studio with D code is a major problem in enviroments where Visual Studio is what is used on Windows (such as where I work). In comparison, in Linux it works, because dmd actually uses the compiler which is the de facto standard on Linux - gcc. But since dmd uses optlink on Windows, you just don't have that level of compatibility. dmc and optlink may very well be solid tools, but as a D programmer trying to interoperate with C code, compatability matters a lot, and dmd on Windows just doesn't have it. - Jonathan M Davis
