Reply 1460 of 2409, by hail-to-the-ryzen
There are other areas with: #if defined(WIN32). Perhaps in SDL_video.c.
There are other areas with: #if defined(WIN32). Perhaps in SDL_video.c.
Verified it was defined in the removed directx5 code. Probably better to propagate the definition WIN32 in a header file than renaming the single instance of it.
In the latest code, I am developing a platform independent menu system for DOSBox-X.
Where DOSBox SVN and DOSBox-X used LoadMenu() to load a menu resource, the new code constructs it using a C++ framework I have developed.
The code will create a menu resource in Windows, or on other platforms will hold the menu in memory without causing problems.
The intent is that eventually this C++ framework for menus will allow the same menus to display on Windows, Mac OS X, and Linux instead of Windows-only menu resources.
The design of it also permits rearranging the menus in the code, and some cleanup between menu.cpp and sdlmain.cpp.
Notes on the changes are given on the release page.
Release 0.82.6 is the last official release to use the Windows menu resource (IDR_MENU) and allow compilation with pre-C++11 compilers.
Other changes:
- The code now requires a C++11 compiler
- Patches have been accepted from another user on Github for VHD image support
- The mapper now has a 4th modifier "key" called the host key (much like VirtualBox). The intent is to move the mess of default mapper shortcuts so that they all tie into the Host key instead of taking up shortcuts likely to conflict with DOS and Windows 3.1 applications.
I released a Work in Progress binary to Github for anyone who wants to poke at it and comment on it. The commit number listed is the commit it is compiled from. Have fun.
https://github.com/joncampbell123/dosbox-x/re … p-20180506-1805
wrote:I think ... i have it found.
I applied a patch some time back that corrected OF and CF flag behavior for SHL.
It's possible the game developer relies on OF and CF somehow for long division.
However I had also discovered a PC-98 game at the time who's sprite rendering (decompression?) routines also relied heavily on OF/CF SHL behavior, where prior to the fix the sprites were misrendered and glitchy.
wrote:I have a question. I know you've repeatedly said that the dynamic core was removed because you couldn't get it right with page fault handling, but will you ever get that problem sorted out and allow the dynamic core to work STABILY with page faulting (i.e. Windows 98), at least in 32-bit? I know you've recently restored the dynamic core, but as you said, it doesn't work with paging because it's incompatible with the current emulation code. So probably no Win98.
The reason why I am asking this is because I am planning on trying to install Windows 98 SE again and am worried that it will run too slow just as the version I tried last summer did (I set the core to normal and it had major performance issues with even some less demanding games as said before, but I tried an earlier version which had the dynamic core from early 2015 and it worked at full speed).
Will you be able to add this sometime in the future? Personally, it seems much more important to me than fixing PC-98 games and such. So will this ever be "fixed", or will I have to use a really old version? Or is there some OTHER way to run Windows 98 SMOOTHLY in the current version without the dynamic core AND without a huge performance dip?
A patch was submitted to re-enable paging with dynamic core, but only if you set an option in dosbox.conf.
It is off by default, because sooner or later, a page fault happens that causes a problem with dynamic core and Windows 95 gets a little crashy. Or worse, the page fault handling defers to normal core and never returns to dynamic, negating any speed advantage.
wrote:... Personally, it seems much more important to me than fixing PC-98 games and such.
I have an easier time implementing PC-98 mode improvements than figuring out what or how the dynamic core works, and it's more interesting to do at this time.
I dunno if this has been mentioned before but a cool addition to Dosbox-x would be support for td0/imd floppy images of floppy games with copy protections. I've never cared about that until now: I bought a game protected with keydisk and I can only play it with original floppy on vintage machine or in Pce emulator with imd image.
"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"
wrote:I dunno if this has been mentioned before but a cool addition to Dosbox-x would be support for td0/imd floppy images of floppy games with copy protections. I've never cared about that until now: I bought a game protected with keydisk and I can only play it with original floppy on vintage machine or in Pce emulator with imd image.
I'll need an example image file and a specification on the file format, then, yes, I can do it.
If no specification is available, source code in another emulator project will do.
If I can write a program that can generate such images, then there are some 5.25" floppies I would like to image in it as well.
I recently went through my box of 5.25" floppies with the floppy test program in DOSLIB and a copy of "Where in the world is Carmen Sandiego?" has a copy protection scheme that would be perfect to develop this with. It seems to have an extra 256-byte sector with sector id=241 on track 10.
I redirect u here. As you can notice from the sshot, Knight Force has a corrupt sector near the end of floppy disk, if you copy the disk with standard dos commands or if you make a floppy image that ignores or discards such sector, the game will not show ingame sprites. I still have to undestand if the problem I encounter when beating final boss is a game bug or it's due to modded exe.
"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"
Is there a method for dosbox-x to report all allocations and deallocations in memory, including some information about the source? Is it also possible to determine whether these events are for stack or heap space?
wrote:Is there a method for dosbox-x to report all allocations and deallocations in memory, including some information about the source? Is it also possible to determine whether these events are for stack or heap space?
Allocations and deallocations by whom?
DOSBox-X itself?
Or the DOS application within?
Would the dosbox-x allocation logs give any insight into the dos application within?
wrote:Would the dosbox-x allocation logs give any insight into the dos application within?
There's logging for INT 21h memory allocation and resizing, that's about it.
The debugger interface offers a "DOS MCBS" command to view memory allocations as well. I recently added commands to view EMS and XMS allocations as well.
The best way to know if DOSBox-X is leaking memory is to run it under Valgrind in Linux. I do this very so often. Memory leaks I can fix are noted in the Git commit log as "valgrind hunting"
Using the djgpp protected mode as an example, I guess I could find documentation on how it forms any table and allocations.
Edit: found this for 1mb and lower, https://www.phatcode.net/res/262/files/dpmi09.html#9.1
And, here is about allocating in linear mode: https://www.phatcode.net/res/262/files/dpmi09.html#13.2
In dos_tables:
if (DOS_PRIVATE_SEGMENT >= 0xA000u) MEM_unmap_physmem((unsigned int)DOS_PRIVATE_SEGMENT<<4u,((unsigned int)DOS_PRIVATE_SEGMENT_END<<4u)-1u);
And in xms.cpp:
MEM_unmap_physmem((unsigned long)first_umb_seg<<4ul,(((unsigned long)first_umb_seg+(unsigned long)first_umb_size)<<4ul)-1ul);
I noted another similar case where the typing is used differently in the same function.
Interesting work on the asserting of bit operations, too. 😀
I had a gcc compiler warning in ne2000.cpp that you may not have, but this seemed to resolve it:
@@ -1557,7 +1557,12 @@ public:
char errbuf[PCAP_ERRBUF_SIZE];
unsigned int userdev;
#ifdef WIN32
- if (pcap_findalldevs_ex(PCAP_SRC_IF_STRING, NULL, &alldevs, errbuf) == -1)
+ char* ifString = new char[sizeof PCAP_SRC_IF_STRING + 1];
+ strcpy ( ifString, PCAP_SRC_IF_STRING );
+
+ if (pcap_findalldevs_ex(ifString, NULL, &alldevs, errbuf) == -1)
+
+ delete [] ifString;
#else
if (pcap_findalldevs(&alldevs, errbuf) == -1)
#endif
Code snippet from here:
http://www.cplusplus.com/forum/windows/162626/
The few times I checked, the binary was the same size before and after the compiler warning fixes. So, it should be possible to first compare the object files for dbopl and voodoo* and verify that there are no changes to the machine code. If they are different, then the further testing would be required.