1. Forum
  2. Usenet
  3. COMP.OS.MSDOS.DJGPP

  • SIGSEGV when trying to compile helloworld

    From [via djgpp@delorie.com]" @21:1/5 to All on Sun Aug 30 17:30:17 2020
    Hello there,

    if anyone's still listening on here... (site seems to be down since today?)

    wanted to play a bit with DOSBox and DIY programs to run on it.

    I went to the DJGPP site and used the file picker to give me the list of
    needed files for compiling on a windows host, with Allegro.
    (Although I did not link Allegro at this point.)

    Unzipped everything into a folder:
    C:\DJGPP_GCC9
    and set up env variables for DJGPP to the .env file and DJDIR to this dir.

    (the gcc9 appendix because I also tried some guy from the internet's
    gcc4.2.1 with allegro all-in-one package, and I did get stuff compiled
    with it, but when I saw there's actually a GCC9 version, I needed to try
    that)

    I literally made a helloworld program:

    #include <stdio.h>
    int main(const int argc, const char** argv)
    {
    printf( "Hello World!" );
    }

    Saved in: C:\DOSBOX_dos_projects\DJGPP\testproj\test.cpp
    With Windows7 (32bit) Cmd shell in that folder, called this, and got the output:

    C:\DOSBOX~3\DJGPP\testproj>gcc -g test.cpp -o test.exe
    Exiting due to signal SIGSEGV
    Stack Fault at eip=00000a11
    eax=00010001 ebx=01c40080 ecx=0165a400 edx=004207bf esi=000023c2
    edi=000023b2
    ebp=0042773a esp=0042773a program=C:\DJGPP_~1\BIN\GCC.EXE
    cs: sel=00cf base=0000d150 limit=00000db0
    ds: sel=00b7 base=00005860 limit=0000ffff
    es: sel=0040 invalid
    fs: sel=0000
    gs: sel=0000
    ss: sel=00b7 base=00005860 limit=0000ffff
    App stack: [00423b78..00223b7c] Exceptn stack: [00223ac8..00221b88]
    .
    Since the delorie.com site is currently down I looked elsewhere and
    found some FAQ where it says this could come from the .env file having
    extra whitespace somewhere... although supposedly fixed by now. And I
    did not edit that file, it's the one I just unzipped.

    Any ideas what could be wrong?


    - Steve

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Aug 30 18:32:41 2020
    Hey, thanks for replying.

    What does go32-v2 reports in that DOSBox?

    This:

    go32/v2 version 2.0 built Oct 18 2015 09:41:08
    Usage: go32 coff-image [args]
    Rename this to go32.exe only if you need a go32 that can run v2 binaries as
    well as v1 binaries (old makefiles). Put ahead of the old go32 in
    your PATH
    but do not delete your old go32 - leave it in the PATH after this one.
    Set GO32_V2_DEBUG=y in the environment to get verbose output.

    DPMI memory available: 704964 Kb
    DPMI swap space available: 0 Kb

    Hm. DPMI swap space 0 = bad?


    From: "sleepy_dog@gmx.de [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Sun, 30 Aug 2020 17:30:17 +0200

    Saved in: C:\DOSBOX_dos_projects\DJGPP\testproj\test.cpp
    With Windows7 (32bit) Cmd shell in that folder, called this, and got the
    output:

    C:\DOSBOX~3\DJGPP\testproj>gcc -g test.cpp -o test.exe
    Exiting due to signal SIGSEGV
    Stack Fault at eip=00000a11
    eax=00010001 ebx=01c40080 ecx=0165a400 edx=004207bf esi=000023c2
    edi=000023b2
    ebp=0042773a esp=0042773a program=C:\DJGPP_~1\BIN\GCC.EXE
    cs: sel=00cf base=0000d150 limit=00000db0
    ds: sel=00b7 base=00005860 limit=0000ffff
    es: sel=0040 invalid
    fs: sel=0000
    gs: sel=0000
    ss: sel=00b7 base=00005860 limit=0000ffff
    App stack: [00423b78..00223b7c] Exceptn stack: [00223ac8..00221b88]
    .
    Since the delorie.com site is currently down I looked elsewhere and
    found some FAQ where it says this could come from the .env file having
    extra whitespace somewhere... although supposedly fixed by now. And I
    did not edit that file, it's the one I just unzipped.

    Any ideas what could be wrong?
    What does go32-v2 reports in that DOSBox?


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Aug 30 19:14:04 2020
    From: "sleepy_dog@gmx.de [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Sun, 30 Aug 2020 17:30:17 +0200

    Saved in: C:\DOSBOX_dos_projects\DJGPP\testproj\test.cpp
    With Windows7 (32bit) Cmd shell in that folder, called this, and got the output:

    C:\DOSBOX~3\DJGPP\testproj>gcc -g test.cpp -o test.exe
    Exiting due to signal SIGSEGV
    Stack Fault at eip=00000a11
    eax=00010001 ebx=01c40080 ecx=0165a400 edx=004207bf esi=000023c2
    edi=000023b2
    ebp=0042773a esp=0042773a program=C:\DJGPP_~1\BIN\GCC.EXE
    cs: sel=00cf base=0000d150 limit=00000db0
    ds: sel=00b7 base=00005860 limit=0000ffff
    es: sel=0040 invalid
    fs: sel=0000
    gs: sel=0000
    ss: sel=00b7 base=00005860 limit=0000ffff
    App stack: [00423b78..00223b7c] Exceptn stack: [00223ac8..00221b88]
    .
    Since the delorie.com site is currently down I looked elsewhere and
    found some FAQ where it says this could come from the .env file having
    extra whitespace somewhere... although supposedly fixed by now. And I
    did not edit that file, it's the one I just unzipped.

    Any ideas what could be wrong?

    What does go32-v2 reports in that DOSBox?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Aug 30 20:03:28 2020
    From: "sleepy_dog@gmx.de [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Sun, 30 Aug 2020 18:32:41 +0200

    go32/v2 version 2.0 built Oct 18 2015 09:41:08
    Usage: go32 coff-image [args]
    Rename this to go32.exe only if you need a go32 that can run v2 binaries as
    well as v1 binaries (old makefiles). Put ahead of the old go32 in
    your PATH
    but do not delete your old go32 - leave it in the PATH after this one.
    Set GO32_V2_DEBUG=y in the environment to get verbose output.

    DPMI memory available: 704964 Kb
    DPMI swap space available: 0 Kb

    Hm. DPMI swap space 0 = bad?

    No, that's OK. Many "modern" DPMI providers just lump all the memory
    together (700MB in your case), and don't bother separating them into
    RAM and swap.

    The memory amount sounds enough, so I'm puzzled what could be the
    problem. Maybe some Windows 7 specific problem? I think someone
    posted here long ago tricks to get the Windows DPMI provider more
    friendly... Anyone?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Aug 30 20:00:30 2020
    problem. Maybe some Windows 7 specific problem? I think someone
    posted here long ago tricks to get the Windows DPMI provider more
    friendly... Anyone?

    Hrm, interesting.
    After reading your comment, I fired up my old Windows XP machine, and
    copied over this very DJGPP_GCC9 folder I talked about earlier, 1:1 onto
    my winxp machine, set the environment variables.
    And compiled the program successfully.
    I have no good enough understanding of the operating systems to have any
    clue what that can be due to.
    Alas, that thing isn't a viable machine to work on anymore.



    From: "sleepy_dog@gmx.de [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Sun, 30 Aug 2020 18:32:41 +0200

    go32/v2 version 2.0 built Oct 18 2015 09:41:08
    Usage: go32 coff-image [args]
    Rename this to go32.exe only if you need a go32 that can run v2 binaries as >> well as v1 binaries (old makefiles). Put ahead of the old go32 in
    your PATH
    but do not delete your old go32 - leave it in the PATH after this one.
    Set GO32_V2_DEBUG=y in the environment to get verbose output.

    DPMI memory available: 704964 Kb
    DPMI swap space available: 0 Kb

    Hm. DPMI swap space 0 = bad?
    No, that's OK. Many "modern" DPMI providers just lump all the memory together (700MB in your case), and don't bother separating them into
    RAM and swap.

    The memory amount sounds enough, so I'm puzzled what could be the
    problem. Maybe some Windows 7 specific problem? I think someone
    posted here long ago tricks to get the Windows DPMI provider more
    friendly... Anyone?


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Sun Aug 30 18:35:55 2020
    Hi all,

    On Sun, 30 Aug 2020 at 17:10, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:

    From: "sleepy_dog@gmx.de [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Sun, 30 Aug 2020 18:32:41 +0200

    go32/v2 version 2.0 built Oct 18 2015 09:41:08
    Usage: go32 coff-image [args]
    Rename this to go32.exe only if you need a go32 that can run v2 binaries as
    well as v1 binaries (old makefiles). Put ahead of the old go32 in
    your PATH
    but do not delete your old go32 - leave it in the PATH after this one. Set GO32_V2_DEBUG=y in the environment to get verbose output.

    DPMI memory available: 704964 Kb
    DPMI swap space available: 0 Kb

    Hm. DPMI swap space 0 = bad?

    No, that's OK. Many "modern" DPMI providers just lump all the memory together (700MB in your case), and don't bother separating them into
    RAM and swap.

    The memory amount sounds enough, so I'm puzzled what could be the
    problem. Maybe some Windows 7 specific problem? I think someone
    posted here long ago tricks to get the Windows DPMI provider more
    friendly... Anyone?

    I thought he was running DJGPP under DOSBox and not directly under
    Windows 7. DOSBox is designed to be able to run old games, so not
    even long filenames are implemented. How about trying some other kind
    of virtual machine, eg. QEMU or VMWare?

    I've said it before, but NT series Windows support for DOS programs is
    pathetic (and on 64-bit versions it is nonexistent). Then again,
    Linux never directly supported DOS programs at all. In both cases,
    virtual machines are the solution.

    Cheers,
    Albert.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Aug 30 21:46:18 2020
    From: "A. Wik (awik32@gmail.com) [via djgpp@delorie.com]" <djgpp@delorie.com> Date: Sun, 30 Aug 2020 18:35:55 +0000

    I've said it before, but NT series Windows support for DOS programs is pathetic

    The XP NTVDM is quite good, though.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Aug 30 21:02:50 2020
    Hi,

    I thought he was running DJGPP under DOSBox and not directly under Windows 7.

    No no, I planned to make the programs run under DOSbox, but compiling is from within windows.
    I guess for debugging I would have to use RHIDE within DOSbox, esp. because Graphics modes are involved.
    But I'd prefer not to use it as an actual editor.

    How about trying some other kind of virtual machine, eg. QEMU or VMWare?

    I was now thinking of running a VirtualBox WinXp32 image on my system,
    with a shared folder for the sources, and a build script I trigger manually. That would be somewhat workable, I guess.

    I have no experience with QEMU or VMWare, and interoperability with
    stuff that runs on the host system.


    Hi all,

    On Sun, 30 Aug 2020 at 17:10, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
    From: "sleepy_dog@gmx.de [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Sun, 30 Aug 2020 18:32:41 +0200

    go32/v2 version 2.0 built Oct 18 2015 09:41:08
    Usage: go32 coff-image [args]
    Rename this to go32.exe only if you need a go32 that can run v2 binaries as >>> well as v1 binaries (old makefiles). Put ahead of the old go32 in
    your PATH
    but do not delete your old go32 - leave it in the PATH after this one. >>> Set GO32_V2_DEBUG=y in the environment to get verbose output.

    DPMI memory available: 704964 Kb
    DPMI swap space available: 0 Kb

    Hm. DPMI swap space 0 = bad?
    No, that's OK. Many "modern" DPMI providers just lump all the memory
    together (700MB in your case), and don't bother separating them into
    RAM and swap.

    The memory amount sounds enough, so I'm puzzled what could be the
    problem. Maybe some Windows 7 specific problem? I think someone
    posted here long ago tricks to get the Windows DPMI provider more
    friendly... Anyone?
    I thought he was running DJGPP under DOSBox and not directly under
    Windows 7. DOSBox is designed to be able to run old games, so not
    even long filenames are implemented. How about trying some other kind
    of virtual machine, eg. QEMU or VMWare?

    I've said it before, but NT series Windows support for DOS programs is pathetic (and on 64-bit versions it is nonexistent). Then again,
    Linux never directly supported DOS programs at all. In both cases,
    virtual machines are the solution.

    Cheers,
    Albert.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com] on Sun Aug 30 19:53:54 2020
    On Sun, 30 Aug 2020 at 19:09, sleepy_dog@gmx.de [via
    djgpp@delorie.com] <djgpp@delorie.com> wrote:

    Hi,

    Hi,

    How about trying some other kind of virtual machine, eg. QEMU or VMWare?

    I was now thinking of running a VirtualBox WinXp32 image on my system,
    with a shared folder for the sources, and a build script I trigger manually. That would be somewhat workable, I guess.

    I have no experience with QEMU or VMWare, and interoperability with
    stuff that runs on the host system.

    VirtualBox should work too. In terms of ease of use, it is somewhere
    between QEMU (harder) and VMWare (easier). VMWare seems to be the
    fastest. There is also Microsoft Virtual PC. If you have the
    Professional version of Win7, you get a copy of XP to run as a VM, but
    I was never able to get that to work.

    But rather than running a WinXP VM, why not go for a Win9x one? It is
    much lighter on the hardware resources and a lot more DOS-friendly.

    You can set up a network share (between the VM and host) so that you
    can edit your files on the host, and use the guest to compile them
    "natively". This is what I'm doing (my host is Linux 64-bit, the
    guest is Win98SE). An added benefit to this solution, is that you can
    use a serial port based debugger without requiring more than one
    computer.

    -aw

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com on Sun Aug 30 12:40:17 2020
    DOSBox provides a (mostly) elegant solution to this -- just share your
    files directly. Unlike other VMs, DOSBox allows you to directly mount the
    host filesystem within the DOS VM -- so you can just edit the files
    directly using your editor of choice on Windows, then switch to DOSBox and build them. (You do need to watch out for long filenames, though.) In the
    odd occurrence of being out of sync, the DOSBox command "resync" will
    refresh its cached directory of the host FS.

    Damian


    On Sun, Aug 30, 2020 at 12:09 PM sleepy_dog@gmx.de [via djgpp@delorie.com] < djgpp@delorie.com> wrote:

    Hi,

    I thought he was running DJGPP under DOSBox and not directly under
    Windows 7.

    No no, I planned to make the programs run under DOSbox, but compiling is
    from within windows.
    I guess for debugging I would have to use RHIDE within DOSbox, esp.
    because Graphics modes are involved.
    But I'd prefer not to use it as an actual editor.

    How about trying some other kind of virtual machine, eg. QEMU or VMWare?

    I was now thinking of running a VirtualBox WinXp32 image on my system,
    with a shared folder for the sources, and a build script I trigger
    manually.
    That would be somewhat workable, I guess.

    I have no experience with QEMU or VMWare, and interoperability with
    stuff that runs on the host system.


    Hi all,

    On Sun, 30 Aug 2020 at 17:10, Eli Zaretskii (eliz@gnu.org) [via djgpp@delorie.com] <djgpp@delorie.com> wrote:
    From: "sleepy_dog@gmx.de [via djgpp@delorie.com]" <djgpp@delorie.com>
    Date: Sun, 30 Aug 2020 18:32:41 +0200

    go32/v2 version 2.0 built Oct 18 2015 09:41:08
    Usage: go32 coff-image [args]
    Rename this to go32.exe only if you need a go32 that can run v2
    binaries as
    well as v1 binaries (old makefiles). Put ahead of the old go32 in
    your PATH
    but do not delete your old go32 - leave it in the PATH after this
    one.
    Set GO32_V2_DEBUG=y in the environment to get verbose output.

    DPMI memory available: 704964 Kb
    DPMI swap space available: 0 Kb

    Hm. DPMI swap space 0 = bad?
    No, that's OK. Many "modern" DPMI providers just lump all the memory
    together (700MB in your case), and don't bother separating them into
    RAM and swap.

    The memory amount sounds enough, so I'm puzzled what could be the
    problem. Maybe some Windows 7 specific problem? I think someone
    posted here long ago tricks to get the Windows DPMI provider more
    friendly... Anyone?
    I thought he was running DJGPP under DOSBox and not directly under
    Windows 7. DOSBox is designed to be able to run old games, so not
    even long filenames are implemented. How about trying some other kind
    of virtual machine, eg. QEMU or VMWare?

    I've said it before, but NT series Windows support for DOS programs is pathetic (and on 64-bit versions it is nonexistent). Then again,
    Linux never directly supported DOS programs at all. In both cases,
    virtual machines are the solution.

    Cheers,
    Albert.





    <div dir="ltr"><div>DOSBox provides a (mostly) elegant solution to this -- just share your files directly. Unlike other VMs, DOSBox allows you to directly mount the host filesystem within the DOS VM -- so you can just edit the files directly using your
    editor of choice on Windows, then switch to DOSBox and build them. (You do need to watch out for long filenames, though.) In the odd occurrence of being out of sync, the DOSBox command &quot;resync&quot; will refresh its cached directory of the host FS.</
    <div><br></div><div>Damian</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 30, 2020 at 12:09 PM <a href="mailto:sleepy_dog@gmx.de">sleepy_dog@gmx.de</a> [via <a href="mailto:djgpp@delorie.com">
    djgpp@delorie.com</a>] &lt;<a href="mailto:djgpp@delorie.com">djgpp@delorie.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>

    &gt; I thought he was running DJGPP under DOSBox and not directly under Windows 7.<br>

    No no, I planned to make the programs run under DOSbox, but compiling is from within windows.<br>
    I guess for debugging I would have to use RHIDE within DOSbox, esp. because Graphics modes are involved.<br>
    But I&#39;d prefer not to use it as an actual editor.<br>

    &gt; How about trying some other kind of virtual machine, eg. QEMU or VMWare?<br>

    I was now thinking of running a VirtualBox WinXp32 image on my system,<br>
    with a shared folder for the sources, and a build script I trigger manually<br> That would be somewhat workable, I guess.<br>

    I have no experience with QEMU or VMWare, and interoperability with<br>
    stuff that runs on the host system.<br>


    &gt; Hi all,<br>
    &gt;<br>
    &gt; On Sun, 30 Aug 2020 at 17:10, Eli Zaretskii (<a href="mailto:eliz@gnu.org" target="_blank">eliz@gnu.org</a>) [via<br>
    &gt; <a href="mailto:djgpp@delorie.com" target="_blank">djgpp@delorie.com</a>] &lt;<a href="mailto:djgpp@delorie.com" target="_blank">djgpp@delorie.com</a>&gt; wrote:<br>
    &gt;&gt;&gt; From: &quot;<a href="mailto:sleepy_dog@gmx.de" target="_blank">sleepy_dog@gmx.de</a> [via <a href="mailto:djgpp@delorie.com" target="_blank">djgpp@delorie.com</a>]&quot; &lt;<a href="mailto:djgpp@delorie.com" target="_blank">djgpp@delorie.
    com</a>&gt;<br>
    &gt;&gt;&gt; Date: Sun, 30 Aug 2020 18:32:41 +0200<br>
    &gt;&gt;&gt;<br>
    &gt;&gt;&gt; go32/v2 version 2.0 built Oct 18 2015 09:41:08<br>
    &gt;&gt;&gt; Usage: go32 coff-image [args]<br>
    &gt;&gt;&gt; Rename this to go32.exe only if you need a go32 that can run v2 binaries as<br>
    &gt;&gt;&gt;    well as v1 binaries (old makefiles).  Put ahead of the old go32 in<br>
    &gt;&gt;&gt; your PATH<br>
    &gt;&gt;&gt;    but do not delete your old go32 - leave it in the PATH after this one.<br>
    &gt;&gt;&gt; Set GO32_V2_DEBUG=y in the environment to get verbose output<br> &gt;&gt;&gt;<br>
    &gt;&gt;&gt; DPMI memory available: 704964 Kb<br>
    &gt;&gt;&gt; DPMI swap space available: 0 Kb<br>
    &gt;&gt;&gt;<br>
    &gt;&gt;&gt; Hm. DPMI swap space 0 = bad?<br>
    &gt;&gt; No, that&#39;s OK.  Many &quot;modern&quot; DPMI providers just lump all the memory<br>
    &gt;&gt; together (700MB in your case), and don&#39;t bother separating them into<br>
    &gt;&gt; RAM and swap.<br>
    &gt;&gt;<br>
    &gt;&gt; The memory amount sounds enough, so I&#39;m puzzled what could be the<br>
    &gt;&gt; problem.  Maybe some Windows 7 specific problem?  I think someone<br>
    &gt;&gt; posted here long ago tricks to get the Windows DPMI provider more<br> &gt;&gt; friendly...  Anyone?<br>
    &gt; I thought he was running DJGPP under DOSBox and not directly under<br> &gt; Windows 7.  DOSBox is designed to be able to run old games, so not<br> &gt; even long filenames are implemented.  How about trying some other kind<br>
    &gt; of virtual machine, eg. QEMU or VMWare?<br>
    &gt;<br>
    &gt; I&#39;ve said it before, but NT series Windows support for DOS programs is<br>
    &gt; pathetic (and on 64-bit versions it is nonexistent).  Then again,<br> &gt; Linux never directly supported DOS programs at all.  In both cases,<br> &gt; virtual machines are the solution.<br>
    &gt;<br>
    &gt; Cheers,<br>
    &gt; Albert.<br>
    &gt;<br>


    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Aug 30 21:55:47 2020
    This is a multi-part message in MIME format.
    Ah! Resync. I didn't know that. I had heard of sync'ing problems with
    DOSBox & file system and seen myself that files created from the host OS
    after starting DOSBox aren't showing up.
    Will try that. Lack of long file names in DOSBox is kind of a pain, though.

    DOSBox provides a (mostly) elegant solution to this -- just share your
    files directly. Unlike other VMs, DOSBox allows you to directly mount
    the host filesystem within the DOS VM -- so you can just edit the
    files directly using your editor of choice on Windows, then switch to
    DOSBox and build them. (You do need to watch out for long filenames,
    though.) In the odd occurrence of being out of sync, the DOSBox
    command "resync" will refresh its cached directory of the host FS.

    Damian


    On Sun, Aug 30, 2020 at 12:09 PM sleepy_dog@gmx.de
    <mailto:sleepy_dog@gmx.de> [via djgpp@delorie.com
    <mailto:djgpp@delorie.com>] <djgpp@delorie.com
    <mailto:djgpp@delorie.com>> wrote:

    Hi,

    > I thought he was running DJGPP under DOSBox and not directly
    under Windows 7.

    No no, I planned to make the programs run under DOSbox, but
    compiling is from within windows.
    I guess for debugging I would have to use RHIDE within DOSbox,
    esp. because Graphics modes are involved.
    But I'd prefer not to use it as an actual editor.

    > How about trying some other kind of virtual machine, eg. QEMU or
    VMWare?

    I was now thinking of running a VirtualBox WinXp32 image on my system,
    with a shared folder for the sources, and a build script I trigger
    manually.
    That would be somewhat workable, I guess.

    I have no experience with QEMU or VMWare, and interoperability with
    stuff that runs on the host system.


    > Hi all,
    >
    > On Sun, 30 Aug 2020 at 17:10, Eli Zaretskii (eliz@gnu.org
    <mailto:eliz@gnu.org>) [via
    > djgpp@delorie.com <mailto:djgpp@delorie.com>] <djgpp@delorie.com
    <mailto:djgpp@delorie.com>> wrote:
    >>> From: "sleepy_dog@gmx.de <mailto:sleepy_dog@gmx.de> [via
    djgpp@delorie.com <mailto:djgpp@delorie.com>]" <djgpp@delorie.com
    <mailto:djgpp@delorie.com>>
    >>> Date: Sun, 30 Aug 2020 18:32:41 +0200
    >>>
    >>> go32/v2 version 2.0 built Oct 18 2015 09:41:08
    >>> Usage: go32 coff-image [args]
    >>> Rename this to go32.exe only if you need a go32 that can run
    v2 binaries as
    >>> well as v1 binaries (old makefiles). Put ahead of the old
    go32 in
    >>> your PATH
    >>> but do not delete your old go32 - leave it in the PATH
    after this one.
    >>> Set GO32_V2_DEBUG=y in the environment to get verbose output.
    >>>
    >>> DPMI memory available: 704964 Kb
    >>> DPMI swap space available: 0 Kb
    >>>
    >>> Hm. DPMI swap space 0 = bad?
    >> No, that's OK. Many "modern" DPMI providers just lump all the
    memory
    >> together (700MB in your case), and don't bother separating them
    into
    >> RAM and swap.
    >>
    >> The memory amount sounds enough, so I'm puzzled what could be the
    >> problem. Maybe some Windows 7 specific problem? I think someone
    >> posted here long ago tricks to get the Windows DPMI provider more
    >> friendly... Anyone?
    > I thought he was running DJGPP under DOSBox and not directly under
    > Windows 7. DOSBox is designed to be able to run old games, so not
    > even long filenames are implemented. How about trying some
    other kind
    > of virtual machine, eg. QEMU or VMWare?
    >
    > I've said it before, but NT series Windows support for DOS
    programs is
    > pathetic (and on 64-bit versions it is nonexistent). Then again,
    > Linux never directly supported DOS programs at all. In both cases,
    > virtual machines are the solution.
    >
    > Cheers,
    > Albert.
    >




    <html>
    <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
    </head>
    <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><br>
    Ah! Resync. I didn't know that. I had heard of sync'ing problems
    with DOSBox &amp; file system and seen myself that files created
    from the host OS after starting DOSBox aren't showing up.<br>
    Will try that. Lack of long file names in DOSBox is kind of a
    pain, though.<br>
    <br>
    </div>
    <blockquote cite="mid:CAN9LaySW9UBQy1-NtpRDssG-pWN0NMPCmw_g5DPBY95HkxsuoA@mail.gmailcom"
    type="cite">
    <div dir="ltr">
    <div>DOSBox provides a (mostly) elegant solution to this -- just
    share your files directly. Unlike other VMs, DOSBox allows you
    to directly mount the host filesystem within the DOS VM -- so
    you can just edit the files directly using your editor of
    choice on Windows, then switch to DOSBox and build them. (You
    do need to watch out for long filenames, though.) In the odd
    occurrence of being out of sync, the DOSBox command "resync"
    will refresh its cached directory of the host FS.</div>
    <div><br>
    </div>
    <div>Damian</div>
    <div><br>
    </div>
    </div>
    <br>
    <div class="gmail_quote">
    <div dir="ltr" class="gmail_attr">On Sun, Aug 30, 2020 at 12:09
    PM <a moz-do-not-send="true" href="mailto:sleepy_dog@gmx.de">sleepy_dog@gmx.de</a>
    [via <a moz-do-not-send="true"
    href="mailto:djgpp@delorie.com">djgpp@delorie.com</a>] &lt;<a
    moz-do-not-send="true" href="mailto:djgpp@delorie.com">djgpp@delorie.com</a>&gt;
    wrote:<br>
    </div>
    <blockquote class="gmail_quote" style="margin:0px 0px 0px
    0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
    <br>
    &gt; I thought he was running DJGPP under DOSBox and not
    directly under Windows 7.<br>
    <br>
    No no, I planned to make the programs run under DOSbox, but
    compiling is from within windows.<br>
    I guess for debugging I would have to use RHIDE within DOSbox,
    esp. because Graphics modes are involved.<br>
    But I'd prefer not to use it as an actual editor.<br>
    <br>
    &gt; How about trying some other kind of virtual machine, eg.
    QEMU or VMWare?<br>
    <br>
    I was now thinking of running a VirtualBox WinXp32 image on my
    system,<br>
    with a shared folder for the sources, and a build script I
    trigger manually.<br>
    That would be somewhat workable, I guess.<br>
    <br>
    I have no experience with QEMU or VMWare, and interoperability
    with<br>
    stuff that runs on the host system.<br>
    <br>
    <br>
    &gt; Hi all,<br>
    &gt;<br>
    &gt; On Sun, 30 Aug 2020 at 17:10, Eli Zaretskii (<a
    moz-do-not-send="true" href="mailto:eliz@gnu.org"
    target="_blank">eliz@gnu.org</a>) [via<br>
    &gt; <a moz-do-not-send="true"
    href="mailto:djgpp@delorie.com" target="_blank">djgpp@delorie.com</a>]
    &lt;<a moz-do-not-send="true" href="mailto:djgpp@delorie.com"
    target="_blank">djgpp@delorie.com</a>&gt; wrote:<br>
    &gt;&gt;&gt; From: "<a moz-do-not-send="true"
    href="mailto:sleepy_dog@gmx.de" target="_blank">sleepy_dog@gmx.de</a>
    [via <a moz-do-not-send="true"
    href="mailto:djgpp@delorie.com" target="_blank">djgpp@delorie.com</a>]"
    &lt;<a moz-do-not-send="true" href="mailto:djgpp@delorie.com"
    target="_blank">djgpp@delorie.com</a>&gt;<br>
    &gt;&gt;&gt; Date: Sun, 30 Aug 2020 18:32:41 +0200<br>
    &gt;&gt;&gt;<br>
    &gt;&gt;&gt; go32/v2 version 2.0 built Oct 18 2015 09:41:08<br>
    &gt;&gt;&gt; Usage: go32 coff-image [args]<br>
    &gt;&gt;&gt; Rename this to go32.exe only if you need a go32
    that can run v2 binaries as<br>
    &gt;&gt;&gt;    well as v1 binaries (old makefiles).  Put
    ahead of the old go32 in<br>
    &gt;&gt;&gt; your PATH<br>
    &gt;&gt;&gt;    but do not delete your old go32 - leave it in
    the PATH after this one.<br>
    &gt;&gt;&gt; Set GO32_V2_DEBUG=y in the environment to get
    verbose output.<br>
    &gt;&gt;&gt;<br>
    &gt;&gt;&gt; DPMI memory available: 704964 Kb<br>
    &gt;&gt;&gt; DPMI swap space available: 0 Kb<br>
    &gt;&gt;&gt;<br>
    &gt;&gt;&gt; Hm. DPMI swap space 0 = bad?<br>
    &gt;&gt; No, that's OK.  Many "modern" DPMI providers just
    lump all the memory<br>
    &gt;&gt; together (700MB in your case), and don't bother
    separating them into<br>
    &gt;&gt; RAM and swap.<br>
    &gt;&gt;<br>
    &gt;&gt; The memory amount sounds enough, so I'm puzzled what
    could be the<br>
    &gt;&gt; problem.  Maybe some Windows 7 specific problem?  I
    think someone<br>
    &gt;&gt; posted here long ago tricks to get the Windows DPMI
    provider more<br>
    &gt;&gt; friendly...  Anyone?<br>
    &gt; I thought he was running DJGPP under DOSBox and not
    directly under<br>
    &gt; Windows 7.  DOSBox is designed to be able to run old
    games, so not<br>
    &gt; even long filenames are implemented.  How about trying
    some other kind<br>
    &gt; of virtual machine, eg. QEMU or VMWare?<br>
    &gt;<br>
    &gt; I've said it before, but NT series Windows support for
    DOS programs is<br>
    &gt; pathetic (and on 64-bit versions it is nonexistent). 
    Then again,<br>
    &gt; Linux never directly supported DOS programs at all.  In
    both cases,<br>
    &gt; virtual machines are the solution.<br>
    &gt;<br>
    &gt; Cheers,<br>
    &gt; Albert.<br>
    &gt;<br>
    <br>
    <br>
    </blockquote>
    </div>
    </blockquote>
    <p><br>
    </p>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sun Aug 30 22:06:49 2020
    This is a multi-part message in MIME format.
    can't find anything about resync, though

    Ah! Resync. I didn't know that. I had heard of sync'ing problems with
    DOSBox & file system and seen myself that files created from the host
    OS after starting DOSBox aren't showing up.
    Will try that. Lack of long file names in DOSBox is kind of a pain,
    though.

    DOSBox provides a (mostly) elegant solution to this -- just share
    your files directly. Unlike other VMs, DOSBox allows you to directly
    mount the host filesystem within the DOS VM -- so you can just edit
    the files directly using your editor of choice on Windows, then
    switch to DOSBox and build them. (You do need to watch out for long
    filenames, though.) In the odd occurrence of being out of sync, the
    DOSBox command "resync" will refresh its cached directory of the host FS.

    Damian


    On Sun, Aug 30, 2020 at 12:09 PM sleepy_dog@gmx.de
    <mailto:sleepy_dog@gmx.de> [via djgpp@delorie.com
    <mailto:djgpp@delorie.com>] <djgpp@delorie.com
    <mailto:djgpp@delorie.com>> wrote:

    Hi,

    > I thought he was running DJGPP under DOSBox and not directly
    under Windows 7.

    No no, I planned to make the programs run under DOSbox, but
    compiling is from within windows.
    I guess for debugging I would have to use RHIDE within DOSbox,
    esp. because Graphics modes are involved.
    But I'd prefer not to use it as an actual editor.

    > How about trying some other kind of virtual machine, eg. QEMU
    or VMWare?

    I was now thinking of running a VirtualBox WinXp32 image on my
    system,
    with a shared folder for the sources, and a build script I
    trigger manually.
    That would be somewhat workable, I guess.

    I have no experience with QEMU or VMWare, and interoperability with
    stuff that runs on the host system.


    > Hi all,
    >
    > On Sun, 30 Aug 2020 at 17:10, Eli Zaretskii (eliz@gnu.org
    <mailto:eliz@gnu.org>) [via
    > djgpp@delorie.com <mailto:djgpp@delorie.com>]
    <djgpp@delorie.com <mailto:djgpp@delorie.com>> wrote:
    >>> From: "sleepy_dog@gmx.de <mailto:sleepy_dog@gmx.de> [via
    djgpp@delorie.com <mailto:djgpp@delorie.com>]" <djgpp@delorie.com
    <mailto:djgpp@delorie.com>>
    >>> Date: Sun, 30 Aug 2020 18:32:41 +0200
    >>>
    >>> go32/v2 version 2.0 built Oct 18 2015 09:41:08
    >>> Usage: go32 coff-image [args]
    >>> Rename this to go32.exe only if you need a go32 that can run
    v2 binaries as
    >>> well as v1 binaries (old makefiles). Put ahead of the old
    go32 in
    >>> your PATH
    >>> but do not delete your old go32 - leave it in the PATH
    after this one.
    >>> Set GO32_V2_DEBUG=y in the environment to get verbose output.
    >>>
    >>> DPMI memory available: 704964 Kb
    >>> DPMI swap space available: 0 Kb
    >>>
    >>> Hm. DPMI swap space 0 = bad?
    >> No, that's OK. Many "modern" DPMI providers just lump all the
    memory
    >> together (700MB in your case), and don't bother separating
    them into
    >> RAM and swap.
    >>
    >> The memory amount sounds enough, so I'm puzzled what could be the
    >> problem. Maybe some Windows 7 specific problem? I think someone
    >> posted here long ago tricks to get the Windows DPMI provider more
    >> friendly... Anyone?
    > I thought he was running DJGPP under DOSBox and not directly under
    > Windows 7. DOSBox is designed to be able to run old games, so not
    > even long filenames are implemented. How about trying some
    other kind
    > of virtual machine, eg. QEMU or VMWare?
    >
    > I've said it before, but NT series Windows support for DOS
    programs is
    > pathetic (and on 64-bit versions it is nonexistent). Then again,
    > Linux never directly supported DOS programs at all. In both cases,
    > virtual machines are the solution.
    >
    > Cheers,
    > Albert.
    >





    <html>
    <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
    </head>
    <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">can't find anything about resync,
    though<br>
    </div>
    <blockquote cite="mid:cf45a5e1-edd6-aa3f-0207-853bd138274a@gmx.de"
    type="cite">
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
    <div class="moz-cite-prefix"><br>
    Ah! Resync. I didn't know that. I had heard of sync'ing problems
    with DOSBox &amp; file system and seen myself that files created
    from the host OS after starting DOSBox aren't showing up.<br>
    Will try that. Lack of long file names in DOSBox is kind of a
    pain, though.<br>
    <br>
    </div>
    <blockquote cite="mid:CAN9LaySW9UBQy1-NtpRDssG-pWN0NMPCmw_g5DPBY95HkxsuoA@mail.gmailcom"
    type="cite">
    <div dir="ltr">
    <div>DOSBox provides a (mostly) elegant solution to this --
    just share your files directly. Unlike other VMs, DOSBox
    allows you to directly mount the host filesystem within the
    DOS VM -- so you can just edit the files directly using your
    editor of choice on Windows, then switch to DOSBox and build
    them. (You do need to watch out for long filenames, though.)
    In the odd occurrence of being out of sync, the DOSBox
    command "resync" will refresh its cached directory of the
    host FS.</div>
    <div><br>
    </div>
    <div>Damian</div>
    <div><br>
    </div>
    </div>
    <br>
    <div class="gmail_quote">
    <div dir="ltr" class="gmail_attr">On Sun, Aug 30, 2020 at
    12:09 PM <a moz-do-not-send="true"
    href="mailto:sleepy_dog@gmx.de">sleepy_dog@gmx.de</a> [via
    <a moz-do-not-send="true" href="mailto:djgpp@delorie.com">djgpp@delorie.com</a>]
    &lt;<a moz-do-not-send="true"
    href="mailto:djgpp@delorie.com">djgpp@delorie.com</a>&gt;
    wrote:<br>
    </div>
    <blockquote class="gmail_quote" style="margin:0px 0px 0px
    0.8ex;border-left:1px solid
    rgb(204,204,204);padding-left:1ex">Hi,<br>
    <br>
    &gt; I thought he was running DJGPP under DOSBox and not
    directly under Windows 7.<br>
    <br>
    No no, I planned to make the programs run under DOSbox, but
    compiling is from within windows.<br>
    I guess for debugging I would have to use RHIDE within
    DOSbox, esp. because Graphics modes are involved.<br>
    But I'd prefer not to use it as an actual editor.<br>
    <br>
    &gt; How about trying some other kind of virtual machine,
    eg. QEMU or VMWare?<br>
    <br>
    I was now thinking of running a VirtualBox WinXp32 image on
    my system,<br>
    with a shared folder for the sources, and a build script I
    trigger manually.<br>
    That would be somewhat workable, I guess.<br>
    <br>
    I have no experience with QEMU or VMWare, and
    interoperability with<br>
    stuff that runs on the host system.<br>
    <br>
    <br>
    &gt; Hi all,<br>
    &gt;<br>
    &gt; On Sun, 30 Aug 2020 at 17:10, Eli Zaretskii (<a
    moz-do-not-send="true" href="mailto:eliz@gnu.org"
    target="_blank">eliz@gnu.org</a>) [via<br>
    &gt; <a moz-do-not-send="true"
    href="mailto:djgpp@delorie.com" target="_blank">djgpp@delorie.com</a>]
    &lt;<a moz-do-not-send="true"
    href="mailto:djgpp@delorie.com" target="_blank">djgpp@delorie.com</a>&gt;
    wrote:<br>
    &gt;&gt;&gt; From: "<a moz-do-not-send="true"
    href="mailto:sleepy_dog@gmx.de" target="_blank">sleepy_dog@gmx.de</a>
    [via <a moz-do-not-send="true"
    href="mailto:djgpp@delorie.com" target="_blank">djgpp@delorie.com</a>]"
    &lt;<a moz-do-not-send="true"
    href="mailto:djgpp@delorie.com" target="_blank">djgpp@delorie.com</a>&gt;<br>
    &gt;&gt;&gt; Date: Sun, 30 Aug 2020 18:32:41 +0200<br>
    &gt;&gt;&gt;<br>
    &gt;&gt;&gt; go32/v2 version 2.0 built Oct 18 2015 09:41:08<br>
    &gt;&gt;&gt; Usage: go32 coff-image [args]<br>
    &gt;&gt;&gt; Rename this to go32.exe only if you need a go32
    that can run v2 binaries as<br>
    &gt;&gt;&gt;    well as v1 binaries (old makefiles).  Put
    ahead of the old go32 in<br>
    &gt;&gt;&gt; your PATH<br>
    &gt;&gt;&gt;    but do not delete your old go32 - leave it
    in the PATH after this one.<br>
    &gt;&gt;&gt; Set GO32_V2_DEBUG=y in the environment to get
    verbose output.<br>
    &gt;&gt;&gt;<br>
    &gt;&gt;&gt; DPMI memory available: 704964 Kb<br>
    &gt;&gt;&gt; DPMI swap space available: 0 Kb<br>
    &gt;&gt;&gt;<br>
    &gt;&gt;&gt; Hm. DPMI swap space 0 = bad?<br>
    &gt;&gt; No, that's OK.  Many "modern" DPMI providers just
    lump all the memory<br>
    &gt;&gt; together (700MB in your case), and don't bother
    separating them into<br>
    &gt;&gt; RAM and swap.<br>
    &gt;&gt;<br>
    &gt;&gt; The memory amount sounds enough, so I'm puzzled
    what could be the<br>
    &gt;&gt; problem.  Maybe some Windows 7 specific problem?  I
    think someone<br>
    &gt;&gt; posted here long ago tricks to get the Windows DPMI
    provider more<br>
    &gt;&gt; friendly...  Anyone?<br>
    &gt; I thought he was running DJGPP under DOSBox and not
    directly under<br>
    &gt; Windows 7.  DOSBox is designed to be able to run old
    games, so not<br>
    &gt; even long filenames are implemented.  How about trying
    some other kind<br>
    &gt; of virtual machine, eg. QEMU or VMWare?<br>
    &gt;<br>
    &gt; I've said it before, but NT series Windows support for
    DOS programs is<br>
    &gt; pathetic (and on 64-bit versions it is nonexistent). 
    Then again,<br>
    &gt; Linux never directly supported DOS programs at all.  In
    both cases,<br>
    &gt; virtual machines are the solution.<br>
    &gt;<br>
    &gt; Cheers,<br>
    &gt; Albert.<br>
    &gt;<br>
    <br>
    <br>
    </blockquote>
    </div>
    </blockquote>
    <p><br>
    </p>
    </blockquote>
    <p><br>
    </p>
    </body>
    </html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to sleepy_dog@gmx.de on Sun Aug 30 22:12:56 2020
    On 2020-08-30 21:02, sleepy_dog@gmx.de [via djgpp@delorie.com] wrote:
    Hi,

    I thought he was running DJGPP under DOSBox and not directly under Windows 7.

    No no, I planned to make the programs run under DOSbox, but compiling is from within windows.
    I guess for debugging I would have to use RHIDE within DOSbox, esp. because Graphics modes are involved.
    But I'd prefer not to use it as an actual editor.

    What you'll want to use is a cross-compiler. You can find prebuilt cross- toolchain packages for a number of GNU/Linux distros online, or use a
    toolchain build script (I maintain one on Github, called build-gcc).

    How about trying some other kind of virtual machine, eg. QEMU or VMWare?

    I was now thinking of running a VirtualBox WinXp32 image on my system,
    with a shared folder for the sources, and a build script I trigger manually. That would be somewhat workable, I guess.

    I have no experience with QEMU or VMWare, and interoperability with
    stuff that runs on the host system.

    I would recommend DOSBox-X, which tries to accurately emulate all the ins and outs of a complete DOS system, and is specifically geared towards development on the platform.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to sleepy_dog@gmx.de on Mon Aug 31 06:18:35 2020
    On 8/30/20 6:30 PM, sleepy_dog@gmx.de [via djgpp@delorie.com] wrote:

    Saved in: C:\DOSBOX_dos_projects\DJGPP\testproj\test.cpp
    With Windows7 (32bit) Cmd shell in that folder, called this, and got the output:

    C:\DOSBOX~3\DJGPP\testproj>gcc -g test.cpp -o test.exe
    Exiting due to signal SIGSEGV
    Stack Fault at eip=00000a11
    eax=00010001 ebx=01c40080 ecx=0165a400 edx=004207bf esi=000023c2
    edi=000023b2
    ebp=0042773a esp=0042773a program=C:\DJGPP_~1\BIN\GCC.EXE
    cs: sel=00cf  base=0000d150  limit=00000db0
    ds: sel=00b7  base=00005860  limit=0000ffff
    es: sel=0040  invalid
    fs: sel=0000
    gs: sel=0000
    ss: sel=00b7  base=00005860  limit=0000ffff
    App stack: [00423b78..00223b7c]  Exceptn stack: [00223ac8..00221b88]

    Looks very similar to NTVDM crashes in Windows 10 32 bit when executing nested

    32 bit DPMI programs:

    - any attempt to run DJGPP program directly or indirectly (for example through bat file) fails

    Microsoft broke NTVDM DPMI support some years ago in Windows 10.

    I have not tested Windows 7 or 8 but according to some tests

    (http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp/2020/04/15/16:34:15):

    - worked in Windows 7 32 bit some time ago

    - did not work in Windows 8 32 bit that time

    Also: have You set DPMI memory limit to something larger than the default 32 MB? There is no need to

    to reboot after adding setting to registry for that.


    Andris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Fri Sep 4 00:49:26 2020
    Hello all,

    in my recent thread about SIGSEGV when compiling on win7,

    someone mentioned remote debugging.
    If this works well, it's probably the best way to debug graphical
    programs. (I've read somewhere about a variant of switching between
    debugger and graphics mode of the program to debug... I can't quite
    imagine that anything resembling a pleasant flow can result from that,
    and it probably creates artificial problems for the gfx application to
    be debugged)

    I have looked a bit, while there is GDB for DJGPP, there seems to be no gdbserver for it, right?
    So, how would one actually do remote debugging, from a more recent
    windows machine running an IDE that supports GDB over to Windows XP, or
    98, or even DOS?
    "Serial debugging" was mentioned, I at first thought this would work
    similar, just using a serialconnection instead of ethernet. Apparently
    it does not work the same way as you'd debug a program via gdbserver
    running on a remote system.
    I'm not familiar with that at all. Can someone point me to an explanation? Since I am somewhat familiar with gdb and it is very common, going a
    route that rests on that would probably make most sense, even if it
    works somewhat different on DOS.

    - Steve

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to djgpp@delorie.com on Thu Sep 3 23:11:04 2020
    Hi all,

    On Thu, 3 Sep 2020 at 22:55, sleepy_dog@gmx.de [via djgpp@delorie.com] <djgpp@delorie.com> wrote:

    "Serial debugging" was mentioned, I at first thought this would work
    similar, just using a serialconnection instead of ethernet. Apparently
    it does not work the same way as you'd debug a program via gdbserver
    running on a remote system.
    I'm not familiar with that at all. Can someone point me to an explanation? Since I am somewhat familiar with gdb and it is very common, going a
    route that rests on that would probably make most sense, even if it
    works somewhat different on DOS.

    I'm currently using the wdeb386 debugger on Win98SE under VMware.
    This is probably not what you're looking for.

    -aw

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pif0017@gmail.com@21:1/5 to All on Fri Sep 4 08:01:55 2020
    Le vendredi 4 septembre 2020 à 01:15:04 UTC+2, A. Wik (awik32@gmail.com) [via djgpp@delorie.com] a écrit :
    Hi all,
    On Thu, 3 Sep 2020 at 22:55, sleep...@gmx.de [via dj...@delorie.com] <dj...@delorie.com> wrote:

    "Serial debugging" was mentioned, I at first thought this would work similar, just using a serialconnection instead of ethernet. Apparently
    it does not work the same way as you'd debug a program via gdbserver running on a remote system.
    I'm not familiar with that at all. Can someone point me to an explanation?

    Gdb and gdbserver have conception problems and have quiet the same hardware requirements. Gdb teams try solve that since a long time by making them sharing more and more software but when djgpp was supported by gdb, gdbserver did not. Now, they simply
    drop djgpp support since version 8 or 9.

    To remote or cross debug, you have to build a cross gdb that target i586-msdos-djgpp. Gdb 7.12 is okay for that.

    To debug your program running on djgpp compliant environment, you have to embedded a gdbstub. You can find one on djgpp ftp. The stub will act like gdbserver by implementing gdb communication protocol but it will be a part of your program that will catch
    interruption and talk to gdb at this moment.
    Stubs use serial connection because it use less hardware and software that tcp/IP over ethernet.

    Since I am somewhat familiar with gdb and it is very common, going a
    route that rests on that would probably make most sense, even if it
    works somewhat different on DOS.

    The stubs on ftp doesn't implement all gdb features. It's okay for breakpoint, stepping, read and write memory, intercepted segmentation fault. Your program have to be single threaded, multi thread is not implemented.

    S. Guillaume

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to pif0017@gmail.com on Fri Sep 4 18:35:47 2020
    Thanks for that info! I'll look into that.
    Single threaded, yeah. I don't think there is much to gain from using
    multiple threads for a program targeted for DOSBox, so I'm fine with that.



    pif0017@gmail.com wrote:
    Le vendredi 4 septembre 2020 à 01:15:04 UTC+2, A. Wik (awik32@gmail.com) [via djgpp@delorie.com] a écrit :
    Hi all,
    On Thu, 3 Sep 2020 at 22:55, sleep...@gmx.de [via dj...@delorie.com]
    <dj...@delorie.com> wrote:
    "Serial debugging" was mentioned, I at first thought this would work
    similar, just using a serialconnection instead of ethernet. Apparently
    it does not work the same way as you'd debug a program via gdbserver
    running on a remote system.
    I'm not familiar with that at all. Can someone point me to an explanation?
    Gdb and gdbserver have conception problems and have quiet the same hardware requirements. Gdb teams try solve that since a long time by making them sharing more and more software but when djgpp was supported by gdb, gdbserver did not. Now, they simply
    drop djgpp support since version 8 or 9.

    To remote or cross debug, you have to build a cross gdb that target i586-msdos-djgpp. Gdb 7.12 is okay for that.

    To debug your program running on djgpp compliant environment, you have to embedded a gdbstub. You can find one on djgpp ftp. The stub will act like gdbserver by implementing gdb communication protocol but it will be a part of your program that will
    catch interruption and talk to gdb at this moment.
    Stubs use serial connection because it use less hardware and software that tcp/IP over ethernet.

    Since I am somewhat familiar with gdb and it is very common, going a
    route that rests on that would probably make most sense, even if it
    works somewhat different on DOS.
    The stubs on ftp doesn't implement all gdb features. It's okay for breakpoint, stepping, read and write memory, intercepted segmentation fault. Your program have to be single threaded, multi thread is not implemented.

    S. Guillaume



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From pif0017@gmail.com@21:1/5 to All on Fri Sep 4 10:15:28 2020
    Le vendredi 4 septembre 2020 à 18:39:54 UTC+2, sleepy_dog@gmx.de [via djgpp@delorie.com] a écrit :
    Thanks for that info! I'll look into that.
    Single threaded, yeah. I don't think there is much to gain from using multiple threads for a program targeted for DOSBox, so I'm fine with that. pif...@gmail.com wrote:
    Le vendredi 4 septembre 2020 à 01:15:04 UTC+2, A. Wik (awi...@gmail.com) [via dj...@delorie.com] a écrit :
    Hi all,
    On Thu, 3 Sep 2020 at 22:55, sleep...@gmx.de [via dj...@delorie.com]
    <dj...@delorie.com> wrote:
    "Serial debugging" was mentioned, I at first thought this would work
    similar, just using a serialconnection instead of ethernet. Apparently >>> it does not work the same way as you'd debug a program via gdbserver
    running on a remote system.
    I'm not familiar with that at all. Can someone point me to an explanation?
    Gdb and gdbserver have conception problems and have quiet the same hardware requirements. Gdb teams try solve that since a long time by making them sharing more and more software but when djgpp was supported by gdb, gdbserver did not. Now, they
    simply drop djgpp support since version 8 or 9.

    To remote or cross debug, you have to build a cross gdb that target i586-msdos-djgpp. Gdb 7.12 is okay for that.

    To debug your program running on djgpp compliant environment, you have to embedded a gdbstub. You can find one on djgpp ftp. The stub will act like gdbserver by implementing gdb communication protocol but it will be a part of your program that will
    catch interruption and talk to gdb at this moment.
    Stubs use serial connection because it use less hardware and software that tcp/IP over ethernet.

    Since I am somewhat familiar with gdb and it is very common, going a
    route that rests on that would probably make most sense, even if it
    works somewhat different on DOS.
    The stubs on ftp doesn't implement all gdb features. It's okay for breakpoint, stepping, read and write memory, intercepted segmentation fault. Your program have to be single threaded, multi thread is not implemented.

    S. Guillaume



    Gdbstub work well on real hardware and virtualbox by plugging serial port to local tcp port.
    Can you give a back if it works on dosbox please.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From [via djgpp@delorie.com]" @21:1/5 to All on Sat Sep 5 23:17:44 2020
    Hey,

    one of the suggestions for somewhat convenient-ish DOS development setup
    was using WIn98 which runs DOS programs well, and makes things easier
    wrt. sharing files over network, to compile, run & debug things on.

    archive.org has a virtual box image with win98 SE, that works, eh, out
    of the box.

    I searched a bit for info and found several references that Win98 can
    run the .NET framework up to 2.0.
    As that would make things a lot easier for me to whip some some little
    tools here and there, that sounded like good news.

    archive.org also had a MSDN CD from 2006-april with an installer for
    NET 2.0 that indeed starts on win98.
    But it says one requirement is not met - the presense of Windows
    Installer 2.0.

    Searching a bit more, 2.0 of win installer is indeed also the last
    version that Win98 can be retrofitted with.

    I have had no luck so far to find an installer-installer that works, though.
    I crawled a bit on the MS sites in wayback machine and found an
    instmsi.exe and InstMsiA.exe.
    Run any of those in the Win98 VM, it claims "already installed".
    Well, the .NET 2.0 installer diagrees, but it did see that I installed
    the other peculiar requirement at first listed: IE5.01 ...

    Anybody got an idea of how I can get Installer 2 onto my Win98
    installation?

    P.S. my fallback is thw WinXP VM where I got .NET 4 installed, much
    nicer C# version, but a lot worse DOS graphics and sound compatibility
    from some first tests. (trying out stuff from the demo folder of the
    Allegro multi media library)

    - Steve

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From RayeR@21:1/5 to All on Tue Sep 8 17:41:54 2020
    BTW 2 things to try on new OS:
    1) DJGPP crosscompiler
    https://github.com/andrewwutw/build-djgpp/releases
    you can then run native DJGPP compiler even from 64-bit Windows, Linux, MasoX...

    2) NTVDMx64
    http://windows98.xf.cz/#NTVDMx64
    This allows you to run DOS programs from Windows 64-bit console as you was used to in NTVDM ini 32-bit Windows. This new build supports also DOS/DPMI programs but it's still experimental and unstable. It's many times faster in compiling than DOSBOX but
    still slow due to full CPU emulation. The advantage is easy to use, you don't need launch any emu/VM, you can access all disks, call dos program from batch file mixed with win32 console apps, redirect in/out, pipe streams...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)