Useless compiler error

[Michael Burns]

I'm in the process of recompiling a program that I've not worked on for a couple of years as I need to add a couple of features. It was last compiled under PBDLL 6 a few years ago. I just tried to compile it under PLWin 7 and got the following compiler error. When "compile" is selected under the "Run" menu, a message box titled "Compile Error!" pops up which says "Cannot compile basic file C:\.... Incorrect function."

No error number or anything to hint at what it does not like. I've replaced the full path to the file I am compiling with 'C:\....' in the above message. I've been using PB for about 10 years and have never seen anything like this before.

[Brice Manuel]

Are you sure you are using 8.3 compatible directories and file names for everything?

[Michael Burns]

I'm compiling under 7.04, not 8.3.

[Brice Manuel]

Can't tell if you are being smart alec or don't understand my comment. I am hoping the latter.

I am referring to file/directory structure.

That version still has a 16bit compiler and requires the 8.3 file/directory structure like you used to use in the old 16bit days of DOS and Windows 3.1

Depending you your system setup, your OS may not automatically create backwards compatible directories/files and you may manually have to install/use PB stuff in an 8.3 structure.

[Michael Mattias]

I'm not sure exactly what the fix is, but "Incorrect Function" error is definitely related to paths. I used to get that a lot.

IIRC you get it if you try to compile a file which does not have a three-character extension, eg "myprog.bi" or "myprog.02"

And/or (maybe) it was the a problem if you compile a program using #INCLUDE files with the the same file name but different extensions, eg "myprog.Bas" and "myprog.bi"

I haven't seen this for a long time, but I do recall it was related to file names and paths.

MCM

[Brice Manuel]

I had it all the time when I bought 8.03 almost a year ago, as I keep XP tweaked and do not have 8.3 compatible directory/file names, etc. PowerBASIC got uninstalled and I didn't touch it until 8.04 hit a couple of months ago and gave us a 32bit compiler.

[Michael Burns]

As near as I can tell, it must have not liked a path embedded in the old resource file. When I recompiled the .PBR file (rc.exe & pbres.exe) before running the PB compiler itself, the issue went away.

[Bob Zale]

That version still has a 16bit compiler and requires the 8.3 file/directory structure like you used to use in the old 16bit days of DOS and Windows 3.1

That would be absolutely, unequivocally incorrect. PowerBASIC Compilers have supported long file names since PB/CC 2.0 and PB/DLL 6.0. That's many, many years now.

Bob Zale
PowerBASIC Inc.

[Bob Zale]

As near as I can tell, it must have not liked a path embedded in the old resource file. When I recompiled the .PBR file (rc.exe & pbres.exe) before running the PB compiler itself, the issue went away.

Documented many times before. It's caused by a bug in the Windows sub-system. The options are to re-boot, terminate NTVDM, or upgrade to the latest version of PowerBASIC.

Best regards,

Bob Zale
PowerBASIC Inc.

[Brice Manuel]

That would be absolutely, unequivocally incorrect. PowerBASIC Compilers have supported long file names since PB/CC 2.0 and PB/DLL 6.0. That's many, many years now.

Bob Zale
PowerBASIC Inc.

Unfortunately, that is not entirely accurate, at least not under XP using NTFS.

It would appear the 16bit compilers are only able to read the 8.3 aliases created by the 32bit file system. They cannot read the true long file names.

Using PB 8.03 under XP/NTFS with 8.3 name creation disalbed, to use 8.03 one had to install in and use the 8.3 file structure for everything.

8.04 remedied this, but it does use a 32bit compiler.

It is not unique to PB, any 16bit program should have that problem under the same circumstances.

[Bob Zale]

Sorry, but... I'm afraid that would still be incorrect. PowerBASIC compilers have used the 32-bit API's to access all files for many years now.

Bob Zale
PowerBASIC Inc.

[Barry Erick]

Darn correct on 8.3's for a LONGGGG time. 16 bit has nothing to do with it as back in dos you could write/read long file names with many things, including a function in a PB utility I wrote back then. So many of the things in the library became part of windows and/or PB that there is no need for it (3rd party support) anymore.

Anyway, it isn't a long file name problem because there is not one.

[Brice Manuel]

Sorry, but... I'm afraid that would still be incorrect. PowerBASIC compilers have used the 32-bit API's to access all files for many years now.

It would "appear" that although it may be "thunking" the 32bit API, all you are retrieving/processing is the 8.3 alias?

I have the issue with 8.03 here on five different XP systems and I detailed the special circumstance above (8.3 creation disabled). If I enabled 8.3 creation, rebooted and reinstalled 8.03 the problem was gone. Disable it and reboot, reinstall 8.03 and the problem is back. Pretty simple to diagnose.

(If you were to disable 8.3 creation and test for yourself, be sure to reboot and reinstall PB in a new directory, otherwise it would be using the previously created 8.3 aliases.)

It happens with any 16bit windows program when 8.3 creation is disabled on my XP/NTFS boxes. If aliases are not being created, then a 16bit app will choke on a long file name.

I love PB and am not in any way trying to put it, or you, down, but the problem I had was real, I know what caused it and I know how to resolve it.

Heck, it isn't even really a PB issue as that is the way the file system is designed to work. A very unique problem and would never affect 99.99% of the PB users, but it did me as I tweak XP quite a bit.

Since 8.04, and its 32bit compiler, the problem is gone. Very happy PB user here and I don't have a single gripe about PB.

[Bob Zale]

Believe what you will. I won't be arguing with you.

[Roger Garstang]

Not picking sides or arguing here as both sides appear to have valid statistics and the artical does confirm 16bit apps having problems, but are we really sure it is a compiler issue and not RC.EXE not being able to read the paths? Although I do have an .RC file with 30+ char names in it...just trying to figure out some things here since the article does say it stops the creation of 8.3 names which to me would mean existing names are kept and it was said not only a reboot, but a reinstall of PB was needed??? When installing PB, what folder are you putting it in? All of my PB files that get installed have 8 or fewer chars. If what you say is true, installing with them enabled, then disabling/rebooting and creating a new folder/name for your source files > 8 chars should fail.

[Roger Garstang]

After doing my own testing, I can now confirm a failure...it is only with the path though...somehow the filenames don't make a difference.

1. 8 char dir, > 8 char source, 8 char exe= Passed
2. 8 char dir, > 8 char source, > 8 char exe= Passed
3. > 8 char dir, any source, any exe= Failed

Yet another reason to upgrade to the latest compilers though. And it would only matter if you applied that tweak...

That is with the NtfsDisable8dot3NameCreation setting set to one and a reboot, no change to my existing install other than renaming the compiler to PBwin32.exe and copying my old 16bit to the Bin folder so it is used as the compiler.

On a side note, another good tweak in that same key is setting Win95TruncatedExtensions to 0 so it doesn't store .html as .ht~ and searches/deletes more accurately...although disabling the 8.3 may do this too. I've read of a few other issues with disabling 8.3, so I may not keep that one...Win95TruncatedExtensions to 0 I kinda like. There is also the tweak to disable last access date in there too, but I kinda like keeping that for security and other troubleshooting. I will most likely add NtfsDisable8dot3NameCreation to my Win XP 64bit Unattended CD tweaks though since 16bit apps won't run, and any other issues I can deal with since they in no way compare to M$'s "excellent" support for drivers...

[Brice Manuel]

Yeppers, admitted to or not, it does exits.