Hey Folks,
Interesting Factoid.....
While working on Activity Editor, I was looking at the STFReader Code. Since the STFReader is format Agnostic, you have to look at where the calls for the reader is....so more code mining....
I then decided to look at the file it was trying to read and in this case it's a Route's .TRK file. so I wrote a little code to basically parse the .trk file. after several hours trying to figure out why what I was seeing in the code (that I wrote) vs what was literally in the .trk file. I came across a interesting factoid.....Windows 10/11 and maybe an earlier version, but I know it's true for 10 and 11 are 64bit OS's. and because they are are 64 bit code the size of a word doubled in size. so to store a character from a text file it uses 16 bits vs 8 bits. All asci chars can be store in 8 bits....so what's in the other 8 bits ....0's.... essentially there is a null char. in every work that used to store a character, Now I'm using a tool called Visual Foxpro to do some prototyping. VFP is long out of date, and it's really a 32 bit software package that Microsoft dumped many years ago. but I'm pretty efficient in writing VFP code, and it's a object oriented language so I have to define classes similar to what's in C#. So I wrote a piece of code to parse the .trk files...The first thing I did was stripped out all the null characters in the file. then I wrote the file out as a .txt file and compared the two in notepad++. What's displayed is exactly the same. however the attached picture shows what happens when you strip out the nulls.....the file size drops in half. so I copied one of my .txt files into the route director backup the original .trk and renamed my .txt to .trk and started OR....no issues
just a little factoid.... ztrack.jpg
Interesting Factoid.....
While working on Activity Editor, I was looking at the STFReader Code. Since the STFReader is format Agnostic, you have to look at where the calls for the reader is....so more code mining....
I then decided to look at the file it was trying to read and in this case it's a Route's .TRK file. so I wrote a little code to basically parse the .trk file. after several hours trying to figure out why what I was seeing in the code (that I wrote) vs what was literally in the .trk file. I came across a interesting factoid.....Windows 10/11 and maybe an earlier version, but I know it's true for 10 and 11 are 64bit OS's. and because they are are 64 bit code the size of a word doubled in size. so to store a character from a text file it uses 16 bits vs 8 bits. All asci chars can be store in 8 bits....so what's in the other 8 bits ....0's.... essentially there is a null char. in every work that used to store a character, Now I'm using a tool called Visual Foxpro to do some prototyping. VFP is long out of date, and it's really a 32 bit software package that Microsoft dumped many years ago. but I'm pretty efficient in writing VFP code, and it's a object oriented language so I have to define classes similar to what's in C#. So I wrote a piece of code to parse the .trk files...The first thing I did was stripped out all the null characters in the file. then I wrote the file out as a .txt file and compared the two in notepad++. What's displayed is exactly the same. however the attached picture shows what happens when you strip out the nulls.....the file size drops in half. so I copied one of my .txt files into the route director backup the original .trk and renamed my .txt to .trk and started OR....no issues
just a little factoid.... ztrack.jpg
Comment