Re: Free FAT16 Filesystem

Hi Jon,

>Your desire that the modifications of your code be at least compatible
>with your compiler are quite reasonable. But since this has been
>aired now in public I've a couple of questions which I believe are
>fair to ask. (I'm in an ornery mood, this morning? Perhaps.)

>No need to answer them, if you feel that an extended discussion here
>is inappropriate -- in that case, these will just lay on the table, as
>it were:

I agree that this should be put to rest, however in the light of recent
activities, I will provide brief responses:

>(1) Who was the professional in this situation, Dave? I accept that
>Murray did not mention Keil in his correspondence to you. But why
>didn't you ask? It seems to me, an outsider of this relationship,
>that if something like this slips between the cracks, so to speak,
>then the fact that it did lays more to your error than his. His
>standard of care is less than yours, I believe. Of course, regardless
>of this question, I do think your position is a reasonable one. I'm
>just wondering how _you_ let this slip through without being asked.

For several reasons:

The inital contact came from the support channel on my web site, and
the individual identified himself as one of my customers - I did make
the error of assuming he was using my tools, as it was not indicated
otherwise.

The original MDCFS.C is very generic, not targeted to a particular
processor, and barely targeted at my tools (the disk read/write
examples given in the distribution are inline Micro-C/86 assembly,
but otherwise the program is fairly standard). It seemed reasonable
that he would keep it that way.

And frankly, it never occured to me ... I've granted use of bits of my
source code to hundreds of people (most anyone who asks), and this
is he first time someone has tried to lock my tools out of the results.

But your point is well taken, I will indeed be more dilligent in the future.


>(2) Let's say that Murray had, instead, developed a single set of
>source code from your FAT12 MDCFS code that was able to be compiled on
>both your compiler AND under Keil's, as well. In other words, it used
>#if type statements to allow it to compiler for either product. Would
>this then still remain a problem for you? In other words, would you
>_require_ that the result of Murray's efforts _also_ be incompatible
>with your competition? Because if that is the case, it seems to me to
>place an even greater emphasis on my first question.

I would not have a problem with that, in fact in correspondance with him
this morning, I suggested that either a) he could release it in a generic
form similar to the original code, or b) I would help him if required to make
it compatible with both toolsets. Unfortunately he has chosen to close that
door.


>I think the letter you presented was very clear and given that you had
>no idea that it was being ported to Keil as well as being enhanced,
>quite understandable. I'm just not sure why you let this one get so
>far away from your interest without ever asking a question that
>probably should have been asked. You are the professional one, held
>to the higher standard, in this partnership -- from my otherwise
>ignorant perspective.

Up until yesterday, it was all very friendly and I wasn't worried about it.
When I realized he had locked out my tools, I asked for it to be removed,
figuring that we would probably work something out later ...

Regarding your original question "Who was the professional in this situation?",
I can only say to please take a look at the comments that he has posted about
me on his web site and draw your own conclusion.

This is as far as this should go in a public forum - if anyone wishes futther
clairification of my position, please contact me privately.

Regards,

Dave

--
Dunfield Development Systems http://www.dunfield.com
Low cost software development tools for embedded systems
Software/firmware development services Fax:613-256-5821

.

Relevant Pages

  • Re: Microfocus COBOL 3.2.43 (16bit)
    ... Forgetting all the good reasons to move to something new, you don't have a lot of options. ... you could host it on a Windows Server or Windows Vista machine without any trouble. ... Build architecture is Windows NT4 SP4, Microfocus COBOL 3.2.43, Gupta ... Running in a zone or container would allow development and/or testing to be done in a separate zone/container, even with a different compiler if you wish. ...
    (comp.lang.cobol)
  • Re: Proper way to input a dynamically-allocated string
    ... >> eliminated them, for very good reasons. ... >> It is perfectly plausible that a company may have more than 32767 employees. ... >> where int is 16 bits. ... > people reported that it couldnt compile with their compiler tho, ...
    (comp.lang.c)
  • Re: int a[17]; int b = -1; /* a[17] same as b guaranteed in ANSI C? */
    ... > qualifiers) it is rather hard to imagine reasons why a compiler would prefer ... > an allocation different from the order of occurrence. ... Any existing code that assumes declared variables are allocated ... There are any number of reasons why a compiler might choose to ...
    (comp.lang.c)
  • Re: Msoft discontinuing VB.NET
    ... mindset of the individual, ... there are many possible reasons for what ... A compiler that does not work is useless.. ... the point was regarding VB.NET support for vs funtions.. ...
    (microsoft.public.vstudio.general)
  • Re: Record Problem
    ... that is not correct - for multiple reasons. ... String is *NEVER* '1' unless string is declared to be a character of ... the details of list-directed output formatting are up to the compiler. ... fact, according to the standard, you can't assume anything about the ...
    (comp.lang.fortran)