There's probably plenty of online converters out there, but I'd suggest taking a look at Pandoc (https://pandoc.org/index.html), which can convert markdown to just about any other format under the sun.

Sorry, been meaning to reply to this for a while now! In general I think this looks okay. I'm not familiar with this kind of markup though, can it be processed to a plain text file for the binary release? The 'markup' is markdown, a simple text format that is actually quite readable as plain text. ...

Greatpsycho wrote: ↑

Sun 22 Nov, 2020 11:35 am

The compiler only complaining about declaration in the for loop. This patch removes declaration in the for loop and solves compile problem on CentOS.

Feel free to integrate this into PCem Sarah, I've committed the changes to MiniVHD as-is.

My recommendation would be to upgrade your compiler. May not be possible on an old version of CentOS. I shouldn't think adding -std=gnu99" to configure.ac would cause too many issues though, although maaaybe it would need to be linux or gcc specific? EDIT: If the only thing the compiler is complain...

There is still compile problem exists on CentOS. Your VHD code uses C99 extensions but it's not enabled by default on CentOS. To solve this problem, configure.ac file must be modified as described below, or all VHD related code must be rewritten to avoid using C99 extensions. pcem-compile-error.png...

SarahWalker wrote: ↑

Sat 21 Nov, 2020 8:59 pm

All committed as of 8fa271d.

Thank you very much.

Thank you for your patience with this.

Just tried NT, first part of installation can be done normally, but during boot, I get gibberish during ntldr or unknown hard error on the dynamic VHD I'm using, this doesn't happen with fixed size VHD or plain RAW. Note that the file system is FAT16, not NTFS, of the dynamic vhd I'm using. I can't...

I can't reproduce this in PCem. I can reproduce it in another emulator. It is not yet known whether this is an underlying MiniVHD issue, or an integration issue.

@Greatpsycho does removing the typedef from minivhd_internal.h and including the minivhd.h header instead work for you? I'd rather avoid the #ifdef if I can.

Laucian wrote: ↑

Wed 18 Nov, 2020 11:43 pm

I just tested the latest patch on Linux, everything still works.

Good to know.

I've got things setup on my Ubuntu box to do some rudimentary testing as well now, so I (hopefully) shouldn't break linux compilation any more.

Alright. Hopefully third times the charm... Now, MSVC gets _ftelli64/_fseeki64. MinGW and MinGW-w64 get ftello64/fseeko64. Linux gets large file ftello/fseeko by way of _FILE_OFFSET_BITS and OSX/BSD supposedly default to large file support for ftello/fseeko. Please let this work. diff --git a/src/mi...

SarahWalker wrote: ↑

Wed 18 Nov, 2020 8:47 pm

With the most recent patch it no longer builds for me on mingw. ftello and fseeko don't exist.

Whyyyyyyyyyyyyy!!!!!!

Ok, looks like I need an ifdef for mingw specifically to separate from mingw-w64. They obviously can't be treated the same.

I just tested and it is working fine under Linux now. As usual cross-platform support is a bit of a pain. Thank you very much for the work on the patch, differencing images are such a lifesaver when it comes to managing Windows 9x and a large software library. Thanks. If you notice any issues with ...

Ok, here's a patch that should correct the segfaults on Linux. Turns out I had forgotten to set the large file macro's while attempting to use fseeko64 and friends. I decided in the end to switch to using fseeko, and setting _FILE_OFFSET_BITS 64 instead. It seems to work alright with both Linux and ...

I finally had more time to test out the changes. It compiles fine now. Under Linux I am experiencing Segmentation fault (core dumped) whenever I create a new VHD or attach an existing one to a machine. Nooooo, not the dreaded segfault :( Let's see if I can replicate. EDIT: yes I can. A bit more Lin...

I have one more little tweak. My apologies for not including it earlier, it's something I meant to do, and it slipped my mind. This diff replaces the "remember to format" message with a "don't open/modify the parent" message when creating a differencing VHD image. The former message isn't very relev...

Alright, here's some fixes. Committed at 322b25a4. I also unilaterally removed the use of _wfopen_s, commit 95e6819f. Thank you Sarah. I originally used _wfopen(), so that change is fine by me. Those '_s' functions were something I kind of glossed over during my review of the code. I know for next ...

Alright, here's some fixes.

And yes, I actually tested compiling this on linux this time...

Diff is against the latest pcem master as of writing this (5ae201b).

If you don't want to deal with the diff, the code is at https://github.com/shermp/pcem/tree/vhd ... tion-fixes

leilei wrote: ↑

Sun 15 Nov, 2020 3:24 am

I'm seeing the same strcpy/strncpy build failures with MinGW 4.7.2

Siigh... Thanks for the feedback.

I'll either revert back to what I had originally (strcpy, strncpy), or switch to a straight memcpy alternative (I'm copying between fixed arrays in some cases, so that's a viable option.

Committed at 602d6f1c. Currently when building under Linux there is a build error due case sensitiveness. The "minivhd" folder is specified as "MiniVHD" in wx-config.c. The build continues after that is fixed. wx-config.c:23:10: fatal error: MiniVHD/minivhd.h: No such file or directory 23 | #includ...

Committed at 602d6f1c. I'll have a look at the image not closing bug. Hopefully won't be too difficult to fix. Thank you very much. When I was running it through the debugger, the image only seems to be closed during the ide reset, which only seems to happen when emulation starts. (this is of cours...

With the assistance of @sards3 , here's a new patch based on PCem v16. I'm hoping that this sneaks in just before the v17 feature freeze. This basically has full VHD support. Fixed, sparse (dynamic) and differencing images all work. Creation of differencing images works. Be very careful when using d...

Note, if you haven't updated MSYS2 in a while, there's been some package maintainer changes and corresponding signing key changes. I found it easier to restart from scratch with a fresh MSYS2 reinstall.

Just made a few updates to the OP. No major changes, but I went through it again on the latest version of MSYS2 (still slow, sigh...).

Main changes are using an updated version of the npcap SDK, and using git to clone the github pcem repository.

Note, a lot of user facing strings will be in 'pc.xrc', although looking at the docs, I get the impression that strings here SHOULD be auto-translated if the resource is constructed correctly. Translation files are sill needed to actually translate of course...

Or, just type in the desired size of disk (in MB) and let the GUI do the calculations for you :p

The largest heads and sectors-per-track supported by PCem is 16 and 63 respectively, so for large hard disks, you have to use the cylinders to get the final size. This is an issue I've run into with VHD support, as it only supports up to 65535 cylinders, so for large hard disks, you are supposed to...

The largest heads and sectors-per-track supported by PCem is 16 and 63 respectively, so for large hard disks, you have to use the cylinders to get the final size. This is an issue I've run into with VHD support, as it only supports up to 65535 cylinders, so for large hard disks, you are supposed to ...

Note that PCem is almost all C, with a few bits of C to C++ wrapping for the wxwidgets bit.

If one were to do translation stuff, it would probably be best to use the tools provided by wxWidgets for the job. See https://docs.wxwidgets.org/trunk/overview_i18n.html on the approach wxWidgets uses.

Glad to hear! I must admit I don't tend to use MSYS2 these days. The makefile autoconf produces is so sloooooow. I instead use the included windows makefile with mingw-w64 and manually installed libraries. It's a LOT quicker! EDIT: This was a reason I experimented with cmake a while back. But Sarah ...