Error:53

[Michael 2727]

I have been getting Error codes appearing.
Using the new colour Ver, ontop of 4.1.10 App.

Error!
**************************|
Error:53 file not found |
***************************
Then -

Path Error
********************************************************************|
The following path is invalid... |
c:\program files\programming editor\picprog\picaxe08a.exe |
*********************************************************************

It seems if your code is between 237 to 246 bytes long
this may occur (almost full - 08M).
If this happens you may have to backtrack up to 20 bytes
of code to get it working again, you can then build it up,
but I have not been able to cram more than 254 bytes in
before the error.

I did not seem to get this before the colour addition
I usually got the Program Full warning only.

The code I am working on at present will go down to the
wire (last byte or so), I will keep trying,,~ ;o)

The code I am using is very busy with an embedded infrain2
command, which is not causing the program to halt while
attempting to D/L the new code, as it is ticking away and blinking here
while the errors come up BTW.

PS: just found stockley's post a few down
I knew had seen it mentioned before,, I am
running XP Pro Op sys.

Edited by - Michael 2727 on 12/28/2005 6:11:34 AM

 

[boezio]

I have error 53 too.

1) Two PCs, same win XP SP2, same progr.editor version: one fully working, one with error 53...
Some days ago either PCs were 100% working, I don't understand what's changed..

2) going into "programming editor\picprog" dir, I've tried to execute all the single EXE for every chip type.
picaxe08,18,28 are OK, all the remaining files respond "can't execute 16 bit app"...
It's a funny thing, but working EXE are only the three with 8.3 chars, instead long filename EXEs won't work anymore... and if i rename a Longfilename to short, this EXE will work and no error is given. old 16 BIT dos exe compilation by rev-ed... nooo please ??!

autoexec.nt, config.nt, etc. stuffs are ok.
the whole PC and every other program is working.

Please help!!! Alex

 

 

[hippy]

Well done for spotting the 8-dot-3 correlation; that might be some help in finding out why it is failing.

That the programs are 16-bit shouldn't be a problem; demonstrated by the fact that the three programs still run and all did until recently.

You'll probably find that if you rename one of the 8-dot-3's to longer it won't run when clicked on until renamed back. It's worth testing that.

To me it looks like a Windows OS problem, nothing at all to do with the Rev-Ed software.

One thing to check; is there a file called <i>windupdate.exe </i> on your PC ? Take care with the spelling ( the D after WIN ) it's not <i>winupdate.exe </i> .

Also, when you say autoexec.nt, config.nt ( and you should really include command.com in the list ) are &quot;ok&quot;, I presume you mean are present. Have you checked they haven't been corrupted ? It may be worthwhile copying the ones off the still working PC and seeing if that fixes it.

One final thing; is the PC which failed connected to the internet with Windows Update enabled ?

One workround could be for Rev-Ed to stop using long filenames for executables in the next software release. I always use 8-dot-3 because I've been bitten by similar problems before under Win98.

 

[boezio]

Yes! It's LFN-8dot3 the problem!
I solved the puzzle at 2:00 AM last night (italy local time...).

Workaround for all troubled people:

1)check autoexec.nt .... etc.
2) uninstall programming editor
3) check if 8.3 filename is enabled - many XP optimizer turn it off, so please search registry for key &quot;NtfsDisable8dot3NameCreation&quot;, it must be 0 (or key missing), if 1 please put it to 0.
4) rebooot &lt;-VERY Important
5) reinstall programming editor (now XP file APIs will recreate in NTFS fat either LFN and 8.3 name)
6) All is OK!

To rev-ed... please don't use APIs like DOS3INT-INT21h in your exe.. we're now in 2006...


 

 

[nmelinat]

Hi! I seem to have a similar problem in getting 53: File not found, etc. I've checked the setting of NtfsDisable8dot3NameCreation in my Windows registry and it is set to 0.
I guess you have a FAT32-, not a NTFS.

 

[boezio]

No, my hard disk are all NTFS.

Please try my solution (working only for those with errors in non-8.3 EXE compilators, for example PICAXE18X.EXE, and 8.3 EXEs working)

-check 8dot3 = 0
-uninstall progr.editor
- reboot
-reinstall programming editor

Bye!
Alex

 

 

[nmelinat]

Sorry, that was my first guess, after trying your solution.
I did this:
-check 8dot3 = 0 (check, was already 0, set to 0 again)
-uninstall progr.editor (done that, check)
- reboot (check)
-reinstall programming editor (check)

