Ooookay...I need a sanity check. I'm trying to assemble the following
file: www.k9spud.com/vwcdpic/devel/vwcdpic-2.7d/vwcdpic-2.7d.asm
- if you click the link you need to agree to the GPL licence on this
code and sign in using username "I" and password "agree".

Anyway, it's been awhile since I've compiled a complete file like this
from somewhere else and I'm running up against a rather hard brick
wall. I used the project wizard, creating a new MPASM project and
targeting the correct processor. I add my .asm file, try to
assemble...and get "DOS Error: File not found". Behind that popup
looks to be the MPASM window stuck on "Building symbol table...".

That's the only error I get, not super helpful. So...does anyone have
any ideas as to why I can't get this simple file to work?

Frustrating!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
-Douglas Adams

At 08:54 PM 4/13/2008, you wrote:
>Ooookay...I need a sanity check. I'm trying to assemble the following
>file: www.k9spud.com/vwcdpic/devel/vwcdpic-2.7d/vwcdpic-2.7d.asm
>- if you click the link you need to agree to the GPL licence on this
>code and sign in using username "I" and password "agree".
>
>Anyway, it's been awhile since I've compiled a complete file like this
>from somewhere else and I'm running up against a rather hard brick
>wall. I used the project wizard, creating a new MPASM project and
>targeting the correct processor. I add my .asm file, try to
>assemble...and get "DOS Error: File not found". Behind that popup
>looks to be the MPASM window stuck on "Building symbol table...".
>
>That's the only error I get, not super helpful. So...does anyone have
>any ideas as to why I can't get this simple file to work?
>
>Frustrating!
>
>Josh

> Aha! It was a filename issue...you saved it as josh.asm, but the
> original name was vwcdpic-2.7d.asm. I guess MPASM doesn't like
> multiple periods in a filename.

Interesting.

And since MPLAB first release was due long after Win95 was introduced,
I can't really see why they are using old and dead DOS file-routines
for it. I thought these silly limitations were gone long time ago, but
obviously some people/companies still stick to them by using weird
compilers.

On Mon, Apr 14, 2008 at 1:59 AM, Rikard Bosnjakovic
<.....rikard.bosnjakovicKILLspam.....gmail.com> wrote:
> And since MPLAB first release was due long after Win95 was introduced,
> I can't really see why they are using old and dead DOS file-routines
> for it. I thought these silly limitations were gone long time ago, but
> obviously some people/companies still stick to them by using weird
> compilers.

Well I shouldn't be too surprised...MPLAB still has that path name
length restriction (or it still does in my current 7.x versions).

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
-Douglas Adams

Josh Koffman wrote:
> On Mon, Apr 14, 2008 at 1:59 AM, Rikard Bosnjakovic
> <EraseMErikard.bosnjakovicspam_OUTTakeThisOuTgmail.com> wrote:
>> And since MPLAB first release was due long after Win95 was introduced,
>> I can't really see why they are using old and dead DOS file-routines
>> for it. I thought these silly limitations were gone long time ago, but
>> obviously some people/companies still stick to them by using weird
>> compilers.
>
>
> Well I shouldn't be too surprised...MPLAB still has that path name
> length restriction (or it still does in my current 7.x versions).

*ONLY* if you're still building old absolute-mode code.
I thought all/most was using relocatable-mode code today...

(And I guess that is the case with the multiple-dots limitation
also, but I'm not 100% sure about that...)

> On 14/04/2008, Jan-Erik Soderholm <@spam@jan-erik.soderholmKILLspamtelia.com> wrote:
>
>> > Well I shouldn't be too surprised...MPLAB still has that path name
>> > length restriction (or it still does in my current 7.x versions).
>>
>> *ONLY* if you're still building old absolute-mode code.
>
> That doesn't make sense.
>
> MPASM's inability for multiple periods in filename really hasn't got
> to do anything regarding absolute or relocatable mode.
>
>

> It would not surprice me if the "mutliple-dots"
> is related to the same base cause. But maybe
> it isn't...

Note that even Windows gets worked up on multiple dots at some point. I
had W trying to rename .tar.gz files to other variants with all the
resulting problems (hidden 'cause windows hides the extensions by
default). So the problem may not be entirely Microchip's.

> Note that even Windows gets worked up on multiple dots at some point. I
> had W trying to rename .tar.gz files to other variants with all the
> resulting problems (hidden 'cause windows hides the extensions by
> default). So the problem may not be entirely Microchip's.

With hidden extensions, anything bad can happen. That's why you unhide
the extensions.

For the sake of testing, renaming an image "foo.png" too
"foo.bar...doodledoo.png" resulted in zero problems here.

Rikard Bosnjakovic wrote:
> On 14/04/2008, John Coppens <spamBeGonejohnspamBeGonejcoppens.com> wrote:
>
>> Note that even Windows gets worked up on multiple dots at some point. I
>> had W trying to rename .tar.gz files to other variants with all the
>> resulting problems (hidden 'cause windows hides the extensions by
>> default). So the problem may not be entirely Microchip's.
>
> With hidden extensions, anything bad can happen. That's why you unhide
> the extensions.
>
> For the sake of testing, renaming an image "foo.png" too
> "foo.bar...doodledoo.png" resulted in zero problems here.

Doesn't prove anything.
The particular part of the MPLAB toolset that
is used when building absolute mode code might
still have that problem (just as the max
path lenght problem).

> Rikard Bosnjakovic wrote:
>> On 14/04/2008, John Coppens <RemoveMEjohnTakeThisOuTjcoppens.com> wrote:
>>
>>> Note that even Windows gets worked up on multiple dots at some point. I
>>> had W trying to rename .tar.gz files to other variants with all the
>>> resulting problems (hidden 'cause windows hides the extensions by
>>> default). So the problem may not be entirely Microchip's.
>>
>> With hidden extensions, anything bad can happen. That's why you unhide
>> the extensions.
>>
>> For the sake of testing, renaming an image "foo.png" too
>> "foo.bar...doodledoo.png" resulted in zero problems here.
>
> Doesn't prove anything.
> The particular part of the MPLAB toolset that
> is used when building absolute mode code might
> still have that problem (just as the max
> path lenght problem).
>
> Jan-Erik.

I've also had problems with spaces in file names with compilers not
being able to find things they need.

So, I use the old batch file command "subst" to force the desired
directory into a short (usually 8.3) directory ("folder") and file name mold,
with no spaces, and the problems go away.