VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 1020 of 2031, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Darkstar wrote:

You know, it would really help if you could (for example) provide the errno in question...

I guess it's just a matter of not #defining the right macros everywhere so that part of the runtime is 32bit while another part is 64bit and you get residual stack parameters interpreted as error codes or something. Similar to what happens when you mix the debug and the non-debug versions of the runtime.

I have never seen these errors you're having myself, but then again I haven't switched to 2015 completely yet (only on a VM for testing). fopen() should work on files >2gb without any problems... it would be a major bug otherwise that I'm pretty sure *someone* would have caught during the three RC cycles they made...

I didn't bother to read back the errno, because that was when I traced it down to stat() failing to return information on the file. I already have some #defines set up now to mask the difference between stat and _stati64 and I am testing them now.

Technically it's not really a bug. Linux has been doing the same thing forever: fopen/open calls fail on files 2GB or larger unless you call fopen64/open64 or call open() with O_LARGEFILE to indicate that you support 2GB or larger. On linux you can map open -> open64 automatically by defining _FILE_OFFSET_BITS=64 (which also changes the stat structure and other calls). If you look at the stat structure in Visual Studio, the off_t field is 32 bits wide. What I think happened is someone at Microsoft decided the Linux way of handling legacy code (that used int or long for file offsets) was a good idea, and carried it into the C runtime sometime between 2013 and 2015, requiring the use of the 64-bit variants to work around it. Then as long as you use the 64-bit version of struct stat, you're good.

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

Reply 1021 of 2031, by Darkstar

User metadata
Rank Newbie
Rank
Newbie

