Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

win16 target: win 3.0 real mode bug? #1235

Open
ghost opened this issue Feb 14, 2024 · 3 comments
Open

win16 target: win 3.0 real mode bug? #1235

ghost opened this issue Feb 14, 2024 · 3 comments

Comments

@ghost
Copy link

ghost commented Feb 14, 2024

When trying following win16 example, after compiling with latest OW, the following win 3.0 problem occurs.

https://github.com/TransmissionZero/Win16-Example-Application

`The Open Watcom build of the application doesn't work correctly under Windows 3.0 when running in Real Mode. The application will start but the menu is missing and the about dialog won't display. I've found Open Watcom to be a bit hit and miss, where certain seemingly harmless changes of compiler option result in an application which crashes, so it may be possible to fix this by changing the compiler options. It runs fine under Windows 3.0 in Standard Mode and 386 Enhanced Mode.

The Open Watcom build of the application has optimisations switched off. With optimisations enabled, the application crashes on startup.`

@jmalak
Copy link
Member

jmalak commented Feb 14, 2024

I am not much familiar with Windows 3.0 real-mode, but probably full fat Windows prolog/epilog is necessary, option -zw (cases are important). Also there can be some assumption about segment attributes as fixed or movable etc. Next problem could be resources, resource compiler need to use -30 option and some other switch. I don't test OW for such target that I can not guarantee anything. I am not sure if there are some limitation in version to Windows 3.10 and above for default setup.

@joncampbell123
Copy link
Contributor

One important thing to know about real-mode Windows is that segments are movable, and therefore if you have a FAR pointer to anything, that FAR pointer will at some point become invalid when Windows moves segments and compacts memory.

One possible quick way to overcome that might be to call LockSegment(-1) at the top of the WinMain() function as a hack.

krnl386_000 raw1

@joncampbell123
Copy link
Contributor

As for resources, Windows in real-mode will not load resources unless you declare them MOVEABLE and DISCARDABLE because of real-mode memory management limitations.

Consider this example in DOSLIB which compiles all the way down to Windows 1.0:

https://github.com/joncampbell123/doslib/tree/master/windows/exmenus

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants