The DOS VDM reentry feature consists in being able to perform a suite of actions similar to this one:
- Start a first DOS app,
- from it, start a 32-bit application: NTVDM should suspend itself and wait for the 32-bit application to either terminate, or to start a new DOS app.
- If the 32-bit app terminate, NTVDM should resume and give main back to the old DOS app. If the 32-bit app starts a new DOS app, NTVDM should resume and start the DOS app.
- When the new DOS app stops, NTVDM should suspend and give main back to the 32-bit application, if it still exists; otherwise it should resume the old DOS app.
More complicated sequences of events can be considered, for example:
- Start DOS app (D1);
- (D1) starts 32-bit app (W1);
- (W1) starts DOS app (D2);
- (D2) starts DOS app (D3);
- (D3) starts 32-bit app (W2);
- (W2) starts DOS app (D4);
- (optional: (D4) starts 32-bit app (W3))
- user force-kills the 32-bit app (W1): NTVDM should continue executing (D4) (for optional case: NTVDM should still wait for (W3) to terminate or start a new DOS app);
- user stops in reverse order: (D4), (W2), (D3);
- when user stops (D2), control should be returned to (D1) immediately without any hang, because the intermediate 32-bit app (W1) was killed previously.
Note that on Windows' NTVDM, in case you perform optional step 6(optional), then step 7, NTVDM immediately gets control back to DOS app (D4), even if it was 32-bit app (W1) that was killed (and not 32-bit app (W3)).
Also note that in either case, if you perform step 7 (kill 32-bit app (W1)) and you gracefully terminate in reverse order the DOS and 32-bit applications: (D4), (W2), (D3) and (D2), Windows' NTVDM never give control back to the initial DOS app (D1) but instead, waits for a next DOS app to be started.
I think that those two last points can be fixed in a smart way in our NTVDM implementation.
(EDIT: Get/SetCurrentVDMDirectories should also be implemented in order to update the list of current directories stored internally by basesrv: see CORE-9427 )