Is there some way to convert long filenames to short filenames?
dos-man 64
for ms-dos programming. I've just used gcc to recompile one of my old
dos directory changing utilities. I had a little bit of trouble with a
few of the functions (chdir,getdisk,getcwd), but I worked through
that. It took a few hours, hehe.
At any rate, this version of the program seems just as clueless about
long filenames as my old borland executable. I'm passing a value of
\program files\ to chdir and it doesn't seem to be able to change the
directory. My readings through the docs seemed to indicate that this
compiler generates dos-based executables that can handle long file
names.
Also, is there some way to shrink down these executables. The exe is
over 300kb. That's six times bigger than the executable that borland's
compiler spit out.
Thanks,
dos-man
DJ Delorie
> My readings through the docs seemed to indicate that this compiler
> generates dos-based executables that can handle long file names.
Yes, it should - as long as you avoid DOS functions that are
short-file-name-only.
Also, see _lfn_gen_short_fname
> Also, is there some way to shrink down these executables. The exe is
> over 300kb. That's six times bigger than the executable that borland's
> compiler spit out.
FAQ 8.14
Ste...@aol.com
Rod Pemberton
news:275d23ac-69e7-4da0...@a39g2000yqc.googlegroups.com...
> At any rate, this version of the program seems just as clueless about
> long filenames as my old borland executable.
DJGPP supports longfilenames (LFNs) but *only* if the environment you're
using supports the LFN API. LFNs aren't available by default in DOS because
the LFN API was created for Windows, not DOS. But, there are some ways to
get LFN support in DOS. For nearly all real mode16-bit DOSes, you'll need
to install an LFN driver TSR. The best one is Henrik Haftmann's DOSLFN. I
use version 0.32o - the last by Haftmann. Jason Hood also has some updated
versions of DOSLFN. However, it seems that Jason didn't list his changes.
So, I'm not clear on what changes he made... If you're running in a Windows
dosbox, you'll have LFN support since it accesses the Windows LFN API. It's
also possible you may have a DOS with the LFN API such as the experimental
versions of OpenDOS/DR-DOS. The last time I used FreeDOS it didn't have LFN
API. It might have it today. You'll have to check. There are also
standalone DOS utilities with LFN support that don't require an LFN driver,
such as LFN tools by Ortwin "Odi" Glueck. His lcopy and lren are very
useful. His code is GPL'd for an obsolete version of MSVC. (Hint for DJGPP
developers?) There are also drivers for other versions of Windows such as
NT.
Jason Hood's updates of DOSLFN, also with a link to Haftmann's pages:
http://www.geocities.com/jadoxa/doslfn/index.html
So, the questions are:
1) What environment are you using: real mode 16-bit DOS without LFN, OpenDOS
with LFN, or a Windows dosbox with LFN? I.e., does it support LFN's?
2) How are you attempting to use LFN's in your program? Are you using
DJGPP's functions? Or, are you calling the LFN API directly?
Many of the DJGPP file functions, e.g., open, rename, exec, stat, call a
DJGPP's _truename() which is a specialized wrapper around the LFN API call
that converts between LFNs and SFNs. So, if the environment you're using
has LFN support, LFN's should be available as DJ stated. Why DJ doesn't
ever clarify that the environment also *requires* LFN support to use DJGPP's
LFN support is beyond me. This issue has come up numerous times... 50% of
an answer...
FYI, I don't usually use the LFN functionality of DJGPP. What I typically
do is use SFNs only. The reason is because I need LFN's to work with the
OpenWatcom C compiler too which doesn't have LFN support or it only had SFN
support when I started using it... It might have LFNs in the current
version. If I need to display an LFN, I convert from SFN to LFN calling the
LFN API directly. If I'm passed an LFN, I convert from LFN to SFN calling
the LFN API directly and then use the SFN. To obtain or convert between
SFNs and LFNs, you need only two of the LFN API's calls - except for
renaming an LFN. I use __dpmi_int() to call the 0x71a0 and 0x7160 LFN
functions to determine: 1) if LFN's are available and 2) to obtain the LFN,
SFN, or fullpathname from an LFN or SFN. This works with both MS-DOS v7.10
and Win98SE dosbox, DJGPP and OpenWatcom. Once these two functions are
written, it's "cut-n-paste".
Rod Pemberton
dos-man 64
Well, I got it down to 129K. That's not too bad. The original was
50K. And this new version is a bit more complex, so it was going to
get at least a little bigger. As long as it stays down around 100k,
I'm fine with that. I've got a massive string class that I wrote.
This is the only application I've ever used it in. Works pretty good,
hehe.
dos-man 64
Can you please direct me to these faq? All I have is the compiler. I
got it off of a book's companion CD. I don't have any docs or
anything. I tried reading through the man pages for gcc, but I don't
have the proper viewer software.
The book was Teach Yourself C++ in 24 hours (second edition.) I do
not have the book anymore. I got it on amazon and it had a dead
cockroach in it. I threw the book out and kept the cd, hehe.
I've had this CD for a few years, but this is my first time using it.
I wonder if the CD has a digital copy of the book on it? I will have
to go and check that. Is it worth rebuying the book?
dos-man 64
> "dos-man 64" <ChairS...@mail.com> wrote in message
>
> news:275d23ac-69e7-4da0...@a39g2000yqc.googlegroups.com...
> So, the questions are:
> 1) What environment are you using: real mode 16-bit DOS without LFN, OpenDOS
> with LFN, or a Windows dosbox with LFN? I.e., does it support LFN's?
> 2) How are you attempting to use LFN's in your program? Are you using
> DJGPP's functions? Or, are you calling the LFN API directly?
I'm a windows 98 SE user. I can certainly use the appliction from Real-
mode, but mostly I'm using from within windows.
I really don't know what the LFN API is. This is my first time using
this compiler. I was pleasantly surprised that I even was able to get
the application to recompile at all. It's pretty compatible with the
borland compiler. As stated, I had a bit of trouble with a few of the
non-ansi functions like getcwd, and getdisk(). The getdisk() function
gave me a lot of trouble, so I created a new function using int86( ).
>
> FYI, I don't usually use the LFN functionality of DJGPP. What I typically
> do is use SFNs only. The reason is because I need LFN's to work with the
> OpenWatcom C compiler too which doesn't have LFN support or it only had SFN
> support when I started using it... It might have LFNs in the current
> version. If I need to display an LFN, I convert from SFN to LFN calling the
> LFN API directly. If I'm passed an LFN, I convert from LFN to SFN calling
> the LFN API directly and then use the SFN. To obtain or convert between
> SFNs and LFNs, you need only two of the LFN API's calls - except for
> renaming an LFN. I use __dpmi_int() to call the 0x71a0 and 0x7160 LFN
> functions to determine: 1) if LFN's are available and 2) to obtain the LFN,
> SFN, or fullpathname from an LFN or SFN. This works with both MS-DOS v7.10
> and Win98SE dosbox, DJGPP and OpenWatcom. Once these two functions are
> written, it's "cut-n-paste".
>
> Rod Pemberton
I've been using this app for quite a few years. I definitely improved
it last night. However, it's always been my dream to have this
program work with long filenames.
DJ Delorie
> Can you please direct me to these faq? All I have is the compiler.
dos-man 64
> > Can you please direct me to these faq? All I have is the compiler.
>
> http://www.delorie.com/djgpp/
Got it. I used the -s linker switch. Boy that really shrunk it down,
46K.
One problem solved, one to go.
Gerrit van Niekerk
> On Mar 13, 12:43 am, DJ Delorie <d...@delorie.com> wrote:
>> > My readings through the docs seemed to indicate that this compiler
>> > generates dos-based executables that can handle long file names.
>>
>> Yes, it should - as long as you avoid DOS functions that are
>> short-file-name-only.
>>
>> Also, see _lfn_gen_short_fname
>>
>> > Also, is there some way to shrink down these executables. The exe is
>> > over 300kb. That's six times bigger than the executable that borland's
>> > compiler spit out.
>>
>> FAQ 8.14
>
> Can you please direct me to these faq? All I have is the compiler. I
> got it off of a book's companion CD. I don't have any docs or
> anything. I tried reading through the man pages for gcc, but I don't
> have the proper viewer software.
dos-man 64
>
> news:275d23ac-69e7-4da0...@a39g2000yqc.googlegroups.com...
>
> Many of the DJGPP file functions, e.g., open, rename, exec, stat, call a
> DJGPP's _truename() which is a specialized wrapper around the LFN API call
> that converts between LFNs and SFNs. So, if the environment you're using
> has LFN support, LFN's should be available as DJ stated. Why DJ doesn't
> ever clarify that the environment also *requires* LFN support to use DJGPP's
> LFN support is beyond me. This issue has come up numerous times... 50% of
> an answer...
>
I got this working now. The only requirement is I have to set an
environment variable LFN=y. It doesn't work if the environment
variable isn't set. Thank you for your help. This utility is kicking
serious butt now. It's shocking stuff.
The whole RHIDE, DJGPP, and GCC package is a really good programming
environment. My complements to the authors of these fine programs.
I'll be interested in seeing what kind Linux and windows GUI
applications can be made using these fine tools. I guess I need to
download a more up-to-date version first, hehe. Right now I'm pretty
into game design. There's no rush on that.
Thanks,
dos-man
DJ Delorie
Odd, it's supposed to guess that you have LFN automatically.
What version of DJGPP do you have?
dos-man 64
> Odd, it's supposed to guess that you have LFN automatically.
>
> What version of DJGPP do you have?
I'm really not sure. The info is eluding me. The RHide IDE is version
1.4 and the faq is 2.11. Perhaps you can deduce from that what the
version is, and also from the year the book was published.
DJ Delorie
Look in (for example) c:\djgpp\include\sys\version.h
Rod Pemberton
> I've been using this app for quite a few years. I definitely improved
> it last night. However, it's always been my dream to have this
> program work with long filenames.
Well, seems you find a solution before I got to post my reply... In case
it's useful to someone else, here it is.
You could DJGPP's LFN aware functions, or do it using the LFN API directly.
You may want to read through DJGPP's libc.info file for LFN aware and SFN
only functions. IIRC, there is a DJGPP variable that indicates the presence
of an LFN aware environment also. (Seems you found LFN=y...)
This example will indicate whether the host environment supports LFNs or
not.
#include <stdio.h>
#include <string.h>
#include <dos.h>
#include <sys/stat.h>
int main(void)
{
int handle;
char SFN[]="eightdot.thr";
char LFN[]="Our_LFN_name_exceeds_83.txt";
/* create a file with an SFN */
_dos_creat(SFN,_A_NORMAL,&handle);
_dos_commit(handle);
_dos_close(handle);
/* attempt to rename with an LFN */
rename(SFN,LFN);
/* did we get our LFN or was our LFN truncated to an 8.3 SFN? */
if(!strcmp(LFN,&strrchr(_truename(LFN,NULL),'\\')[1]))
{
printf("LFN ");
}
else
{
printf("SFN ");
}
printf("%s\n",_truename(LFN,NULL));
remove(LFN);
return(0);
}
Rod Pemberton
Rod Pemberton
> The only requirement is I have to set an
> environment variable LFN=y.
As DJ said, this should be automatic... However, I've also have a few
programs where I have code force LFN use, if available. This is with DJGPP
v2.03.
#ifdef __DJGPP__
/* if LFN driver installed, force _USE_LFN on */
if(lfn_installed)
{
_crt0_startup_flags&=~_CRT0_FLAG_NO_LFN;
putenv("LFN=y");
}
#endif
The variable lfn_installed gets set to one if a __dpmi_int 0x21 call to
0x71a0 reports that it supports long filename functions.
Rod Pemberton
dos-man 64
> Look in (for example) c:\djgpp\include\sys\version.h
Very clever, hehe. It's 2.2.
dos-man 64
> "dos-man 64" <ChairS...@mail.com> wrote in message
I'm going to try these out right now, thanks. Hopefully I can get rid
of this dos environment variable requirement. I can imagine the horror
and disfunctionality if every program relied on dos environment
variables to run correctly, heh. It would be chaos.
DJ Delorie
> Very clever, hehe. It's 2.02
2.03 and a preview of 2.04 are available online, might want to try
them.
dos-man 64
It's definitely worth the download. I'll get to it soon. Right now
I'm working on a graphics program in vb. You place lines, circles,
and squares on a form. You can move them around and resize them and
whatnot. Everything is done with the keyboard. It's the only
graphics program I've ever seen that barely uses the mouse at all. I
just figured out a way to have an undo feature this afternoon by using
the windows clipboard. Pretty clever sometimes, hehe. At any rate,
When you are finished editing your image, it spits out vb line( ) and
circle ( ) statements for recreating the images in your programs.
Your example code worked like a charm :D The putenv( ) statement did
the trick.
Funny, I tried setting the value of LFN=y with setenv( ) and it didn't
work at all.
Rugxulo
Try "gcc -s -Os -march=i386 myapp.c -o myapp.exe" and then "upx --best
--lzma --all-filters myapp.exe", and see if that helps.
Or try UPX-UCL (DJGPP compile) if you're a license purist (a la
Debian) although the LZMA part is the same either way :
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/upx/
dos-man 64
What is upx? Is that the linker?
BTW. I appreciate all the help I have received here. All of you
please feel free to download this apparently finished program, and
also my string class. For such a simple command line navigational
utility, this was a real B***H to program. I only use C when I don't
see any other options for using something a little easier. In this
case I was getting my ass handed to me in quickbasic, and I quickly
realized that all bets were off. I don't know that I could have made
this without my string class. I doubt it.
Here is the download link to the zip file.
http://www.yousendit.com/transfer.php?action=batch_download&batch_id=UmNMRE9zR3M1UjZ4dnc9PQ
Thank you, all.
Jason Hood
> use version 0.32o - the last by Haftmann. Jason Hood also has some updated
> versions of DOSLFN. However, it seems that Jason didn't list his changes.
Not on the site, no, but the version history has been updated in
doslfn.txt. And I've moved to http://adoxa.110mb.com/.
Jason.
Rugxulo
Why the move? Got tired of Geocities lack of bandwidth and storage?
BTW, still loving TDE (compiled by DJGPP, of course)! ;-)
Jason Hood
>> doslfn.txt. And I've moved to http://adoxa.110mb.com/.
>
> Why the move? Got tired of Geocities lack of bandwidth and storage?
Yep, I ran out of room.
> BTW, still loving TDE (compiled by DJGPP, of course)! ;-)
I've really got to fix the known bugs in 5.2 and release a beta...
Jason.
Jude DaShiell
file name plus a (.) plus a (~) plus a unique two digit number where first
eight characters of long file name are identical inside of a single
directory. Perhaps this capability may be under short file names in some
library of the compiler in use I don't know.