xref: /aosp_15_r20/external/gptfdisk/README.Windows (revision 57696d54d05c64fd1b1787f8371dbcf104911cfb)

GPT fdisk (aka gdisk) and FixParts

by Roderick W. Smith, [email protected]

******************************** 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.