Here is my listing of the picprog directory with long file names and the corresponding alternative 8.3 entries. Maybe your 8.3 alternative names are different and somehow mine get translated differently and that is the problem:
<code><pre><font size=2>
CSTAMP16.EXE
flash.hex
ISTAMP16.EXE
pic18.exe
pic28.exe
picaxe08.exe
PIDD23~1.EXE PICAXE08A.EXE
PICAXE18.EXE
PICAXE~1.EXE PICAXE18A.EXE
PICAXE~4.EXE PICAXE18X.EXE
PI68CF~1.EXE PICAXE18X_1.EXE
PICAXE28.EXE
PICAXE~3.EXE picaxe28a.EXE
PICAXE~2.EXE PICAXE28X.EXE
PI69CF~1.EXE PICAXE28X_1.EXE
picdef.ini
picprog.exe
PICPROG.HLP
picprog.ini
WSTAMP16.EXE
Xstamp16.exe
</font></pre></code>

Your proposal is a workaround that might resolve the issue in some configurations like yours, sometimes not. Like in my case.

This seems to me like an application not an OS related problem. At first the Programming Editor should not use long file names and then rely on a correct 8.3 name conversion to get things working. You see that also in the using lower case file names in the PE (see dialog), while some of the exe's have upper case file names. In my opinion the names used by the editor should exactly match those on the file system. And if for some reason it's not possible to use long file names, those need to conform to the 8.3 standard.

There is a problem in finding and executing the corresponding intermediate code compilers and that needs to be fixed.

Team, do you here me? Can you put that on your list for the next version, please?
Many thanks,

Norbert

&#160;

 

[hippy]

<i>This seems to me like an application not an OS related problem. </i>

I don't believe that holds up to analysis. To me it still looks like a Windows OS problem. Especially note that people report that the PE was working fine but then stops working, and yet nothing has changed with respect to the PE installation.

<i>At first the Programming Editor should not use long file names and then rely on a correct 8.3 name conversion to get things working. </i>

It doesn't appear to do that and uses the usual means of calling Shell(), RunExe() or similar to execute those programs using the long filename, and leaves Windows to determine what to run and to launch the application. The mapping between the 8-dot-3 and long name is irrelevent in this repsect. By a bit of crafty renaming and copying of files, my PICAXE18X.EXE has the 8-dot-3 name PICAX~10.EXE and it works fine. The PE doesn't appear to care what short name the .EXE's have, and nor should it.

<i>You see that also in the using lower case file names in the PE (see dialog), while some of the exe's have upper case file names. In my opinion the names used by the editor should exactly match those on the file system. </i>

It would be nice for consistency, but irrelevent in practice; neither the PE or Windows OS are case sensitive. Changing the case of those filenames shows no problems with the PE executing them.

<i>There is a problem in finding and executing the corresponding intermediate code compilers and that needs to be fixed. </i>

I'll agree that there is both a problem and it needs resolving, but the question is where the fault lies and in who can fix it. The PE simply instructs Windows OS to execute the application, giving its long filename. Beyond that, the PE doesn't care what happens until control is returned to it when execution of the called program is completed.

What is going wrong appears to be between telling Windows OS to execute a particularly named executable and Windows acually running it, and that is out of the hands of the PE.

That is also demonstrated by attempting to run those executables directly from Explorer. Explorer has the same problem running those files as the PE does, ergo the problem is not with the PE.

One thing to bear in mind is that &quot;Error 53 file not found&quot; is not the actual error which occurs, but a consequential error. If the executable doesn't run it doesn't create a file which the PE looks for when control is returned to it, and it seems to report that as its error, and then it somewhat misleadingly then reports that the executable's path was invalid when it wasn't - It doesn't mean that the executable file wasn't found ! If the executable runs but the expected file isn't found, it will still give the same error. Change TempSavePath in network.ini to be a single dot, startup the PE, Syntax Check and you can simulate the effect.

Somewhat sloppy error reporting to report a failed consequence rather than the actual failure of execution ( and it clouds the issue ), but I think the PE is blameless in the problem of not being able to run the executables.

 

[nmelinat]

Thanks a lot for your extensive reply. Anyhow it still leaves me left with the same problem.

So, if that isn't a 8.3 translation related problem the whole check-registry-8.3Disable-etc-workaround (I've seen that workaround also in another section of the website) is a shot in the dark.

How can I be of help to you to get this problem fixed? Meanwhile I've downloaded your test application of November (see other thread) and it's generating a report with errors related in finding the output files generated by the picprog-exes. This is what you also mentioned above. Would it be of help to have the report forwarded to your e-mail address?

Could this be related to some specific versions of Runtime-DLLs? If so, please name the DLL-modules of interest to you and I will forward my version numbers and dates to you.


Edited by - nmelinat on 1/13/2006 6:06:12 PM

 

[hippy]

I'm not a member of Rev-Ed, just a PICAXE enthusiast and I use Win98 primarily, so I'm not really in a position to help fix this.

That my test program also has the same problems suggests the issue does lie with Windows. It's not worth sending me the details as there's not a lot I can do with the data.

I've had a look on Google for similar problems and solutions, but it is swamped with fixes for the autoexec.nt / config.nt problem, and this seems to be a problem more complex than that. If I find anything I'll let you know. My WinXP system doesn't have a problem so I can't try anything to help. I'm not sure where to go from here.