another variation of "10 PRINT"

[JRace]

Why is it I SEE the TTF file there in the dir in the file explorer and not in DOS?

When you say "in DOS" do you mean "in the Windows Command Prompt"?  The full file name should be listed there, but it depends on the program you are using to view the folder.

Wall of text incoming!  Set phasers on "oh, man!"

---

Many people think of the Windows Command Prompt as "DOS" or the "DOS Prompt", but that is no longer the case.  IIRC Windows ME was the last version of Windows built on top of DOS, with a command prompt that let you access the real underlying DOS.  All versions of Windows since then descend from Windows NT, with DOS compatibility being an added feature.   The modern Command Prompt is very DOS-like and borrow commands and features from DOS, but it's just a compatibility layer.

Anyway, back to the story.  Windows can store stupidly long and complex filenames, but it also stores short filenames for older programs which are not "long filename aware", and your "DOS" prompt may not be showing long filenames?

---

First, some definitions:
FILENAME:

• Unix and descendents: The COMPLETE name of the file, including the extension after the ".", if any.
  
• Windows: The filename before the "."
  

EXTENSION:

• Unix etc: The part after the ".", UNLESS the "." is the first character of the filename.  If the filename begins with "." then the file is invisible in a normal directory listing.  For wildcard searches the extension is considered to be part of the filename.  (confused yet?)
  
• Windoze: The 1, 2, or 3 characters after the ".", which tell Windows what type of file it's dealing with.  Windows considers this to be separate from the filename.
  

In these days of modern malware it would seem logical to look INSIDE the files to determine what they are, but Windows descends from a simpler age & mindset and is unable to do that.  Meanwhile, Unix, Linux (& presumably MacOS), which descend from that same age, do EXACTLY that: they examine the file contents to see what's inside!

---

Here's a directory listing showing both short filename (in the center column) alongside long, full filenames on the right (generated by typing "dir /x"):

V Volume in drive C has no label.
Volume Serial Number is 44A9-7300

Directory of C:\I\Downloads\_____________\WhatAreYouLookingHereFor

01/13/2025  06:31 PM    <DIR>                          .
01/13/2025  06:31 PM    <DIR>                          ..
01/13/2025  05:56 PM                0 COUSIN~2.THI    CousinBlakeOwesMeMoney - BreakHisKneecaps.ThisIs EnoughToMakeMeCallPapa!
01/13/2025  05:17 PM                0 COUSIN~1.THI    CousinBlakeOwesMeMoney - BreakHisKneecaps.ThisIsGettngRediculous!
01/13/2025  05:16 PM                0 COUSIN~1.TTF    CousineNerdFontMono-Bold.ttf
01/13/2025  05:16 PM                0 COUSIN~1.TXT    CousinJoesWeddingToAnOgre.txt

(FYI: The shortened DOS-compatible filename starts with the first few characters of the full filename, which is, well, shortened to make room for a numeric distinction of one or more characters.  To be compatible with DOS, the full filename may not be longer than 8 characters with an extension of not more than 3 characters.)

Instead, maybe you can try "dir c*.*", which may list a name like "COUSIN~1.TTF".  There may be many files with similar shortened names, like " COUSIN~2.TTF",  COUSIN~3.TTF", and so on.  Windows gives a unique short name to each file, so that MS-DOS users can use the files even though the names may not make much sense to us.

(Notice how I recommended "dir c*.*" above?  The "c" can be either lower-case or upper-case because Windows filenames are not normally case-sensitive, so "c" and "C" are the same in file names.  Also notice the "*.*" part: Windows considers file extensions to be a separate part of the filename, so "c*" under Windows will match a file name, but not the filename extension.  It might match "CousineNerdFontMono-Bold", but it will not match "CousineNerdFontMono-Bold.ttf".  It seems kind of inconsistent, doesn't it, that Windows is so carefree about upper-case or lower-case, but it's so finicky about extensions?  Oh, well, "Forget it Jake, it's Windows."  While Unix, Linux, (and I presume?) MacOS look at file contents to determine their type, Windows looks only at the file's extension.  Windows inherits this behavior from MS-DOS, which inherited from CP/M, and so on... back to the days of tally sticks, I suppose.)

Since you are using Windows, you should ignore $HOME, "/usr/share/", or "/usr/" anything, since these are all Unix conventions which are inherited by Linux & modern MacOS.  (On Windows there is no environment variable "HOME"... if you read it, you get an empty string (""), so "HOME$\Windows\Fonts" is the same as "\Windows\Fonts".)

In short: If you see "HOME" or "/usr/" then those are not for Windows users.

[hsiangch_ong]

i don't think "Jack002" has read anything i wrote.

should simply use smcneill's first contribution which certainly works on windows.

while my example would work on qb64 2.1, the character creation statement will have to be changed to _printstring because _uprintstring is specific to phoenix edition.  since 3.8 if i'm not mistaken.

[bplus]

+1 for encouragement. Welcome to the Monologue Club

Some of us like to talk and show off more than read or listen, how many? all at least one time of another.

You see that last one by JRace, I totally skipped it, looked like a small business report to me, none of my business!

[JRace]

You see that last one by JRace, I totally skipped it, looked like a small business report to me, none of my business!

You missed out on the profits, man!

---

Talk and show off?

Nah, maybe just trying to help and share experience, from a "been there, so I know how you feel, from a guy who didn't have the interwebs to fall back on" angle.

TMI all too often and too quickly, but just trying to share and help out.

I'm a bit of a polymath, going wherever the muses lead.  Jack-of-all-trades, knowledgeable at all, expert at none.   All that stuff that looks passable on a resume.


Unlike the single-minded twits that are all too common on other fora, I think that sometimes it helps to ignore the main  topic - the facade - and get to the foundation.

Big picture guy and all that.

¯\_(ツ)_/¯

[bplus]

Hmm... maybe I missed something in that Directory Listing

"01/13/2025 05:17 PM 0 COUSIN~1.THI CousinBlakeOwesMeMoney - BreakHisKneecaps.ThisIsGettngRediculous!"

[JRace]

Hmm... maybe I missed something in that Directory Listing

"01/13/2025  05:17 PM                0 COUSIN~1.THI    CousinBlakeOwesMeMoney - BreakHisKneecaps.ThisIsGettngRediculous!"

Either my spellchecker missed something or I did, but I would never name real family, no matter how tempted.

[Jack002]

i don't think "Jack002" has read anything i wrote.

should simply use smcneill's first contribution which certainly works on windows.

while my example would work on qb64 2.1, the character creation statement will have to be changed to _printstring because _uprintstring is specific to phoenix edition.  since 3.8 if i'm not mistaken.

My problem is not with QB64. And I can use another version of the program to go around the issue I have, but me and my font problems will still go on.
I have an issue with my laptop computer running WIN 10, not with QB64.
The TTF file is both there and not there at the same time.

[Jack002]

Why is it I SEE the TTF file there in the dir in the file explorer and not in DOS?

When you say "in DOS" do you mean "in the Windows Command Prompt"?  The full file name should be listed there, but it depends on the program you are using to view the folder.

[1000 lines of text snipped]

Ok, when I say DOS or DOS prompt, I mean command prompt. I thought that didn't need to be said, but if it helps.
The FONTS area of the file explorer shows a TTF that is just NOT there in COMMAND PROMPT
(File explorer is the name windows uses for that doodad you look at files with, I used the name microsoft calls it)
Other than finding out about a blocked status of a font, I have no other clues, it still is there and not there.
Jack