I think it's just that some default somewhere has been switched from 32 to 64 bit and then everything breaks because it's quite a mess to know which function you need to call when (some ignore all 32/64 bit definitions, some use them, and some even use them the other way round than what would be logical). If you use the corresponding set of functions (e.g. all explicit 64-bit functions which don't care about things like the _USE_32BIT_TIME_T macro or similar) you should be good.

OTOH you can always use CreateFile() etc. on Windows to use "native" file access routines (which still isn't exactly "native" but rather the WIN32 runtime, but from a user application point of view it's "native enough" 😉

Also I don't think thy were "inspired" by Linux since _stat64 etc. exist since at least 2002 and back then Microsoft didn't even touch Linux with a 10 feet pole 😉

Reply 1022 of 2031, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

Fair enough. Fixed. Git clone the latest code and you should be able to IMGMOUNT large (2GB or larger) hard disk images.

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

Reply 1023 of 2031, by Wengier

User metadata
Rank Member
Rank
Member

TheGreatCodeholio: In "Long File Name support" thread of this forum (Long File Name (LFN) support (SDL1)), we are talking about the possibility of merging the Long File Name (LFN) patch into the DOSBox-X branch, especially the Win32 port. Are you interested in doing so? Thanks!

Reply 1024 of 2031, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Wengier wrote:

TheGreatCodeholio: In "Long File Name support" thread of this forum (Long File Name (LFN) support (SDL1)), we are talking about the possibility of merging the Long File Name (LFN) patch into the DOSBox-X branch, especially the Win32 port. Are you interested in doing so? Thanks!

Of course! I've already been around a few times with someone on Github to apply another version of the patch, but it never made it because the patch broke everything related to path resolution for any drive other than Z: on Linux. Before submitting it to me please check the code on Linux and Windows.

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

Reply 1025 of 2031, by Wengier

User metadata
Rank Member
Rank
Member

TheGreatCodeholio: Thanks for your reply. As mentioned in the other thread, I probably can't help with the Linux part since I am not very familiar with Linux systems. However, is the patch working fine on Windows systems now?

Reply 1026 of 2031, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Wengier wrote:

TheGreatCodeholio: Thanks for your reply. As mentioned in the other thread, I probably can't help with the Linux part since I am not very familiar with Linux systems. However, is the patch working fine on Windows systems now?

We never did get it to work on Linux. It did do an impressive job with LFN emulation on Linux but that doesn't help when you can't open any files. I would suggest that when you work on it you put it on a github repository I can test from before accepting the changes so I can verify. You may want to also set up some Linux distro in a VM and do some test compiles there.

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

Reply 1027 of 2031, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

I have 32-bit and 64-bit Linux standing by to test when you're ready with the LFN patch.

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

Reply 1028 of 2031, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Regarding the PDF-based GUS panning patch using a fixed array of offset values: official source computes the same offset values using an equation that is mentioned on the page preceding the table of values in the PDF.

The significant difference from official source is multiplying the offsets by twice as much (2048 instead of 1024), thus greater attenuation and more perceived stereo separation. You might not believe this until you check the math and audible result for yourself, but simply changing (1 << RAMP_FRACT) to (1 << (RAMP_FRACT+1)) in the pantable equation in official source is effectively the same as the fixed array approach DOSBox-X is using.

Reply 1029 of 2031, by Wengier

User metadata
Rank Member
Rank
Member
TheGreatCodeholio wrote:

I have 32-bit and 64-bit Linux standing by to test when you're ready with the LFN patch.

I am just wondering if you have ever tested the LFN patch on Win32 port of your DOSBox-X. Since my own DOSBox LFN build does open files properly on Win32 systems, I currently still have not experienced that particular problem you mentioned as Linux is currently not available for me to test. I am trying to set up a Linux VM at the momemt but it may take some time.

Last edited by Wengier on 2015-08-29, 18:48. Edited 1 time in total.

Reply 1030 of 2031, by Wengier

User metadata
Rank Member
Rank
Member

I have by now tested my own LFN build on Fedora 20, and it seems to open files properly. For example, I used "type", "more", and "edit" to view, edit and save files, but all work fine. So I still have not experienced the problem you mentioned by myself. In such case the problem is most likely specific to your DOSBox-X branch, probably only its Linux port (which I have not tested). Can you please confirm the LFN patch works properly on the Win32 port of your DOSBox-X? Thanks!

Reply 1031 of 2031, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
Wengier wrote:

I have by now tested my own LFN build on Fedora 20, and it seems to open files properly. For example, I used "type", "more", and "edit" to view, edit and save files, but all work fine. So I still have not experienced the problem you mentioned by myself. In such case the problem is most likely specific to your DOSBox-X branch, probably only its Linux port (which I have not tested). Can you please confirm the LFN patch works properly on the Win32 port of your DOSBox-X? Thanks!

Certainly. Where can I get your branch with LFN patches?

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

Reply 1032 of 2031, by Wengier

User metadata
Rank Member
Rank
Member
TheGreatCodeholio wrote:
Wengier wrote:

I have by now tested my own LFN build on Fedora 20, and it seems to open files properly. For example, I used "type", "more", and "edit" to view, edit and save files, but all work fine. So I still have not experienced the problem you mentioned by myself. In such case the problem is most likely specific to your DOSBox-X branch, probably only its Linux port (which I have not tested). Can you please confirm the LFN patch works properly on the Win32 port of your DOSBox-X? Thanks!

Certainly. Where can I get your branch with LFN patches?

Both sources and Win32 binary are available from the LFN patch thread:

Long File Name (LFN) support (SDL1)

If you want the most recent source diff, please go to Page 3 of that thread:

Long File Name (LFN) support (SDL1)

Reply 1033 of 2031, by avx

User metadata
Rank Newbie
Rank
Newbie

Does anyone have original Star Control 2 floppies and computer with real GUS? Can you record the music from the intro, the click sound of the menu and bit of gameplay and up to youtube?

I know how the ur-quan masters open source version sounds but I can't get dos version sound same in dosbox and I wonder if it's a bit different in implementation.

Reply 1034 of 2031, by marzsyndrome

User metadata
Rank Newbie
Rank
Newbie

Hello again. I unfortunately seem to be flummoxed and frustratred when it comes to finding a combination of a working build and a configuration setup that will allow me to actually install Windows 95.

I'm trying to install Win95 OSR2, seeing as that's my preferred version. I adjusted my config to select a few suggestions from the DOSBox95 site, namely as follows:

output=opengl
vmemsize=8
memsize=512 *or* 63
cputype=pentium
cycles=max 105%
voodoo=opengl

(BTW, why does DOSBox-X pick Direct3D as the default output when it doesn't even support it? Is D3D support in the pipeline at all?)

Alas, v0.801 appears to be more broken to me than previous builds. For starters, I can't even use OpenGL for output without the emu showing its window for a nano-second and then crashing on me straight away. I'm none the wiser as to why it's doing this when older builds can do OpenGL without keeling over. Another severe problem with this build is what happens when I try to access the second part of the Win95 installation process (after the reset)..... it bombs out instantly and I get this worrying error log:

DOSBox LOG: DOSBox version DOSBox-X
DOSBox LOG: Copyright 2002-2015 DOSBox Team, published under GNU GPL.
DOSBox LOG: ---
DOSBox LOG: DOSBox_CheckOS results: id=2 major=6 minor=1
DOSBox LOG: GUI: Press Ctrl-F10 to capture/release mouse.
Save your configuration and restart DOSBox if your settings do not take effect.
DOSBox LOG: CONFIG:Loading primary settings from config file dosbox.conf
DOSBox LOG: "direct3d" is not a valid value for variable: output.
It might now be reset to the default value: direct3d
DOSBox LOG: SDL:Unsupported output device direct3d, switching back to surface
DOSBox LOG: Memory sizes above 31 MB are NOT recommended.
DOSBox LOG: Stick with the default values unless you are absolutely certain.
DOSBox LOG: APM BIOS allow: real=1 pm16=1 pm32=1
DOSBox LOG: Allocated APM BIOS pm entry point at f000:e56e
DOSBox LOG: MIDI:Opened device:win32
DOSBox LOG: Registered ISA PnP read port at 0x20b
DOSBox LOG: ISA Plug & Play BIOS enabled
DOSBox LOG: Registering APM BIOS as ISA Plug & Play BIOS device node
DOSBox LOG: VGA BIOS occupies segment 0xc000-0xc2ff
DOSBox LOG: DOS: MAXENV=65535 ENV_KEEPFREE=1024
DOSBox LOG: Dynamic DOS kernel mode, structures will be allocated from pool 0x0070-0x9bff
DOSBox LOG: DOS kernel alloc:
DOSBox LOG: IHSEG: seg 0x0070
DOSBox LOG: infoblock: seg 0x0071
DOSBox LOG: condrv: seg 0x0091
DOSBox LOG: constring: seg 0x0099
DOSBox LOG: SDA: seg 0x00a3:0x0000
DOSBox LOG: CDS: seg 0x00f9
DOSBox LOG: first shell: seg 0x0109-0x0148
DOSBox LOG: [private segment @ this point 0x0070-0x9c00 mem=0x3f0000]
DOSBox LOG: mem start: seg 0x0400
DOSBox LOG: DOS private segment set to 0xc300-0xcaff
DOSBox LOG: EMS: OS handle allocated 0x00110000-0x00127fff
DOSBox LOG: Enabling VCPI emulation
DOSBox LOG: EMS:EMM OS handle is associated with memory on an odd megabyte. Enabling A20 gate to avoid corrupting DOS state
DOSBox LOG: 0 ERROR BIOS:Keyboard layout file auto not found
DOSBox LOG: 0 ERROR BIOS:Keyboard layout file auto not found
DOSBox LOG: One joystick reported, initializing with 4axis
DOSBox LOG: Using joystick Controller (XBOX One For Windows) with 5 axes, 10 buttons and 1 hat(s)
DOSBox LOG: SHELL: psp_seg 0x0109
DOSBox LOG: SHELL: env_seg 0x011c
DOSBox LOG: DOS_AllocateMemory(blocks=0x0045) = 0x0419-0x045d
DOSBox LOG: DOS_AllocateMemory(blocks=0x9ba0) = 0x045f-0x9ffe
DOSBox LOG: DOS_ResizeMemory(seg=0x045f) blocks=0x0040
DOSBox LOG: IDE: index -1 slave=0
DOSBox LOG: DOS_AllocateMemory(blocks=0x0045) = 0x0419-0x045d
DOSBox LOG: DOS_AllocateMemory(blocks=0x9ba0) = 0x045f-0x9ffe
DOSBox LOG: DOS_ResizeMemory(seg=0x045f) blocks=0x0040
DOSBox LOG: IDE: index 0 slave=0
DOSBox LOG: Mapping BIOS DISK C/H/S 520/64/63 as IDE 2080/16/63
DOSBox LOG: DOS_AllocateMemory(blocks=0x0045) = 0x0419-0x045d
DOSBox LOG: DOS_AllocateMemory(blocks=0x9ba0) = 0x045f-0x9ffe
DOSBox LOG: DOS_ResizeMemory(seg=0x045f) blocks=0x0040
DOSBox LOG: Booting guest OS stack_seg=0x7000 load_seg=0x07c0
DOSBox LOG: Removing UMB block 0xcb00-0xdfff
DOSBox LOG: Unmapping DOS private segment 0xc300-0xcaff
DOSBox LOG: Alright: DOS kernel shutdown, booting a guest OS
DOSBox LOG: CS:IP=0000:7c00 SS:SP=7000:0100 AX=0000 BX=7c00 CX=0001 DX=0080
DOSBox LOG: 35247 ERROR BIOS:INT13: Function 15 called on drive 0 (dos drive 0)
DOSBox LOG: 36201 ERROR BIOS:INT15:Unknown call 4101
Show last 107 lines
DOSBox LOG:   63168551 ERROR BIOS:INT15:Unknown call 2403
DOSBox LOG: 63334591 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334605 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334619 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334633 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334647 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334661 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334675 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334689 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334703 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334717 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334731 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334745 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334759 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334773 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334787 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63334801 ERROR BIOS:INT15:Unknown call D800
DOSBox LOG: 63392521 ERROR CPU:Illegal Unhandled Interrupt Called 68
DOSBox LOG: 102763504 ERROR CPU:Illegal Unhandled Interrupt Called 68
DOSBox LOG: INT13: Check Extensions Present for drive: 0x80
DOSBox LOG: APM BIOS: Connected to 32-bit protected mode interface
DOSBox LOG: APM BIOS: OS disconnected
DOSBox LOG: 118258799 ERROR CPU:Illegal Unhandled Interrupt Called 68
DOSBox LOG: 127885811 ERROR CPU:Write 0 to rom at e00a0
DOSBox LOG: 127885811 ERROR CPU:Write ffff to rom at e00a2
DOSBox LOG: 127885811 ERROR CPU:Write 0 to rom at e00a2
DOSBox LOG: 127885811 ERROR CPU:Write 0 to rom at e00a0
DOSBox LOG: 127885950 ERROR CPU:Write 0 to rom at e10a0
DOSBox LOG: 127885950 ERROR CPU:Write ffff to rom at e10a2
DOSBox LOG: 127885950 ERROR CPU:Write 0 to rom at e10a2
DOSBox LOG: 127885950 ERROR CPU:Write 0 to rom at e10a0
DOSBox LOG: 127886089 ERROR CPU:Write 0 to rom at e20a0
DOSBox LOG: 127886089 ERROR CPU:Write ffff to rom at e20a2
DOSBox LOG: 127886089 ERROR CPU:Write 0 to rom at e20a2
DOSBox LOG: 127886089 ERROR CPU:Write 0 to rom at e20a0
DOSBox LOG: 127886228 ERROR CPU:Write 0 to rom at e30a0
DOSBox LOG: 127886228 ERROR CPU:Write ffff to rom at e30a2
DOSBox LOG: 127886228 ERROR CPU:Write 0 to rom at e30a2
DOSBox LOG: 127886228 ERROR CPU:Write 0 to rom at e30a0
DOSBox LOG: 127886367 ERROR CPU:Write 0 to rom at e40a0
DOSBox LOG: 127886367 ERROR CPU:Write ffff to rom at e40a2
DOSBox LOG: 127886367 ERROR CPU:Write 0 to rom at e40a2
DOSBox LOG: 127886367 ERROR CPU:Write 0 to rom at e40a0
DOSBox LOG: 127886506 ERROR CPU:Write 0 to rom at e50a0
DOSBox LOG: 127886506 ERROR CPU:Write ffff to rom at e50a2
DOSBox LOG: 127886506 ERROR CPU:Write 0 to rom at e50a2
DOSBox LOG: 127886506 ERROR CPU:Write 0 to rom at e50a0
DOSBox LOG: 127886645 ERROR CPU:Write 0 to rom at e60a0
DOSBox LOG: 127886645 ERROR CPU:Write ffff to rom at e60a2
DOSBox LOG: 127886645 ERROR CPU:Write 0 to rom at e60a2
DOSBox LOG: 127886645 ERROR CPU:Write 0 to rom at e60a0
DOSBox LOG: 127886784 ERROR CPU:Write 0 to rom at e70a0
DOSBox LOG: 127886784 ERROR CPU:Write ffff to rom at e70a2
DOSBox LOG: 127886784 ERROR CPU:Write 0 to rom at e70a2
DOSBox LOG: 127886784 ERROR CPU:Write 0 to rom at e70a0
DOSBox LOG: 127886923 ERROR CPU:Write 0 to rom at e80a0
DOSBox LOG: 127886923 ERROR CPU:Write ffff to rom at e80a2
DOSBox LOG: 127886923 ERROR CPU:Write 0 to rom at e80a2
DOSBox LOG: 127886923 ERROR CPU:Write 0 to rom at e80a0
DOSBox LOG: 127887062 ERROR CPU:Write 0 to rom at e90a0
DOSBox LOG: 127887062 ERROR CPU:Write ffff to rom at e90a2
DOSBox LOG: 127887062 ERROR CPU:Write 0 to rom at e90a2
DOSBox LOG: 127887062 ERROR CPU:Write 0 to rom at e90a0
DOSBox LOG: 127887201 ERROR CPU:Write 0 to rom at ea0a0
DOSBox LOG: 127887201 ERROR CPU:Write ffff to rom at ea0a2
DOSBox LOG: 127887201 ERROR CPU:Write 0 to rom at ea0a2
DOSBox LOG: 127887201 ERROR CPU:Write 0 to rom at ea0a0
DOSBox LOG: 127887398 ERROR CPU:Write 0 to rom at eb0a0
DOSBox LOG: 127887398 ERROR CPU:Write ffff to rom at eb0a2
DOSBox LOG: 127887398 ERROR CPU:Write 0 to rom at eb0a2
DOSBox LOG: 127887398 ERROR CPU:Write 0 to rom at eb0a0
DOSBox LOG: 127887479 ERROR CPU:Write 0 to rom at ec0a0
DOSBox LOG: 127887479 ERROR CPU:Write ffff to rom at ec0a2
DOSBox LOG: 127887479 ERROR CPU:Write 0 to rom at ec0a2
DOSBox LOG: 127887479 ERROR CPU:Write 0 to rom at ec0a0
DOSBox LOG: 127887618 ERROR CPU:Write 0 to rom at ed0a0
DOSBox LOG: 127887618 ERROR CPU:Write ffff to rom at ed0a2
DOSBox LOG: 127887618 ERROR CPU:Write 0 to rom at ed0a2
DOSBox LOG: 127887618 ERROR CPU:Write 0 to rom at ed0a0
DOSBox LOG: 127887757 ERROR CPU:Write 0 to rom at ee0a0
DOSBox LOG: 127887757 ERROR CPU:Write ffff to rom at ee0a2
DOSBox LOG: 127887757 ERROR CPU:Write 0 to rom at ee0a2
DOSBox LOG: 127887757 ERROR CPU:Write 0 to rom at ee0a0
DOSBox LOG: 127887896 ERROR CPU:Write 0 to rom at ef0a0
DOSBox LOG: 127887896 ERROR CPU:Write ffff to rom at ef0a2
DOSBox LOG: 127887896 ERROR CPU:Write 0 to rom at ef0a2
DOSBox LOG: 127887896 ERROR CPU:Write 0 to rom at ef0a0
DOSBox LOG: APM BIOS: Connected to 32-bit protected mode interface
DOSBox LOG: Unknown APM BIOS call AX=5312
DOSBox LOG: enable APM for device 1
DOSBox LOG: engage APM for device 1
DOSBox LOG: enable APM for device 1
DOSBox LOG: 135348248 ERROR INT10:Unhandled VESA Function 15
DOSBox LOG: Adlib polling hack triggered. Forcing timers to reset. Hope this helps your DOS game to detect Adlib.
DOSBox LOG: Plug & Play OS reports itself active
DOSBox LOG: 147153357 ERROR CPU:Illegal Unhandled Interrupt Called 20
DOSBox LOG: 147153638 ERROR CPU:Illegal Unhandled Interrupt Called 20
DOSBox LOG: 150289413 ERROR BIOS:INT15:Unknown call F963
DOSBox LOG: INT 15h mouse initialized to 3-byte protocol
DOSBox LOG: INT 15h reporting mouse device ID 0x00
DOSBox LOG: Warning: PAGING_NewPageFault() more than one level, now using level 2
DOSBox LOG: Warning: PAGING_NewPageFault() more than one level, now using level 2
DOSBox LOG: Warning: PAGING_NewPageFault() more than one level, now using level 2
DOSBox LOG: Warning: PAGING_NewPageFault() more than one level, now using level 3
DOSBox LOG: E_Exit: CPU_SetSegGeneral: Stack segment with invalid privileges

E_Exit: CPU_SetSegGeneral: Stack segment with invalid privileges

Doesn't matter if I mount both floppy and hard disk, or just hard disk, or if I switch APM on and off. It just doesn't want to know. Older builds can get further than this, but then tend to BSOD during the Plug and Play process, and then freeze the display after I get out of the blue screen.

Is it my fault for trying to borrow some suggestions from DOSBox95? Or do the current DOSBox-X Win32 builds just plain hate my computer? This is why I think a dedicated tutorial guide for DOSBox-X would really come in handy because for one thing, I'd like to know what config/setup TheGreatCodeholio himself is using to ensure a friendly DIY Win95 environment.

Haven't tried to install Win98SE instead yet, but I doubt that's going to play any nicer.

Reply 1035 of 2031, by Sammy

User metadata
Rank Oldbie
Rank
Oldbie

i also had problems to install win95c the last time i tryed..

I had to use different Dosbox versions on some points in the setup process..

One version for the first part, another for the second part... and a third for using.

i would try a completly new install of win95c this weekend with the newest dosbox-x version.

Reply 1038 of 2031, by Sammy

User metadata
Rank Oldbie
Rank
Oldbie

i need a dosbox with defaults to see what i can change.

sure, i can use a dosbox.conf from a daum build. But are there all sections inside that dosbox-x supports??

Btw... the newest version crashes to desktop when the second install part from win95 starts.

When i install win95 with the daum version, and then copy the image to the Dosbox-x version, it will also crash to desktop with no error as soon as win95 starts to boot.