README.Windows - LeafOS-Project/android_external_gptfdisk - Gitiles

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