VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 400 of 2397, by truth_deleted

User metadata

I think I have the necessary bits and am able to fully test your PS/2 emulation, at least the latest version (and also your "non-recursive" core mode and IDE updates). I read through other extensive updates, such as dynamic assignment of reserved memory and the loading of particular executables. From reading your excellent documentation here and in your emulation code, I believe those updates often find application in loading the older DOS and early Windows versions. I also read though the code for "shut down" and rebooting a guest operating system. I haven't tested that code, but I've wondered if that is necessary for installation of NT 3.1; I've assumed that it is, otherwise the non-DOS installation step will not proceed. Last, I appreciate your correcting the greater code base, where possible, of memory leaks.

I also noted extensive additions to the ET4000 video emulation, although I merely read through those changes. It references the hi-color modes and I assume this is necessary for NT 3.1 compatibility with the better video modes.

I had not realized fully, if this is even possible, of how extensively you have added new emulation and code "corrections". I can appreciate your survey though the Windows and DOS operating systems, starting with 1.0. 😀 For running 9x, the "non-recursive" mode and PS/2 mouse emulation are particularly important. This mode will allow more recent 9x games to run which would page fault previously, including Alpha Centauri and Half-life where using CD audio; although your PS/2 fixes may have cured that problem, too. I also look forward to testing your PS/2 emulation with regular Windows 3.1, as I noted tweaks for mouse control in your code.

Reply 401 of 2397, by truth_deleted

User metadata

Is the change below as intended? It looks like the new line of code should begin with "Real_WriteChar" instead of "INT10_WriteChar".

