_OS$ Very interesting, but... - Printable Version +- QB64 Phoenix Edition (https://qb64phoenix.com/forum) +-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1) +--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3) +---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10) +---- Thread: _OS$ Very interesting, but... (/showthread.php?tid=1288) |
_OS$ Very interesting, but... - Pete - 12-16-2022 Rowin and Martin's Laugh IN aside, I don't quite get this about _OS$. The wiki states _OS$ ireturns the operating system that compiled the program. So If I compile a program in Windows, and a Linux user gets the .exe file, and runs it., all the _OS$ conditional statements can do is to indicate to the Linux user the exe was compiled on a Windows OS. It seems to me we would be better off having it or something else identify the OS the exe is actually running on, but maybe I'm missing some value here. I haven't used it before. Pete RE: _OS$ Very interesting, but... - SMcNeill - 12-16-2022 You can't run windows EXEs on Linux or Mac. (Well, perhaps in WINE, but that's kind of like a Windows-in-Linux experience. It's still not a linux executable.) Just like how you can't run 64-bit programs on a 32-bit OS... _OS$ works just fine. Take for example the difference in the forward and backwards slashes between file paths. As long as you compile with a windows version of cpp, that program is going to want the backslashes that windows uses. If you compile on a linux or mac version, that program is always going to want the forward slash. Even IF you copy that compiled executable over to another OS, it's not going to run unless it's got some sort of Virtual Machine or emulator on it, to work with it in that native format. (Linux subsystem on windows or WINE, for example, or even a full fledged virtual machine.) RE: _OS$ Very interesting, but... - Pete - 12-16-2022 I think I get it now. So this keyword is for non-compiled code, meaning if I post code here that could be compiled by by a Linux user (All compatible keywords) when that person compiled it, their _OS$ would show they compiled it on a Linux system and as it runs, if we encounter a situation when it needs to read a directory, it will branch to the Linux format with forward slashes, rather than the Windows one, which is the only OS that uses back slashes. Code: (Select All) IF INSTR(_OS$, "[WINDOWS]") THEN slash$ = "\" else slash$="/" If I missed something, let me know. If not, thanks for the explanation. Pete Old dogs can learn new tricks, but if helps if the neighbor locks up her poodle. RE: _OS$ Very interesting, but... - SMcNeill - 12-16-2022 (12-16-2022, 07:27 PM)Pete Wrote: I think I get it now. So this keyword is for non-compiled code, meaning if I post code here that could be compiled by by a Linux user (All compatible keywords) when that person compiled it, their _OS$ would show they compiled it on a Linux system and as it runs, if we encounter a situation when it needs to read a directory, it will branch to the Linux format with forward slashes, rather than the Windows one, which is the only OS that uses back slashes. You've got it. That's exactly what it's for. Though I tend to use the $IF routines more personally. Code: (Select All) $IF WIN THEN With the above, the precompiler choses one branch, or the other, and completely ignores everything else. When it comes to actually compiling, all of that's just a single line of code, with the assignment of slash$ dependent upon the users OS. RE: _OS$ Very interesting, but... - Pete - 12-16-2022 It all boils down to a preference, I guess; but now I feel bad for _OS$. Hey, if we boiled it down, would it make glue? Pete Channeling Deep Thoughts, by Jack Handy |