Data from ghost of Elvis
Blitz3D Forums/Blitz3D Programming/Data from ghost of Elvis
| ||
| I was rather surprised that Blitz gave ma a filehandle when I opened the NUL device. Now, as expected it returned zero when I used to readbyte from it. But then I was really surprised when it gave me some mysterious data when I used to writebyte to it!! pseudocode: re=openfile("NUL") while not keyhit(1) writebyte re, 255 print readbyte(re) wend closefile re On one computer I get some data at the beginning, on an other machine I get a frequent stream of mysterious data, and it builds some kind of pattern that I couldn't decode so far... So fpr now this data is declared "from the ghost of Elvis", until somebody has a better explanation ^^ cya |
| ||
| Well, you're supposed to be able to write to it - that's what it's for, so I wouldn't be surprised that Blitz allows you to use it: http://en.wikipedia.org/wiki/NUL: That posted code just lists zeroes for me. However, if you test it with Eof(re) istead of KeyHit(1), it ends immediately (as expected), so the stream is presumably returning EOFs (as designed). |
| ||
| The title of this thread gave me a cracking good laugh. XD Got to ask though; what in the hay is this NUL: file good for? Obviously it must have some use, but in my uneducated state I don't honestly see the benefit of writing data that disappears immediately and can never be read. It's like writing in a diary with disappearing ink. :/ |
| ||
| It's handy if you have a procedure that you want to run for its effects (for some unrelated reason), but that procedure also writes output to a stream and you don't want to keep the output. The Wikipedia example is a good one: "pause" normally writes "Press any key to continue...", but if for some reason you want a silent pause, you can run "pause > NUL" and the message will not appear (this would be incredibly annoying and unhelpful to do to someone, but it works as an example). You can test this at the Windows command line. Note that it makes most sense in the context of console applications, where everything has the three streams stdin, stdout and stderr (for input, output and errors, funnily enough), and all output is handled by writing to the output stream. This may seem a little odd coming from Blitz3D's world of drawing output to graphics contexts by default, where we would simply ...not draw... and a) know more about the output context and b) generally assume that we're drawing to the screen, for a human to view, whereas console apps often write to streams to be read immediately by other programs, potentially being only one link in an arbitrarily-long chain of piped-together programs. Last edited 2011 |
| ||
| Interesting that NUL works tho as I've tried other standard IO streams in the past without sucess i.e. to read/write from the console. EDIT: Tho I had to compile the exe to get standard API calls to the console to work but I was probably running the code from the IDE when testing native b3d file handling. Last edited 2011 |
| ||
| So I can relax and don't need no garlic and cristalls on top of my machine then... Noless, still a bit confusing, that massive Data stream I get on one machine. Anyone remember the days when a IMG SRC=C:/CON/CON used to freeze all machines in a chat? well we were young and stupid. (now getting older, but...) ;) BTW the reason why I tested this NUL device was: I was trying to write a file to its buffer, eg. a B3D Mesh, then use LoadMesh on that NUL Port, in the hope to be able to load it without to save it to the harddrive... No success so far. Last edited 2011 |
| ||
| Oh nice trick, if that worked would make loading from banks, network streams, compressed files, etc. a breeze. NUL even if it worked wouldn't be specific to the application but it might be possible with the console if someone can work out how to access that with b3d load commands :S Last edited 2011 |
   |