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.
- Jonathan M Davis
--
Dmitry Olshansky
