long filename and turbo-c findfirst()

Has anyone written a replacemnet for the findfirst and findnext functions that come with turbo-c to enable the long filenames of winNT and XP

Comments

  • : Has anyone written a replacemnet for the findfirst and findnext functions that come with turbo-c to enable the long filenames of winNT and XP
    :

    Turbo C is a 16-bit compiler is it not (depending on version and whether we're talking Turbo C or Turbo C++)? I think you may want a newer compiler and a decent Windows IDE if you're writing programs for Windows.
  • : : Has anyone written a replacemnet for the findfirst and findnext functions that come with turbo-c to enable the long filenames of winNT and XP
    : :
    :
    : Turbo C is a 16-bit compiler is it not (depending on version and whether we're talking Turbo C or Turbo C++)? I think you may want a newer compiler and a decent Windows IDE if you're writing programs for Windows.
    :
    I writing for DOS not windows and using Borland Turbo_c not C++. I was hoping someone may have written an asm routine to replace the findfirst and findnext routines. Without going into to much detail, I cannot use windows of any kind for this application. It would be so much easier if I could. BUt all the windows generations are not secure enough for my needs.


  • : :
    : I writing for DOS not windows and using Borland Turbo_c not C++. I was hoping someone may have written an asm routine to replace the findfirst and findnext routines. Without going into to much detail, I cannot use windows of any kind for this application. It would be so much easier if I could. BUt all the windows generations are not secure enough for my needs.
    :


    your computer must be running some version of Windows because long file names didn't come about until Win95. MS-DOS 6.X and earlier had no concept of long file names. console applications under windows NT and newer are not true MS-DOS but MS-DOS emulators. TurboC provides no more security on any version of MS-Windows than programs written by any other compiler. However, if you are maintaining a large program originally written with TurboC you may not have any other choice but to retain it.

    Short answer to your original question: I vagually recall something along those lines 8-10 years ago. but have no clue whether it's still available or not.
  • : : :
    : : I writing for DOS not windows and using Borland Turbo_c not C++. I was hoping someone may have written an asm routine to replace the findfirst and findnext routines. Without going into to much detail, I cannot use windows of any kind for this application. It would be so much easier if I could. BUt all the windows generations are not secure enough for my needs.
    : :
    :
    :
    : your computer must be running some version of Windows because long file names didn't come about until Win95. MS-DOS 6.X and earlier had no concept of long file names. console applications under windows NT and newer are not true MS-DOS but MS-DOS emulators. TurboC provides no more security on any version of MS-Windows than programs written by any other compiler. However, if you are maintaining a large program originally written with TurboC you may not have any other choice but to retain it.
    :
    : Short answer to your original question: I vagually recall something along those lines 8-10 years ago. but have no clue whether it's still available or not.
    :
    Your right. I am indeed running dos from a boot floppy created in XP.
    Iam then running a C program from this floppy to access a network drive with long filenames and copying all the files from the network to the local SCSI disk. This local disk does not have a OS on it, so that when I run the C program from the floppy and then remove the floppy no one can access the computer without their own boot disk(this is part of the security measure I have in place.
    So the files are long named and I want to copy them to a local drive keeping long in place. Findfirst puts the ~ in at 8 chars.

    cheers


  • : : your computer must be running some version of Windows because long file names didn't come about until Win95. MS-DOS 6.X and earlier had no concept of long file names. console applications under windows NT and newer are not true MS-DOS but MS-DOS emulators. TurboC provides no more security on any version of MS-Windows than programs written by any other compiler. However, if you are maintaining a large program originally written with TurboC you may not have any other choice but to retain it.
    : :
    : : Short answer to your original question: I vagually recall something along those lines 8-10 years ago. but have no clue whether it's still available or not.
    : :
    : Your right. I am indeed running dos from a boot floppy created in XP.
    : Iam then running a C program from this floppy to access a network drive with long filenames and copying all the files from the network to the local SCSI disk. This local disk does not have a OS on it, so that when I run the C program from the floppy and then remove the floppy no one can access the computer without their own boot disk(this is part of the security measure I have in place.
    : So the files are long named and I want to copy them to a local drive keeping long in place. Findfirst puts the ~ in at 8 chars.
    :
    : cheers
    :


    I created a boot 3 1/2" floppy disk on my XP computer, then wrote a Hello World console program with my VC++ 6.0 compiler, copied it to the floppy, booted with that floppy. Surprise! Surprise! the Hello World program wouldn't run because it requires Windows os, and the os on the floppy is Windows Millemum (used ver command to verify the version). So, I guess your only option is to continue using that TurboC compiler or another 16-bit compiler. You might try Watcom C.

    Your second problem (?) is that you must have installed your XP os on FAT32 file system. I use NTFS and cannot access my C drive from that floopy boot disk (because it's FAT file system).

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories