Compiled Under Win2000
Author
I wrote a game (Escoba, check it out in the gds) and compiled it under Win2000. It works great under 2000 and NT but with 98 it gets a game stopping bug a few seconds into it. I don''t believe I put anything in the code (C++ with MSV v6 just using WINAPI) that is 2000 specific. So basically I am wondering if just compiling something under 2000 can make it incompatible and if not why it would be doing this. And if that is true, I have been having a horrid time trying to find a computer with 98 and MSV v6 on it and would appreciate it if someone with that would compile it for me.
Thanks,
Scott (oldfiesa@muohio.edu)
I''ve experienced problems like this as well. For me, it wasn''t that I was simply "compiling in 2000", it was that things tend to work better in 2000.
Check your code to see if all your memory allocation is working (no lost pointers or damaged blocks), and also check to see if you are using any archaic Windows functions because 2000 might just route them to newer functions, whereas 98 might not.
Check your code to see if all your memory allocation is working (no lost pointers or damaged blocks), and also check to see if you are using any archaic Windows functions because 2000 might just route them to newer functions, whereas 98 might not.
Windows NT/2000 handles various things like memory a little different from 95/98/me. Its possible that there really is a bug, that just so happens doesn''t show up in 95/98. For me it was the other way around, and 2000 showed a bug that 98 didn''t. I''ve since fixed it, and like you now develop in 2000 & test in 98. To fix your bug, try tracing it to the line of code that''s causing it, and see what''s being done there.
Some other common things you may be doing which aren''t the same on all platforms:
Unicode/WideChars - Windows2000/NT supports it properly, Win9x/ME doesn''t so passing L"" strings to everything isn''t going to work on 9x.
Asyncronous I/O - Win9x/ME doesn''t do it since its still got loads of legacy stuff from the DOS/Win3.1 days.
Security - Win9x isn''t the same (it isn''t secure) - many of the security functions don''t exist or have no effect.
Memory access, allocation and protection, threads, the file system, address space layout etc could all have an effect but only if you''re making bad assumptions about how its working (the kernel changes - relying on a certain undocumented behavior is bad, as is not checking caps flags and error codes!).
"Jobs" - not supported on 9x
--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com
Unicode/WideChars - Windows2000/NT supports it properly, Win9x/ME doesn''t so passing L"" strings to everything isn''t going to work on 9x.
Asyncronous I/O - Win9x/ME doesn''t do it since its still got loads of legacy stuff from the DOS/Win3.1 days.
Security - Win9x isn''t the same (it isn''t secure) - many of the security functions don''t exist or have no effect.
Memory access, allocation and protection, threads, the file system, address space layout etc could all have an effect but only if you''re making bad assumptions about how its working (the kernel changes - relying on a certain undocumented behavior is bad, as is not checking caps flags and error codes!).
"Jobs" - not supported on 9x
--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com
If u look on ure windows cd "\suport\tools\" run the setup exe. this istalls the supost tools that has a program called "Application Compatibility Tool" which lets u fake which windows os ure using and has some options on it to desable windows 2000 specific features so u can find out whats hapaning. Also it doesnt mater what windows ure compling on whic decides what windows ver ure prog will work on. its some of the functions/headers u use, the msdn used to tell u what os function ''s required
~prevail by daring to fail~
~prevail by daring to fail~
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