@@ -342,9 +479,10 @@ bool device_CON::Write(Bit8u * data,Bit1
case 'K': /* erase till end of line (don't touch cursor) */
col = CURSOR_POS_COL(page);
row = CURSOR_POS_ROW(page);
- INT10_WriteChar(' ',ansi.attr,page,ansi.ncols-col,true); //Use this one to prevent scrolling when end of screen is reached
+ INT10_WriteChar(' ',ansi.attr,page,ansi.ncols-col,true); //Real_WriteChar(ansi.ncols-col,row,page,' ',ansi.attr,true);

And I included a left bracket after "if (player.channel == NULL)", at least in my case:

@@ -138,7 +138,7 @@ CDROM_Interface_Image::CDROM_Interface_I
images[subUnit] = this;
if (refCount == 0) {
player.mutex = SDL_CreateMutex();
- if (!player.channel) {
+ if (player.channel == NULL) {
player.channel = MIXER_AddChannel(&CDAudioCallBack, 44100, "CDAUDIO");
}
player.channel->Enable(true);

Reply 402 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
truth5678 wrote:
Is the change below as intended? It looks like the new line of code should begin with "Real_WriteChar" instead of "INT10_WriteC […]
Show full quote

Is the change below as intended? It looks like the new line of code should begin with "Real_WriteChar" instead of "INT10_WriteChar".

@@ -342,9 +479,10 @@ bool device_CON::Write(Bit8u * data,Bit1
case 'K': /* erase till end of line (don't touch cursor) */
col = CURSOR_POS_COL(page);
row = CURSOR_POS_ROW(page);
- INT10_WriteChar(' ',ansi.attr,page,ansi.ncols-col,true); //Use this one to prevent scrolling when end of screen is reached
+ INT10_WriteChar(' ',ansi.attr,page,ansi.ncols-col,true); //Real_WriteChar(ansi.ncols-col,row,page,' ',ansi.attr,true);

And I included a left bracket after "if (player.channel == NULL)", at least in my case:

@@ -138,7 +138,7 @@ CDROM_Interface_Image::CDROM_Interface_I
images[subUnit] = this;
if (refCount == 0) {
player.mutex = SDL_CreateMutex();
- if (!player.channel) {
+ if (player.channel == NULL) {
player.channel = MIXER_AddChannel(&CDAudioCallBack, 44100, "CDAUDIO");
}
player.channel->Enable(true);

I removed the brackets around the single player.channel = MIXER_AddChannel() assignment, yes. It's only one statement and it's indented clearly.

The other one I believe was inherited when I pulled code in from Taewoong's branch.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 403 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Another update

http://hackipedia.org/Projects/DOSBox-X/dosbo … cfe1-src.tar.xz

commit 5c9842baa4060e8acad0ffe82fd1bc0e87c6cfe1
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Wed Apr 23 16:46:15 2014 -0700

updated notes and bugs regarding demoscene entry "Majic 12: Show" and
why and when it triggers a "MCB list is corrupt" error message in
DOSBox and how to reconfigure your dosbox.conf to work around it.

It turns out the demo (perhaps the graphical effect routines) clears and
overwrites memory in the 0xC0000-0xCFFFF range. If DOSBox has any
private areas or upper memory blocks there, the data there will be lost.
If upper memory blocks exist up there, they will be lost and DOSBox will
E_Exit() with a message stating that the MCB list is corrupt. When I
added code to dump the MCBs, I saw that when this happens, the MCBs
below the 640KB boundary are OK, the MCBs in the upper memory are zeroed
out.

commit e77b8abff3cce4afebe820f86f271fbf6efaedea
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Wed Apr 23 16:32:27 2014 -0700

DOS MCB debugging: Instead of just exiting with "MCB list corrupt", show
the MCB list on STDERR before shutdown so that I can see where it got
corrupted.

commit a5f6cf3ea51c18b7ea6421c10b7ede2f659efa20
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Wed Apr 23 15:54:51 2014 -0700

add configuration option to control the size of the DOSBox command
shell's environment block. the option does not apply if using mainline
compatible mapping. adjusted code to make room for it in the DOS kernel.
You can go as low as 16 bytes or as high as 65536 bytes.

commit dd684216833cf7eed996c58bc51d580d3aa3be64
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Wed Apr 23 15:15:33 2014 -0700

whoops. SetEnv() checking needs room for two NULs not one.

commit 8ad5fa925181f54b8b90cf42b5497e7ac77f65cb
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Wed Apr 23 15:05:14 2014 -0700

Program::SetEnv() fix: before removing the variable, make sure there is
room to insert the new value.

commit ace263384c5284fda43db82fccba725b2e8446ed
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Wed Apr 23 14:59:20 2014 -0700

Found stack buffer overrun issue with Debug GUI LOG() function where, if
the error message is long enough, it will overwrite the stack with part
of the message and crash.

This bug was discovered by using really long environment variable
strings, which apparently triggered the LOG() call.

commit 8b499088056c4ca11b683085d9d175ee6f253a9e
Author: Jonathan Campbell <jonathan@castus.tv>
Show last 57 lines
Date:   Wed Apr 23 14:55:31 2014 -0700

add #ifdef for non-dynamic core case

commit 5f6e18d66c7a27b19cab9a8db69e1eb5baccfc66
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Wed Apr 23 14:21:33 2014 -0700

DOS shell: assign environment block from middle of DOS_FIRST_SHELL to
DOS_FIRST_SHELL_END instead of assuming DOS_FIRST_SHELL to
DOS_MEM_START. Wrote new Program::SetEnv() implementation that's less
messy and respects the boundaries of the segment allocated to the
environment block.

commit e1aa849af85fc10c04c135ba00030b5ccd45529c
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Wed Apr 23 13:37:52 2014 -0700

Define DOS_FIRST_SHELL_END variable to mark the end of the shell's
workspace. The reason this variable is needed is because DOSBox-X's
dynamic allocation mode permits additional allocation to happen before
determining the value of DOS_MEM_START. And the reason that is important
is because the DOS shell builtin assumed that it could use the area from
DOS_FIRST_SHELL+19 to DOS_MEM_START as it's environment block, when it
turns out the dynamic allocation method would have already assigned the
extra space to certain DOS kernel structures. Oops!

commit c1616914eb3f3aaee69d1f660cf3e8972d72d837
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Wed Apr 23 13:12:46 2014 -0700

cosmetic change

commit 684e12b2eaf64566e3ebb2ee6a61793a42e7d70f
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Wed Apr 23 13:06:56 2014 -0700

DOS shell: rewrite %variable% substitution to better emulate Win95
COMMAND.COM including how '%%' becomes '%' as well as check during the
process for string overflow conditions. Prior to this fix, the DOSBox
expansion code did not expand '%%' => '%' and if the string was long
enough, could overflow the temp[] array on the stack. Fixed command
input history buffer code to store the command PRIOR to expansion,
instead of after, the way Win95 COMMAND.COM and DOSKEY would do it.

commit 93cda948837b55ffe193ba2107a41cf52e52df68
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Wed Apr 23 12:17:22 2014 -0700

Internal DOS command "SET" code fixed. Removed variable substitution
code. The COMMAND interpreter built into DOSBox already does the
variable substitution, the parsing in CMD_SET was redundant and likely
not used anyway. Additionally, the CMD_SET expansion code that was
removed had a buffer overrun bug where a large environment variable
could overflow the 4096-byte buffer on the stack and cause problems.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 404 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

To explain some of the changes: I noticed that if I run the DOSBox command line, run MSVCVARS.BAT from \MSVC\BIN (Microsoft Visual C++ installation), then boot into Windows 3.1, bring up a command line, add more environment variables, and then run any DOS program, the system would crash or run erratically as if memory were corrupted (because it was!). The previous SetEnv() implementation did not range-check to determine if there was sufficient room in the environment block for another variable.

While digging around in that part of DOSBox, I also cleaned up the %variable% expansion code. Apparently the "SET" command routine was expanding the string when the DOSBox shell was already expanding variables! Also noted and fixed several places where that variable expansion could have easily overflowed the temp[] array on stack and corrupted the call stack if the environment variable was long enough. Variable expansion is now done in a way that emulates COMMAND.COM on Windows 95, including %% => % and various noted quirks.

Apparently this also resolves a bug I noted with Open Watcom's installer causing MCB corruption warnings.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 405 of 2397, by truth_deleted

User metadata

Thanks for the additional updates! UT99 is the only game that is not "non-recursion" core friendly (same in other cores which have this feature), so I ran it with IDE and "non-recursion mode" off; however, enabled your PS/2 mouse emulation along with the "memory leak" updates, and noted the overall increased stability in loading and running the game, and responsiveness of the mouse during gameplay.

I also disabled the DOS mouse program, so I reverted a line of code back to original (float dy). It seems that it should be correct and that the change corrected an error when running the DOS mouse after exiting Windows (but since I disabled the DOS mouse program, then it shouldn't be required?).

 void Mouse_CursorMoved(float xrel,float yrel,float x,float y,bool emulate) {
+ //extern bool Mouse_Vertical;
float dx = xrel * mouse.pixelPerMickey_x;
float dy = yrel * mouse.pixelPerMickey_y; //Original line here
+ //float dy = (Mouse_Vertical?-yrel:yrel) * mouse.pixelPerMickey_y;

Edit: Win3.1 works great with your PS/2 mouse emulation. I set int33=false for this case. 😀

Reply 406 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
SA1988 wrote:

when the menu is disabled, no errors are detected, so, there's something wrong in the gui menu.

OK, I figured it out:

Remember when I said that whoever wrote the INT 33h emulation didn't know that mem_readb() could cause page faults?

The Win32 GUI code also didn't know that apparently.

The reason accessing the menu causes a fault in Windows NT is because the ReflectMenu function in src/gui/menu.cpp is reading the current PSP segment from the DOS SDA and then reading the memory control block. This is obvious because when NT shows a dump describing the page fault it always shows the fault as happening in virtual memory address 0x00000B30 (the DOS SDA area). Again, that information by this point is LONG GONE and overwritten by the guest OS, and Windows NT maps those pages not present, so the DOS_MCB object only succeeds in triggering a page fault in the guest.

That code in the ReflectMenu function only serves to read the current DOS program name from the MCB apparently, so I modified that code to not read that information if booted into a guest OS. It apparently worked, I'm able to access the Win32 menu without causing faults in NT (though most of the functions in the menu still trigger a fault, so I have to dig deeper).

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 408 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Another update

Source: http://hackipedia.org/Projects/DOSBox-X/dosbo … 69ca-src.tar.xz

Win32 binary: http://hackipedia.org/Projects/DOSBox-X/dosbo … 369ca-win32.zip

commit ddcedf25f10cd2f0f868426b83cb6ca126f369ca
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 02:19:54 2014 -0700

more work

commit 794de83e318a2cb2ba7f8672c571f496b4902f9e
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 01:45:01 2014 -0700

more fixes for possible NULL pointer de-refs in GUI code.

commit 81e7164b899de8432782d8200f1f973299e332dc
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 01:35:40 2014 -0700

SDL GUI: modified "first_shell" computation to never read DOS PSP
segment values if booted into guest OS. This resolves the bug where
bringing up the keymapper or any of the GUIs causes NT to crash or
DOSBox to hang when exiting back to emulation.

commit 95c2e4f9a451192ba620403bedfe6b19d4713c5e
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 01:07:04 2014 -0700

more work, cleanup

commit 1ccdb4422b485a2193675f7c21f86884581aeb24
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 00:41:15 2014 -0700

bugfix: ShowGUI command updated to properly force screen redraw after
"fading back and un-blurring to" the emulator. the ShowGUI command had
the same problem as the DOSBox keymapper screen in that after returning,
the screen would become black with "fragments" showing where things
changed.

commit ee60c789a7300d09417022ede9bd7b0e1d218e4c
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 00:38:14 2014 -0700

bugfix: keymapper screen now correctly triggers redraw of the screen
when returning to the emulator. prior to this fix, entering the
keymapper screen, and then exiting back resulted in a black screen with
"fragments" visible whenever something changed, instead of a full redraw
of the screen.

commit 16516703e01eed9caa8e68e4653f42ef1dc76104
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 00:17:08 2014 -0700

cleanup script: delete VS2008 build logs too

commit 7e6d9e25c468622be23a88acbee37e121dbc872e
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 00:15:10 2014 -0700

DOS kernel: Modified psp() and dta() functions to print BUG message and
ignore attempts to read/write PSP and DTA segments IF booted into a
guest OS.
Show last 115 lines

commit b4c6945e67e128a9d94e41753a13d729b12df3a2
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 23:55:05 2014 -0700

some Win32 build testing, cleanup, update cleanup script

commit a56bacecb7750bda6057c23d44a72d56e0f0d658
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 23:46:40 2014 -0700

Don't read DOS PSP MCB if booted into a guest OS. This resolves Windows
NT "instant BSOD" if you click on the menu bar in the Win32 build.
There's still plenty of commands within though that trigger the same
issue.

You can tell if the DOS PSP MCB is involved by whether or not Windows NT
points to memory address 0x00000B30 as the page fault address.

commit 78c652b25ebb7314f755de2b6cdfac03a35c73ba
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 23:21:49 2014 -0700

a-ha... my Win32 build all this time forgot to compile the windres.rc
resources as well. This made the menu appear, which allows me to see
what other members on the forums mean when "clicking on the menu causes
Windows NT to BSOD"

commit 399886b8e444b41689edf6c060f2907cd36457a8
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 21:26:08 2014 -0700

remove more DISP2

commit 5442dfc16e34fae3560923955131ff9f322995e6
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 21:24:45 2014 -0700

remove more DISP2

commit 6c321592de8deac8befe9506d71640a17a2f643b
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 21:24:11 2014 -0700

remove more DISP2

commit e97f8d6ac121826eed4e210d46e55f92123002c1
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 21:23:30 2014 -0700

remove more DISP2

commit f582a33f35a91ff726f8841dedda69d0e25b60d9
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 21:21:59 2014 -0700

remove more DISP2

commit 5ae47920bb2bb703d6a4da8bf2404da253a3da5c
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 21:19:58 2014 -0700

remove more DISP2 code

commit de2c5c37d253d6c5a7aea65189df7f1eeca6f588
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 21:17:28 2014 -0700

remove display2.cpp code

commit 246c716690d4e969f636812b6145b1e1fca2c073
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 10:02:03 2014 -0700

and... another one

commit 8d6ee450a3b972f7e3177587816dc2a778ce1a8e
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 10:01:22 2014 -0700

minor correction to dump information

commit 5a569758d7de4685b984b2e4f37e8fc4de80b9ee
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 09:58:58 2014 -0700

Added shell INT2FDBG command. Command, when given the /I switch, hooks
INT 2Fh at the head of the call chain. This way, the DOS kernel can see
the Windows init broadcast at the bottom of the chain (before anyone
modifies registers) and the hook can see the resulting chain just before
it's returned back to WIN.COM.

commit bcd404dbfc1f9808a6cb301d388b75b6c2449402
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 08:28:55 2014 -0700

BOOT command updated to uninstall and remove INT 2Ah and INT 2Fh vectors
before booting guest OS.

commit d2e8804354d541784931f9d6f0561b579078dcd6
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 08:15:51 2014 -0700

add program code to print out debug information regarding the Windows
init and exit broadcast calls (INT 2Fh) as well as the INT 2Fh device
callouts.

commit bc727debb30f986ebdc114760a8755f4e4b6cabb
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Fri Apr 25 01:25:55 2014 -0700

complete rewrite and cleanup of Program:: environment variable functions
SetEnv, GetEnvCount, GetEnvNum, GetEnv, etc.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 412 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
SA1988 wrote:
collector wrote:

Downloaded without issue for me.

can you post it to another website or on dropbox please? hackipedia hates my download speed.

I realized how large my source tarballs were getting and made some changes to how they're made to keep the size sane.
First, I updated the script that packs the tarball to exclude the .git repository section.
Then, I went into the vs2008 directory and removed source code that wasn't being used by the Win32 and Linux builds.

http://hackipedia.org/Projects/DOSBox-X/dosbo … rc-nogit.tar.xz

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 413 of 2397, by truth_deleted

User metadata

Thank you for this updated release! I noted the disabling of INT2h for booting into an OS and also the work on the psp/dta functions.

I've also noted a ~5% speedup in DOS and Windows games, using (GL)Quake as a benchmark test. I believe this speedup occurred at the time of the memory leak patches. The shutdown "on boot" code is elegant along with your understanding of the memory paging process. It seems like much of the hurdles of booting an "advanced" OS is with the paging process and removing some of the DOS only functions.

Since the DOS kernel is disabled on booting an OS, would this remove functions if booting from a DOS image?

Reply 414 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
truth5678 wrote:

Thank you for this updated release! I noted the disabling of INT2h for booting into an OS and also the work on the psp/dta functions.

I've also noted a ~5% speedup in DOS and Windows games, using (GL)Quake as a benchmark test. I believe this speedup occurred at the time of the memory leak patches. The shutdown "on boot" code is elegant along with your understanding of the memory paging process. It seems like much of the hurdles of booting an "advanced" OS is with the paging process and removing some of the DOS only functions.

Since the DOS kernel is disabled on booting an OS, would this remove functions if booting from a DOS image?

Yes. DOS kernel functions are removed and disabled when you BOOT a guest OS, even if the guest OS is MS-DOS. Your BIOS doesn't provide DOS-level APIs like INT 33h and INT 21h when booting an OS so why should DOSBox?

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 415 of 2397, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Another update, then I'm done for awhile 😀

Source code: http://hackipedia.org/Projects/DOSBox-X/dosbo … rc-nogit.tar.xz
Win32 binary: http://hackipedia.org/Projects/DOSBox-X/dosbo … 97290-win32.zip

commit b9de4fe3ec301beda34c04d0b08fee28c9d97290
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 23:05:55 2014 -0700

more? goddammit Visual Studio I'm going to autodelete this file if you
keep modifying it for no reason!

commit 8a821b9a72cfbc8ad2d2f50dc8a70a76b043edc8
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 23:05:20 2014 -0700

more?

commit a861c0c2d9a545f967eda4c37b3a8a5d38ed62c6
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 22:32:44 2014 -0700

hm? Visual Studio leftover?

commit e85c7c56b27c0a9245751035da0365ef0bfe0826
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 22:32:13 2014 -0700

SDL GUI: Modified buttons to only respond to left click.

commit b5137c5af184d83f7dc188aa0023857d80286bbc
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 22:26:09 2014 -0700

SDL GUI: Feed the GUI a proper time source (unlike the code prior to
this commit). Fixed double-click detection logic. Double-clicking the
system menu on a window will now reliably close the window. Removed test
code from SDL GUI.

commit 1d5a94ea0af07d61a4d2c458f093c856411a89b6
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 20:44:23 2014 -0700

SDL GUI: Double-clicking the system menu changed to send "Close" event
in the same way that selecting "Close" would trigger it. This allows
both selecting the item AND double-clicking to have the same effect,
just as it does in Windows and most other GUIs.

commit ad18b9d7648710384137d4febe4ba5baacc997cb
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 20:21:25 2014 -0700

SDL GUI: Remove all but "Close" from the system menu (with reminder to
self that future Window objects might wish to selectively enable the
other commands). The GUI doesn't actually implement "Move" "resize"
"minimize" "maximize" and "restore" so why have them there?

commit 4ab99aa44170147307f91170f7dd4b073f593bc7
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 20:13:49 2014 -0700

SDL GUI: Add code to catch "Close" event that can be sent from the
"System menu" of the window. Prior to this fix, clicking "OK" and
"Cancel" acted as expected, returning to emulation, while selecting
"Close" from the system menu did not (Windows disappears, but emulation
Show last 57 lines
    does not resume).

commit a6c05e224575631da045a592026047595437ef4d
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 19:52:05 2014 -0700

Win32 menu: remove save state entries, clarify what "Automatic
execution" means

commit 211408aa28f9d84c3f3ace52be106bb440b657f4
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 17:14:01 2014 -0700

whoops

commit 8cf1e1cc4fa146c11b520e789b66a81c207115cd
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 17:13:06 2014 -0700

more

commit 09c48c0b579fdc0db09de71724a6731ad7f1daf9
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 16:54:25 2014 -0700

more

commit 0db74ed319dc95ef7af4f2f7adbce72cf5f3f81c
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 16:48:21 2014 -0700

more

commit 6f203fbbe2012bef498ea185bf9caa093b25795c
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 16:26:14 2014 -0700

declare utility function static inline. reorder constructor variable
assignment. fix "flags" variable in SDL video init, which was another
coding mistake of redefining "flags" in an inner scope expecting to use
"flags" from the outer scope without consideration of what the compiler
would actually do with the statement.

commit bc7ae4bdd79897f7bf841a76ebef50a9dcce3239
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 16:09:16 2014 -0700

some cleanup

commit 6248e3fb2085c6f831b00b7922018fcd518ff751
Author: Jonathan Campbell <jonathan@castus.tv>
Date: Sat Apr 26 15:50:58 2014 -0700

remove unused char suffix[] from cpu.cpp.
Looks like the "configure" script finally updated in the -Wall change

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 416 of 2397, by truth_deleted

User metadata
TheGreatCodeholio wrote:

Yes. DOS kernel functions are removed and disabled when you BOOT a guest OS, even if the guest OS is MS-DOS. Your BIOS doesn't provide DOS-level APIs like INT 33h and INT 21h when booting an OS so why should DOSBox?

I understand now. 😀 Also, thanks for the additional updates to the GUI and CPU code!

Reply 417 of 2397, by Bandock

User metadata
Rank Newbie
Rank
Newbie

For anyone who is trying to compile the code through Visual Studio 2013 (possibly Visual Studio 2012), you will or have gotten the following (or similar) error:

Error	11	error LNK2005: _strtoull already defined in LIBCMTD.lib(strtoq.obj)	E:\DOSBox Source\dosbox-x\vs2008\* CIL library *(* CIL module *)	dosbox-x

There is a way to correct it and get it to compile. Make sure to comment out the entire custom strtoull function found in 'dosbox.cpp' (that includes commenting out the #ifdef preprocessor along with the #endif preprocessor). For some reason, it does not recognize that later versions now have their own strtoull function.

This should help any one of y'all out in getting it to compile under Visual Studio 2013 and maybe Visual Studio 2012 (works even on Express Editions, though make sure to comment out any 'afxres.h' presence). Another word is to make sure to use the Windows XP Toolset to make it use Windows SDK 7.1a unless you want to remove compatibility with Windows XP systems.

Edit: I have now confirmed that the issue only exists so far in Visual Studio 2013 (which may also affect future versions). Strtoull was added finally to Visual Studio 2013. Here's some updated code to implement support for compilation on Visual Studio 2013:

/* TODO: move to utility header */
#if _MSC_VER < 1800 /* Microsoft C++ does not have strtoull */
unsigned long long strtoull(const char *s,char **endptr,int base) {
return _strtoui64(s,endptr,base); /* pfff... whatever Microsoft */
}
#endif

Anything earlier than the compiler supplied with Visual Studio 2013 will use that code.

Reply 418 of 2397, by truth_deleted

User metadata

ReactOS (extract jar file) boots in jDOSBox (attached picture below). However, DOSBox+enhancements (major emulation featured in DOSBox-x) results in this error when booting ReactOS: INT13: AH=41h, Function not supported 0x55aa for drive: 0x0.

Filename
jdosbox_boot.JPG
File size
31.61 KiB
Downloads
No downloads
File comment
jDOSBox booting ReactOS
File license
Fair use/fair dealing exception

Reply 419 of 2397, by Bandock

User metadata
Rank Newbie
Rank
Newbie

I have noticed recently that upon closing, DOSBox-X crashes (even with the provided Win32 Binary Build). Doing some debugging on it, I have found that it is trying to deallocate memory for different lists that were never allocated (or not properly allocated) in the first place. I have found that applying a condition to check if 'is_dummy' is false that it would delete/deallocate the memory for lists in reference to the Joystick.

Not sure if it was intended or not, but I tested it already with the conditional check. No more crashing upon exit.

Edit: I forgot to mention that turning off joystick support does not result in crashing. Only with it enabled (before fixing it of course).