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.
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 😉
TheGreatCodeholio: In "Long File Name support" thread of this forum (Long File Name (LFN) support), 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!
TheGreatCodeholio: In "Long File Name support" thread of this forum (Long File Name (LFN) support), 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.
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?
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.
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.
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.
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!
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.
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:
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.
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:
(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:
1DOSBox LOG: DOSBox version DOSBox-X 2DOSBox LOG: Copyright 2002-2015 DOSBox Team, published under GNU GPL. 3DOSBox LOG: --- 4DOSBox LOG: DOSBox_CheckOS results: id=2 major=6 minor=1 5DOSBox LOG: GUI: Press Ctrl-F10 to capture/release mouse. 6 Save your configuration and restart DOSBox if your settings do not take effect. 7DOSBox LOG: CONFIG:Loading primary settings from config file dosbox.conf 8DOSBox LOG: "direct3d" is not a valid value for variable: output. 9It might now be reset to the default value: direct3d 10DOSBox LOG: SDL:Unsupported output device direct3d, switching back to surface 11DOSBox LOG: Memory sizes above 31 MB are NOT recommended. 12DOSBox LOG: Stick with the default values unless you are absolutely certain. 13DOSBox LOG: APM BIOS allow: real=1 pm16=1 pm32=1 14DOSBox LOG: Allocated APM BIOS pm entry point at f000:e56e 15DOSBox LOG: MIDI:Opened device:win32 16DOSBox LOG: Registered ISA PnP read port at 0x20b 17DOSBox LOG: ISA Plug & Play BIOS enabled 18DOSBox LOG: Registering APM BIOS as ISA Plug & Play BIOS device node 19DOSBox LOG: VGA BIOS occupies segment 0xc000-0xc2ff 20DOSBox LOG: DOS: MAXENV=65535 ENV_KEEPFREE=1024 21DOSBox LOG: Dynamic DOS kernel mode, structures will be allocated from pool 0x0070-0x9bff 22DOSBox LOG: DOS kernel alloc: 23DOSBox LOG: IHSEG: seg 0x0070 24DOSBox LOG: infoblock: seg 0x0071 25DOSBox LOG: condrv: seg 0x0091 26DOSBox LOG: constring: seg 0x0099 27DOSBox LOG: SDA: seg 0x00a3:0x0000 28DOSBox LOG: CDS: seg 0x00f9 29DOSBox LOG: first shell: seg 0x0109-0x0148 30DOSBox LOG: [private segment @ this point 0x0070-0x9c00 mem=0x3f0000] 31DOSBox LOG: mem start: seg 0x0400 32DOSBox LOG: DOS private segment set to 0xc300-0xcaff 33DOSBox LOG: EMS: OS handle allocated 0x00110000-0x00127fff 34DOSBox LOG: Enabling VCPI emulation 35DOSBox LOG: EMS:EMM OS handle is associated with memory on an odd megabyte. Enabling A20 gate to avoid corrupting DOS state 36DOSBox LOG: 0 ERROR BIOS:Keyboard layout file auto not found 37DOSBox LOG: 0 ERROR BIOS:Keyboard layout file auto not found 38DOSBox LOG: One joystick reported, initializing with 4axis 39DOSBox LOG: Using joystick Controller (XBOX One For Windows) with 5 axes, 10 buttons and 1 hat(s) 40DOSBox LOG: SHELL: psp_seg 0x0109 41DOSBox LOG: SHELL: env_seg 0x011c 42DOSBox LOG: DOS_AllocateMemory(blocks=0x0045) = 0x0419-0x045d 43DOSBox LOG: DOS_AllocateMemory(blocks=0x9ba0) = 0x045f-0x9ffe 44DOSBox LOG: DOS_ResizeMemory(seg=0x045f) blocks=0x0040 45DOSBox LOG: IDE: index -1 slave=0 46DOSBox LOG: DOS_AllocateMemory(blocks=0x0045) = 0x0419-0x045d 47DOSBox LOG: DOS_AllocateMemory(blocks=0x9ba0) = 0x045f-0x9ffe 48DOSBox LOG: DOS_ResizeMemory(seg=0x045f) blocks=0x0040 49DOSBox LOG: IDE: index 0 slave=0 50DOSBox LOG: Mapping BIOS DISK C/H/S 520/64/63 as IDE 2080/16/63 51DOSBox LOG: DOS_AllocateMemory(blocks=0x0045) = 0x0419-0x045d 52DOSBox LOG: DOS_AllocateMemory(blocks=0x9ba0) = 0x045f-0x9ffe 53DOSBox LOG: DOS_ResizeMemory(seg=0x045f) blocks=0x0040 54DOSBox LOG: Booting guest OS stack_seg=0x7000 load_seg=0x07c0 55DOSBox LOG: Removing UMB block 0xcb00-0xdfff 56DOSBox LOG: Unmapping DOS private segment 0xc300-0xcaff 57DOSBox LOG: Alright: DOS kernel shutdown, booting a guest OS 58DOSBox LOG: CS:IP=0000:7c00 SS:SP=7000:0100 AX=0000 BX=7c00 CX=0001 DX=0080 59DOSBox LOG: 35247 ERROR BIOS:INT13: Function 15 called on drive 0 (dos drive 0) 60DOSBox LOG: 36201 ERROR BIOS:INT15:Unknown call 4101
…Show last 107 lines
61DOSBox LOG: 63168551 ERROR BIOS:INT15:Unknown call 2403 62DOSBox LOG: 63334591 ERROR BIOS:INT15:Unknown call D800 63DOSBox LOG: 63334605 ERROR BIOS:INT15:Unknown call D800 64DOSBox LOG: 63334619 ERROR BIOS:INT15:Unknown call D800 65DOSBox LOG: 63334633 ERROR BIOS:INT15:Unknown call D800 66DOSBox LOG: 63334647 ERROR BIOS:INT15:Unknown call D800 67DOSBox LOG: 63334661 ERROR BIOS:INT15:Unknown call D800 68DOSBox LOG: 63334675 ERROR BIOS:INT15:Unknown call D800 69DOSBox LOG: 63334689 ERROR BIOS:INT15:Unknown call D800 70DOSBox LOG: 63334703 ERROR BIOS:INT15:Unknown call D800 71DOSBox LOG: 63334717 ERROR BIOS:INT15:Unknown call D800 72DOSBox LOG: 63334731 ERROR BIOS:INT15:Unknown call D800 73DOSBox LOG: 63334745 ERROR BIOS:INT15:Unknown call D800 74DOSBox LOG: 63334759 ERROR BIOS:INT15:Unknown call D800 75DOSBox LOG: 63334773 ERROR BIOS:INT15:Unknown call D800 76DOSBox LOG: 63334787 ERROR BIOS:INT15:Unknown call D800 77DOSBox LOG: 63334801 ERROR BIOS:INT15:Unknown call D800 78DOSBox LOG: 63392521 ERROR CPU:Illegal Unhandled Interrupt Called 68 79DOSBox LOG: 102763504 ERROR CPU:Illegal Unhandled Interrupt Called 68 80DOSBox LOG: INT13: Check Extensions Present for drive: 0x80 81DOSBox LOG: APM BIOS: Connected to 32-bit protected mode interface 82DOSBox LOG: APM BIOS: OS disconnected 83DOSBox LOG: 118258799 ERROR CPU:Illegal Unhandled Interrupt Called 68 84DOSBox LOG: 127885811 ERROR CPU:Write 0 to rom at e00a0 85DOSBox LOG: 127885811 ERROR CPU:Write ffff to rom at e00a2 86DOSBox LOG: 127885811 ERROR CPU:Write 0 to rom at e00a2 87DOSBox LOG: 127885811 ERROR CPU:Write 0 to rom at e00a0 88DOSBox LOG: 127885950 ERROR CPU:Write 0 to rom at e10a0 89DOSBox LOG: 127885950 ERROR CPU:Write ffff to rom at e10a2 90DOSBox LOG: 127885950 ERROR CPU:Write 0 to rom at e10a2 91DOSBox LOG: 127885950 ERROR CPU:Write 0 to rom at e10a0 92DOSBox LOG: 127886089 ERROR CPU:Write 0 to rom at e20a0 93DOSBox LOG: 127886089 ERROR CPU:Write ffff to rom at e20a2 94DOSBox LOG: 127886089 ERROR CPU:Write 0 to rom at e20a2 95DOSBox LOG: 127886089 ERROR CPU:Write 0 to rom at e20a0 96DOSBox LOG: 127886228 ERROR CPU:Write 0 to rom at e30a0 97DOSBox LOG: 127886228 ERROR CPU:Write ffff to rom at e30a2 98DOSBox LOG: 127886228 ERROR CPU:Write 0 to rom at e30a2 99DOSBox LOG: 127886228 ERROR CPU:Write 0 to rom at e30a0 100DOSBox LOG: 127886367 ERROR CPU:Write 0 to rom at e40a0 101DOSBox LOG: 127886367 ERROR CPU:Write ffff to rom at e40a2 102DOSBox LOG: 127886367 ERROR CPU:Write 0 to rom at e40a2 103DOSBox LOG: 127886367 ERROR CPU:Write 0 to rom at e40a0 104DOSBox LOG: 127886506 ERROR CPU:Write 0 to rom at e50a0 105DOSBox LOG: 127886506 ERROR CPU:Write ffff to rom at e50a2 106DOSBox LOG: 127886506 ERROR CPU:Write 0 to rom at e50a2 107DOSBox LOG: 127886506 ERROR CPU:Write 0 to rom at e50a0 108DOSBox LOG: 127886645 ERROR CPU:Write 0 to rom at e60a0 109DOSBox LOG: 127886645 ERROR CPU:Write ffff to rom at e60a2 110DOSBox LOG: 127886645 ERROR CPU:Write 0 to rom at e60a2 111DOSBox LOG: 127886645 ERROR CPU:Write 0 to rom at e60a0 112DOSBox LOG: 127886784 ERROR CPU:Write 0 to rom at e70a0 113DOSBox LOG: 127886784 ERROR CPU:Write ffff to rom at e70a2 114DOSBox LOG: 127886784 ERROR CPU:Write 0 to rom at e70a2 115DOSBox LOG: 127886784 ERROR CPU:Write 0 to rom at e70a0 116DOSBox LOG: 127886923 ERROR CPU:Write 0 to rom at e80a0 117DOSBox LOG: 127886923 ERROR CPU:Write ffff to rom at e80a2 118DOSBox LOG: 127886923 ERROR CPU:Write 0 to rom at e80a2 119DOSBox LOG: 127886923 ERROR CPU:Write 0 to rom at e80a0 120DOSBox LOG: 127887062 ERROR CPU:Write 0 to rom at e90a0 121DOSBox LOG: 127887062 ERROR CPU:Write ffff to rom at e90a2 122DOSBox LOG: 127887062 ERROR CPU:Write 0 to rom at e90a2 123DOSBox LOG: 127887062 ERROR CPU:Write 0 to rom at e90a0 124DOSBox LOG: 127887201 ERROR CPU:Write 0 to rom at ea0a0 125DOSBox LOG: 127887201 ERROR CPU:Write ffff to rom at ea0a2 126DOSBox LOG: 127887201 ERROR CPU:Write 0 to rom at ea0a2 127DOSBox LOG: 127887201 ERROR CPU:Write 0 to rom at ea0a0 128DOSBox LOG: 127887398 ERROR CPU:Write 0 to rom at eb0a0 129DOSBox LOG: 127887398 ERROR CPU:Write ffff to rom at eb0a2 130DOSBox LOG: 127887398 ERROR CPU:Write 0 to rom at eb0a2 131DOSBox LOG: 127887398 ERROR CPU:Write 0 to rom at eb0a0 132DOSBox LOG: 127887479 ERROR CPU:Write 0 to rom at ec0a0 133DOSBox LOG: 127887479 ERROR CPU:Write ffff to rom at ec0a2 134DOSBox LOG: 127887479 ERROR CPU:Write 0 to rom at ec0a2 135DOSBox LOG: 127887479 ERROR CPU:Write 0 to rom at ec0a0 136DOSBox LOG: 127887618 ERROR CPU:Write 0 to rom at ed0a0 137DOSBox LOG: 127887618 ERROR CPU:Write ffff to rom at ed0a2 138DOSBox LOG: 127887618 ERROR CPU:Write 0 to rom at ed0a2 139DOSBox LOG: 127887618 ERROR CPU:Write 0 to rom at ed0a0 140DOSBox LOG: 127887757 ERROR CPU:Write 0 to rom at ee0a0 141DOSBox LOG: 127887757 ERROR CPU:Write ffff to rom at ee0a2 142DOSBox LOG: 127887757 ERROR CPU:Write 0 to rom at ee0a2 143DOSBox LOG: 127887757 ERROR CPU:Write 0 to rom at ee0a0 144DOSBox LOG: 127887896 ERROR CPU:Write 0 to rom at ef0a0 145DOSBox LOG: 127887896 ERROR CPU:Write ffff to rom at ef0a2 146DOSBox LOG: 127887896 ERROR CPU:Write 0 to rom at ef0a2 147DOSBox LOG: 127887896 ERROR CPU:Write 0 to rom at ef0a0 148DOSBox LOG: APM BIOS: Connected to 32-bit protected mode interface 149DOSBox LOG: Unknown APM BIOS call AX=5312 150DOSBox LOG: enable APM for device 1 151DOSBox LOG: engage APM for device 1 152DOSBox LOG: enable APM for device 1 153DOSBox LOG: 135348248 ERROR INT10:Unhandled VESA Function 15 154DOSBox LOG: Adlib polling hack triggered. Forcing timers to reset. Hope this helps your DOS game to detect Adlib. 155DOSBox LOG: Plug & Play OS reports itself active 156DOSBox LOG: 147153357 ERROR CPU:Illegal Unhandled Interrupt Called 20 157DOSBox LOG: 147153638 ERROR CPU:Illegal Unhandled Interrupt Called 20 158DOSBox LOG: 150289413 ERROR BIOS:INT15:Unknown call F963 159DOSBox LOG: INT 15h mouse initialized to 3-byte protocol 160DOSBox LOG: INT 15h reporting mouse device ID 0x00 161DOSBox LOG: Warning: PAGING_NewPageFault() more than one level, now using level 2 162DOSBox LOG: Warning: PAGING_NewPageFault() more than one level, now using level 2 163DOSBox LOG: Warning: PAGING_NewPageFault() more than one level, now using level 2 164DOSBox LOG: Warning: PAGING_NewPageFault() more than one level, now using level 3 165DOSBox LOG: E_Exit: CPU_SetSegGeneral: Stack segment with invalid privileges 166 167E_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.
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.
