I am using a windows graphics package and would like to increase its functionality. Is it possible to patch some DOS code (from an existing DOS programme) to it. Paddy.
Posted on 2001-06-30 14:41:00 by paddy
Ummm, no. Completely different models of what the screen is and does.
Posted on 2001-06-30 16:46:00 by Ernie
Paddy, Ernie is right, DOS code works in an entirely different way which involved direct hardware access to things like video which in the normal sense cannot be done in Windows. You have a far more powerful range of options in 32 bit windows including direct draw if you want to develop in that direction. Perhaps the games guys could help here as they have the experience in working with Windows graphics. regards, hutch@pbq.com.au
Posted on 2001-06-30 20:05:00 by hutch--
Thanks for the replies fellas. What if I said that the sections of DOS code which I wanted to add to the windows programme did ABSOLUTELY nothing but calculations. i.e. these sections of code take numbers that have been placed in the appropriate memory locations by the windows programme and manipulate them without ever using an interrupt or communicating with the screen in any way. Paddy.
Posted on 2001-06-30 21:19:00 by paddy
Hi Now doing grafix in the DOS way is pretty easy using DirectDraw/DirectX, basicaly you create a VideoMemory surface, Lock it and by doing so obtain a pointer to a memory area that represents the video cards physical memory. Transfer your ald proggys final rendered image to this memory area, Unlock it and eventually do a Flip to get it on screen. However setting up a Window, a message loop, initializeing DirectX, and using COM intefaces is not so easy to understand for a DOS style programmer...but manageable. Using GDI is more diffrent from DOS. This means you do not get a pointer to the video card's memory and you MUST use windows API to draw things on screen. Also windows has a flat huge memory model (2Gigabytes linear) so one can forget old DOS stuff about EMS or XMS memory alocation or/and management Keyboard and mouse input can be done using DirectInput conceptually the same as in DOS (after initializations) ... but again not the same in code. DirectSound is also close to DOS way of playing sounds. Basically all DirectX (until version 8.0) is pretty much like DOS but NOT the same. Starting from version 8.0 ...3D operations are required even for 2D stuff ...( did i mentioned how stupid this is?...eh...good news is that one can still use DirectDraw7 style interfaces even on DX8...lucky COM specifications ;) ) I estimate medium size modifications (no you will not get by easy) to any DOS proggy to be ported to Windows. But IF you do only calculations...hmmm then ONLY 16 bit to 32 bit (eventually) coding modifications are required...self momdify code will also not work ...normaly.. This message was edited by BogdanOntanu, on 6/30/2001 9:35:56 PM
Posted on 2001-06-30 21:31:00 by BogdanOntanu
I agree it's probably time to redo the source for 32-bit. A DLL can do 16-bit code, but you would still have to redo all the variables, away from DOS and into Windows. Asm or not, if you just paste 16-bit code into a 32-bit program, it won't work; e.g. this 16-bit code: mov bx,1234h add bx,bx will look like this to the cpu in 32-bit mode: mov ebx, 0DB031234h
Posted on 2001-07-01 19:54:00 by Larry Hammick
Again, thank you for your replies. I am new to this game and have to admit that parts of these replies are over my head. The sections of DOS code in question are quiet large. Do I have to manually modify each line of code to read properly in 32 bit. The DOS programme was originally written in FORTRAN. If I had the original source code would it make things any easier. I suspect 'self momdify code' (BogdanOntanu) should read 'self modify code' but either way i dont know what this means. Paddy.
Posted on 2001-07-02 11:40:00 by Paddy