If anyone here is interested, a DOS game jam was announced recently for a streaming event called DOSember. https://itch.io/jam/dosember-game-jam Starts in a couple of weeks and lasts for three months.
DOS is an interesting platform because it can run on old hardware, and then basically anything else by way of emulation (such as in browsers) or via DOSBox.
If networking can be plumbed up, it's probably a legitimate and fun application platform for some uses that's worthy of investing time building on either for fun or for something real.
With some emulators (at least DOSBox-X) you can enable modern graphics modes that show up in SVGA in the emulated DOS and can be supported by DOS software just like any other modes. Anyone making DOS software today that isn't going explicitly for a retro look can try to detect and support a few modes like 1920x1080 and only fall back to more common old modes when necessary.
> If networking can be plumbed up, it's probably a legitimate and fun application platform for some uses that's worthy of investing time building on either for fun or for something real.
It's probably well suited to being a game console platform, too.
I've been playing around with raylib/raygui for cross-platform game/app development. It would be cool if it could target DOS. It probably could, but it sounds way beyond my current knowledge.
Yeah, I think the hard part would be graphics libraries for anything 3D.
I've always had a bucket-list item along the lines of "constructing basic game playing graphics primitives from scratch using the SVGA address offset for output".
MS-DOS (and games for it) ran on 486s, at the end. Writing MS-DOS games for a computer running many hundreds/thousands of times faster would probably allow for many more different types of approaches that could not be done on slow machines.
That sounds like a fun project! Would taking something like the DOOM source code, and extracting the "3d engine" from that be a workable approach? Or in your vision of it how would you make the primitives?
This might not exist, but could you recommend a text that _does_ cover refactoring for a functional and immutable approach? I would be interested in reading something like that.
Probably Peter Norton's Assembly Language Book for the IBMPC. Ray Duncan's Advanced MSDOS was another essential. If you want a bit more esoteric, The Undocumented PC by Frank Van Gilluwe.
I could name a few more but I probably shouldn't be admitting that I'm pulling these off my shelves :-)
Ah thank you! I currently have the MS-DOS Encyclopedia (not the first first edition https://blogs.msdn.microsoft.com/larryosterman/2004/06/14/do... which was apparently a little _too_ detailed) which is pretty informative. I'll track down your recommendations though.
Oh. Another one is Norton's Programmer's Guide to the IBMPC. Finally, one other book is Brown & Kyle's PC Interrupts.
I sold a shareware DOS file management program written in assembler (the file was about 30kb) for a number of years which is why I have all this obscure stuff :-)
The author talks about Graphite and Prometheus as instrumentation systems but they're for collecting data. What do people recommend as a linkable library for collecting metrics in the service process? (before it is collected). A quick google gave me 'go-metrics' and 'dropwizard metrics' but the code I'm working on will require linking with a native C library.
The author is a Go developer; if you are too, a good starting point is to use expvar and then whatever tool your collector provides for collecting expvars. Besides being in the standard library, there's the advantage of there being lots of tools that speak expvar.
Thanks for that. 'expvar' looks like a great hidden gem for go development. Unfortunately most of our services aren't written in Go so we might have to write our own if there isn't a handy library we could write bindings for.
Whenever I hear of a golang binding to a library implemented in C++ I'm always interested to see how they map the class hierarchy to golang's type model which doesn't have traditional inheritence.
Does QT's class hierarchy map cleanly to Go? Is it just interfaces everywhere?
(I'm not trying to start a language war, just genuinely curious.)
So it uses interfaces and anonymous fields. So if you are familiar with Qt, something like QPushButton would be implemented in go by having an anonymous field for QAbstractButton which would have an anonymous field for QWidget. Furthermore, this class has to implement an interface so it can be passed around like a normal QWidget in C++ would.
That was kind of a ramble, but thats the gist of it.