GPT fdisk (aka gdisk) and FixParts by Roderick W. Smith, rodsmith@rodsbooks.com ******************************** IMPORTANT ******************************** Most versions of Windows cannot boot from a GPT disk on BIOS-based computers, and most varieties prior to Vista cannot read GPT disks. GPT fdisk is a partition editor for GPT disks, and it will *AUTOMATICALLY CONVERT* MBR disks to GPT form. Therefore, you should **NOT** use GPT fdisk on a Windows system unless you fully understand what you're doing or are certain that your computer boots in EFI/UEFI mode! If you accidentally use GPT fdisk on a BIOS-mode boot disk, or perhaps even on a data disk, you may find recovery to be very difficult! Pre-installed Windows 8 and later systems almost always use GPT disks and boot in EFI/UEFI mode, but self-installed Windows 8 systems sometimes use BIOS mode. This caveat does not apply to FixParts, though; that tool works only on MBR disks. *************************************************************************** Read the main README file for general information on the program, and read the gdisk.html or fixparts.html documents (the Linux man pages converted to HTML format) for detailed use information. My GPT fdisk Web page, http://www.rodsbooks.com/gdisk/, provides a more tutorial introduction to the software. I originally wrote GPT fdisk on Linux, and some Linux- and Unix-centric language remains in the documentation. Windows Use Notes ----------------- The Windows version of GPT fdisk was added with version 0.6.2 of the package. The Windows binary package includes the gdisk.exe interactive text-mode program file as well as the sgdisk program that's available with Linux, FreeBSD, and OS X builds. Beginning with version 0.8.10, I'm distributing both 32-bit and 64-bit binaries, which include the strings "32" or "64" in their names. The 32-bit binaries work fine on most versions of Windows, but some 64-bit installations of Windows 8 lack 32-bit support libraries and so may need the 64-bit binaries. The FixParts program (fixparts32.exe and fixparts64.exe) is new with GPT fdisk 0.7.0. As described in the main README file, this program fixes certain partition table problems that can be created by buggy partitioning software. Windows seems to be unfazed by most such problems, but I've not done an extensive survey of Windows partitioning tools on this score. To install the programs, copy the gdisk32.exe, cgdisk32.exe, sgdisk32.exe and fixparts32.exe (or gdisk64.exe, cgdisk64.exe, sgdisk64.exe and fixparts64.exe) program files to any directory on your path, such as C:\Windows. Alternatively, you can change to the program's directory or type its complete path whenever you use it. To use the programs, first launch a Command Prompt as the Administrator. To do this, locate the Command Prompt program icon, right-click it, and select "Run as Administrator." If you use a non-Administrator Command Prompt, you won't be able to edit hard disk partition tables, although you will be able to edit raw disk image files. The program requires a hard disk identifier as an option. You can specify this in either of two forms. The first way is as a number followed by a colon, as in: gdisk 0: Disks are numbered starting from 0, so the preceding command launches gdisk on the first disk. The second way to specify a disk device is via a harder-to-remember name: gdisk32 \\.\physicaldrive0 This command is equivalent to the earlier one -- it edits the partition table on the first physical disk. Change the number at the end of the device name to change the disk edited. If you pass the "-l" option to gdisk64.exe in addition to the disk identifier, the program displays the current partition table information and then exits. (Alternatively, you can pass "-p" to sgdisk64.exe.) This use entails no risk to MBR disks, since the program never writes data back to the disk when used in this way. As noted above, editing the first disk with GPT fdisk is a Bad Idea on older BIOS-based computers. Newer computers typically use an Extensible Firmware Interface (EFI) and boot from GPT disks. It's safer to edit non-boot disks, which usually have numbers of 1 and above, but only if you run a version of Windows with GPT support. For more information on Windows' support of GPT, see Microsoft's Web page on the topic: http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx The Windows binaries I've compiled do not support Unicode UTF-16LE GPT partition names. This feature was added to version 0.7.1 of the software for Linux, FreeBSD, and OS X, and with changes to some #ifndef lines in the source files, it can be compiled for Windows; however, it seems to do little good in Windows because of Command Prompt window and/or ICU library limitations. Thus, I've omitted this support in the interests of simplifying the binary distribution, since including it would mean distributing the ICU libraries. Source Code and Compilation Issues ---------------------------------- I have successfully compiled GPT fdisk using three different Windows compilers: - MinGW (https://www.mingw-w64.org/), using either a Linux-hosted cross-compiler or under Windows using the original MinGW or MSYS2 (https://www.msys2.org). This is my only GPT fdisk development environment for Windows in 2022. - Microsoft Visual C++ 2008 Express (http://www.microsoft.com/express/Windows/) -- This compiler requires a third-party stdint.h file (I used the one from http://web.archive.org/web/20130317001712/http://msinttypes.googlecode.com/svn/trunk/stdint.h), but it otherwise worked fine the last time I tried it. A project is easily created by adding all the *.h files and all the *.cc files except diskio-unix.cc, sgdisk.cc, and whichever program file you intend to NOT build (gdisk.cc or fixparts.cc). - Microsoft Visual C++ 2010 Express -- This compiler works much like the 2008 version, although I didn't need to add a third-party stdint.h file. Although I used Microsoft Visual C++ in the past, I haven't tried using these compilers recently and so I can't promise they would work today (in 2022). If you modify GPT fdisk to get it to compile under another compiler, I welcome submission of patches. The following instructions focus on use of MinGW to compile GPT fdisk for Windows. My primary development environment is Ubuntu Linux, using the MinGW cross-compiler. This system can compile the gdisk and fixparts binaries with no need for additional libraries; after installing MinGW (via the g++-mingw-w64 package in Ubuntu, or the equivalent in another distribution), you can type "TARGET=win32 make" to compile 32-bit binaries, and "TARGET=win64 make" to compile 64-bit binaries. This will attempt to build gdisk, sgdisk, and fixparts; but the sgdisk build will fail until you install the popt libraries, as described shortly. You can build the other binaries by specifying them, as in "TARGET=win64 make gdisk" to build the 64-bit gdisk binary alone. If you use Windows, your best bet is likely to be to install the MSYS2 package (https://www.msys2.org). This package provides MinGW and a package management system based on pacman (used by Arch Linux) for installing additional libraries. To install the libraries needed to compile sgdisk and cgdisk, type "pacman -S mingw-w64-x86_64-popt mingw-w64-x86_64-gettext mingw-w64-x86_64-ncurses" if you want to compile 64-bit binaries; change 'x86_64' to 'i686' for 32-bit packages. This command will install the popt library needed by sgdisk and the ncurses library needed by cgdisk, along with gettext, which is needed by popt. With these libraries installed, you should be able to compile all four Linux programs -- gdisk, cgdisk, sgdisk, and fixparts. Typing "make" alone in the MSYS2 shell should build all four programs for the host architecture (x86-64 or i686); to compile for the other architecture, you must specify it with a "TARGET=" specification, as under Linux. (The Makefile does not currently support ARM64 targets for Windows.) If you want to compile sgdisk for Windows under Linux, you can do so; however, you must copy the relevant header and library files from a Windows installation to Linux. Specifically, you must copy: Windows File Linux Directory ------------ --------------- /mingw64/include/popt.h /usr/x86_64-w64-mingw32/include/ /mingw64/lib/libpopt.a /usr/x86_64-w64-mingw32/lib/ /mingw64/lib/libintl.a /usr/x86_64-w64-mingw32/lib/ /mingw64/lib/libiconv.a /usr/x86_64-w64-mingw32/lib/ For 32-bit binaries, change /mingw64 to /mingw32 on the Windows source and x86_64-w64-mingw32 to i686-w64-mingw32 on the Linux destination. In theory, you should be able to do something similar to compile cgdisk. The relevant files are: Windows File Linux Directory ------------ --------------- /mingw64/include/ncursesw/curses.h /usr/x86_64-w64-mingw32/include/ncursesw/ /mingw64/include/ncursesw/ncurses.h /usr/x86_64-w64-mingw32/include/ncursesw/ /mingw64/include/ncursesw/ncurses_dll.h /usr/x86_64-w64-mingw32/include/ncursesw/ /mingw64/include/ncursesw/unctrl.h /usr/x86_64-w64-mingw32/include/ncursesw/ /mingw64/lib/libncurses.a /usr/x86_64-w64-mingw32/lib/ In practice, this has not worked for me; the compilation fails with a complaint about an undefined reference to 'nanosleep'. My guess is that the ncurses version installed in Windows is too new to work with the MinGW libraries in Ubuntu (20.04 or 22.04). It's conceivable it would work with another distribution, though. The Makefile is configured to create statically-linked binaries so as to simplify installation of the binaries. If you want smaller binaries, you can remove the various static options from the Makefile. You can also strip the binaries ("make strip") to remove unused code.