Windows打印机API封装

前面工作需要对打印机的部分功能进行调用,主要是获取和设置默认打印机,修改纸张尺寸,修改打印方向等。
因此封装了如下的代码。
头文件


	/**
	 * 获取默认打印机名字
	 * @param name: 打印机名字
	 * @param name: 名字buffer长度
	 * @return: 0-获取成功 1-获取失败
	 */
	DLLEXPORT_API int getDefaultPrinter(char *printerName, unsigned int bufferLen);


	/** 设置默认打印机
	 * @param printerName: 打印机名字
	 * @return: 0-获取成功 1-获取失败
	 */
	DLLEXPORT_API int setDefaultPrinter(const char *printerName);

	/*增加规格 自定义纸张
	 * @param printerName: 打印机名字
	 * @param paperName: 纸张名字
	 * @param width: 宽度 单位:cm
	 * @param hight: 高度 单位:cm
	 * @param leftMargin: 左边距 单位:cm
	 * @param topMargin: 上边距 单位:cm
	 * @param rightMargin: 右边距 单位:cm
	 * @param bottomMargin: 下边距 单位:cm
	 * @return: 0-获取成功 1-获取失败
	 */
	DLLEXPORT_API int addCustomPaper(const char *printerName, const char *paperName, unsigned int width, unsigned int hight,
		unsigned leftMargin, unsigned int topMargin, unsigned int rightMargin, unsigned int bottomMargin);

	/* 删除纸张
	* @param printerName: 打印机名字
	* @param paperName: 纸张名字
	* @return: 0-获取成功 1-获取失败
	*/
	DLLEXPORT_API int deleteCustormPaper(const char *printerName, const char *paperName);

	/* 获取纸张尺寸
	* @param printerName: 打印机名字
	* @param paperName: 纸张名字
	* @param bufferLen: 缓冲区长度
	* @return: 0-获取成功 1-获取失败
	*/
	DLLEXPORT_API int getPaperSize(const char *printerName, char *paperName, unsigned int bufferLen);

	/* 设置打印机默认纸张和方向
	* @param printerName: 打印机名字
	* @param paperName: 纸张名字
	* @param orientation: 打印方向 1-纵向 2-横向
	* @return: 0-获取成功 1-获取失败
	*/
	DLLEXPORT_API int setPaper(const char *printerName, const char *paperName, short orientation);

	/* 设置打印机方向
	* @param printerName: 打印机名字
	* @param orientation: 打印方向 1-纵向 2-横向
	* @return: 0-获取成功 1-获取失败
	*/
	DLLEXPORT_API int setOrientation(const char *printerName, short orientation);

实现

#include <Windows.h>
//注意这里必须头文件windows.h在winbase前面
//否则错误error C4430
#include <winbase.h>

typedef TCHAR PAPERNAME[64];

int isWindowsNT() {
	OSVERSIONINFO vi;
	vi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
	BOOL ret = GetVersionEx(&vi);
	if (!ret) {
		return FALSE;
	}

	return vi.dwPlatformId == VER_PLATFORM_WIN32_NT;
}

HANDLE getPrinterHandle(LPCTSTR printerName)
{
	PRINTER_DEFAULTS pds;
	HANDLE hPrinter = NULL;
	ZeroMemory(&pds, sizeof(PRINTER_DEFAULTS));
	pds.DesiredAccess = PRINTER_ALL_ACCESS;
	OpenPrinter((LPSTR)printerName, &hPrinter, &pds);
	return hPrinter;
}

short getPaperSize1(LPCTSTR szPrinterName, LPCTSTR szPortName, PAPERNAME szPaperName)
{
	short nPaperSize = -1;
	//获得可用打印机纸张类型数目
	int nNeeded = DeviceCapabilities(szPrinterName, szPortName, DC_PAPERNAMES, NULL, NULL);
	if (nNeeded)
	{
		PAPERNAME *pszPaperNames = new PAPERNAME[nNeeded]; //分配纸张名称数组
		//获得可用打印机纸张名称数组
		if (DeviceCapabilities(szPrinterName, szPortName, DC_PAPERNAMES, (LPTSTR)pszPaperNames, NULL) != -1)
		{
			int i;
			//查找纸张类型szPaperName在数组中的索引
			for (i = 0; i < nNeeded && strcmp(pszPaperNames[i], szPaperName); i++);
			if (i < nNeeded)
			{
				//获得可用打印机纸张尺寸号数目(应该等于打印机纸张类型数目)
				nNeeded = DeviceCapabilities(szPrinterName, szPortName, DC_PAPERS, NULL, NULL);
				if (nNeeded)
				{
					LPWORD pPapers = new WORD[nNeeded]; //分配纸张尺寸号数组
					//获得可用打印机纸张尺寸号数组
					if (DeviceCapabilities(szPrinterName, szPortName, DC_PAPERS, (LPSTR)pPapers, NULL) != -1)
						nPaperSize = pPapers[i]; //获得纸张类型szPaperName对应的尺寸号
					delete[]pPapers;
				}
			}
		}
		delete[]pszPaperNames;
	}
	return nPaperSize;
}


//获取打印机详细信息,返回的指针用后必须以GlobalFree释放
PRINTER_INFO_2 *getInfo2(LPCTSTR szPrinterName)
{
	HANDLE hPrinter = getPrinterHandle(szPrinterName);
	PRINTER_INFO_2 *ppi2 = NULL;
	DWORD cbNeeded = 0;
	if (hPrinter)
	{
		GetPrinter(hPrinter, 2, 0, 0, &cbNeeded);
		if (cbNeeded)
		{
			ppi2 = (PRINTER_INFO_2 *)GlobalAlloc(GPTR, cbNeeded);
			if (ppi2)
			{
				if (!GetPrinter(hPrinter, 2, (LPBYTE)ppi2, cbNeeded, &cbNeeded))
				{
					GlobalFree((HGLOBAL)ppi2);
					ppi2 = NULL;
				}
			}
		}
		ClosePrinter(hPrinter);
	}
	return ppi2;
}

//打印机设置
BOOL SetInfo2(PRINTER_INFO_2 *ppi2)
{
	HANDLE hPrinter = getPrinterHandle(ppi2->pPrinterName);
	BOOL bOk = FALSE;
	DWORD fMode;
	if (hPrinter)
	{
		fMode = DM_IN_BUFFER | DM_OUT_BUFFER;
		bOk = (DocumentProperties(NULL, hPrinter,
			ppi2->pPrinterName,
			ppi2->pDevMode,
			ppi2->pDevMode,
			fMode) == IDOK &&
			::SetPrinter(hPrinter, 2, (LPBYTE)ppi2, 0));
		ClosePrinter(hPrinter);
	}
	return bOk;
}

int getDefaultPrinter(char *name, unsigned int bufferLen) {
	char tempPrinterName[256] = { 0 };
	unsigned long len = 256;

	BOOL result = GetDefaultPrinter(tempPrinterName, &len);
	if (!result || len == 0 || strlen(tempPrinterName) == 0) {
		return 1;
	}

	if (strlen(tempPrinterName) > bufferLen) {
		return 1;
	}

	strncpy_s(name, bufferLen, tempPrinterName, len);
	return 0;
}

/** 设置默认打印机
* @param printerName: 打印机名字
* @return: 0-获取成功 1-获取失败
*/
int setDefaultPrinter(const char *printerName) {
	return SetDefaultPrinter((LPTSTR)printerName) ? 0 : 1;
}

int addCustomPaper(const char *printerName, const char *paperName, unsigned int width, unsigned int hight,
	unsigned int leftMargin, unsigned int topMargin, unsigned int rightMargin, unsigned int bottomMargin)
{
	if (!isWindowsNT()) {
		return 1;
	}

	FORM_INFO_1 fi1;
	fi1.Flags = FORM_USER;
	fi1.pName = (LPTSTR)paperName;
	fi1.Size.cx = width * 100;
	fi1.Size.cy = hight * 100;
	fi1.ImageableArea.left = leftMargin * 100;
	fi1.ImageableArea.top = topMargin * 100;
	fi1.ImageableArea.right = fi1.Size.cx - rightMargin * 100;
	fi1.ImageableArea.bottom = fi1.Size.cy - bottomMargin * 100;
	HANDLE hPrinter = getPrinterHandle(printerName);
	BOOL bOk = false;
	if (hPrinter) {
		//已存在就修改纸张
		//否则添加自定义纸张
		bOk = (SetForm(hPrinter, (LPSTR)paperName, 1, (LPBYTE)&fi1) || AddForm(hPrinter, 1, (LPBYTE)&fi1));
		ClosePrinter(hPrinter);
	}

	return !bOk;
}

int deleteCustormPaper(const char *printerName, const char *paperName)
{
	if (!isWindowsNT()) {
		return 1;
	}

	BOOL bOk = FALSE;
	HANDLE hPrinter = getPrinterHandle(printerName);
	if (hPrinter) {
		bOk = DeleteForm(hPrinter, (LPSTR)paperName);
		ClosePrinter(hPrinter);
	}
	return !bOk;
}

int getPaperSize(const char *printerName, char *paperName, unsigned int bufferLen)
{
	PRINTER_INFO_2 *ppi2 = getInfo2(printerName);
	if (ppi2 == NULL) {
		return 1;
	}

	int retLen = strlen((const char *)ppi2->pDevMode->dmFormName);
	if (retLen > bufferLen) {
		return 1;
	}
	strncpy(paperName, (const char *)ppi2->pDevMode->dmFormName, retLen);
	return 0;
}

int setPaper(const char *printerName, const char *paperName, short orientation)
{
	BOOL bOk = FALSE;
	PRINTER_INFO_2 *ppi2 = getInfo2(printerName);
	if (ppi2) {
		short nPaperSize = getPaperSize1(printerName, ppi2->pPortName, (TCHAR *)paperName);
		if (nPaperSize != -1) {
			ppi2->pDevMode->dmFields = DM_PAPERSIZE | DM_PAPERWIDTH | DM_PAPERLENGTH | DM_ORIENTATION;
			ppi2->pDevMode->dmPaperSize = nPaperSize;
			ppi2->pDevMode->dmPaperWidth = 0;
			ppi2->pDevMode->dmPaperLength = 0;
			ppi2->pDevMode->dmOrientation = orientation;
			bOk = SetInfo2(ppi2);
		}
		GlobalFree((HGLOBAL)ppi2);
	}
	return !bOk;
}

int setOrientation(const char *printerName, short orientation)
{
	BOOL bOk = FALSE;
	PRINTER_INFO_2 *ppi2 = getInfo2(printerName);
	if (ppi2) {
		ppi2->pDevMode->dmFields = DM_ORIENTATION;
		ppi2->pDevMode->dmOrientation = orientation;
		bOk = SetInfo2(ppi2);
	}
	GlobalFree((HGLOBAL)ppi2);

	return !bOk;
}
  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
简介 WTL 是 Windows Template Library 的缩写,由微软的ATL(Active Template Library) 小组开发,主要是基于 ATL 对Win32API封装。从 2.0 后,功能逐步完善,成为了一个完整的支持窗口的框架(windows framework)。 WTL 功能不如MFC完善,但是比 MFC 更小巧,不依赖 MFC 的DLL。 WTL 不是微软的正式产品,没有微软的官方支持。 WTL有什么? 它给各种类型的应用程序提供了一个基本的框架.注意,虽然没有MFC那样的文档/视结构,但是有视(views). 在WTL有大量的代码来管理视,而且加入自己的代码也很容易. WTL有AppWizard,可以生成SDI,MDI和多线程SDI程序多线程SDI跟IE或Windows Explorer很像.它看起来是打开了多个程序实例,实际上这些窗口都是属于一个进程的). 另外,程序可以是基于对话框的,也可以是基于视的.视可以是基于CWindowImpl的,也可以是基于控件,甚至是IE里的一个HTML页.可以选择程序是否需要一个rebar, command bar (CE-like), toolbar 和/或status bar.另外,程序可以支持ActiveX控件,以及成为一个COM服务器. 这里有几个关于视的选项. WTL提供splitter窗口类(这样在一个视里您可以有两个窗口)和scroll窗口类(这样您的窗口可以比它显示的"视"小). WTL也有个类似MFC的UpDateUI的东西,但是它们不是很一样 - 主要的区别是您需要把需要更新的项用宏映射标注出来,然后您在您的类里加入执行UpdateUI的代码. DDX/DDV在WTL也支持,同样类似MFC,但有不同. 必须加一个宏映射来实现DoDataExchange,然后加入调用它的代码. 现在WTL也有GDI类了.然而,HDC的封装类就像CWindow一样,只进行了很简单的封装 - 它几乎没有加入任何新的功能.不过,在WTL,你可以得到播放meta文件和OpenGL支持. 最有价值的我猜应该是打印机DC的那些继承类 - WTL有打印机支持,甚至打印预览. 当然也有GDI对象的封装. 诸如画笔,画刷,区域等. WTL对所有的Win32 (和W2K) 通用对话框进行了封装.同样尽管简单,但是它的确使请求字体或者文件变的非常的简单. 合成了旧的AtlControls.h,新加了一些封装类. 这些封装封装了W2K控件,以及一些不属于Win32的"控件",像Command Bar, bitmap button, hyperlink 和 wait cursor. WTL 最终把消息分离带入了ATL! 一些新的MSG映射宏将消息分离,调用您类里的消息处理函数.消息处理函数的参数的值是从消息分离得到的.唯一令人头痛的是,您需要查看头文件以确定函数参数的意义. 最后,WTL还有一些实用类.最重要的是CString. 不错,它是从MFC克隆得到的(copy on write),具有(在我知道的范围内)MFC版本的所有方法.还有查找文件的API封装类,以及CRect, CSize and CPoint. WTL中没有什么? 没有Document支持 WTL提供了frame和view,但是没有document。WTL所关注的是用户界面,而document是不可见的,所以它不是WTL关心的范围。 没有Active Document支持 没有ISAPI支持 没有WinInet支持 没有对线程和同步进行包装 没有数据库支持 总结 如果打算写一个Win32 界面程序,我建议您在考虑MFC之前,先试试WTL.使用WTL来写您的代码, 程序将变得小巧些,也更有效率些.使用WTL, 还将得到ATL支持COM好处.可以在2000年一月份的平台SDK中找到WTL.在MSI选项页的Source Code section下. 无 。
WINDOWS环境 Windows几乎不需要介绍。然而人们很容易忘记Windows给办公室和家庭桌上型计算机所带来的重大改变。Windows在其早期曾经走过一段坎坷的道路,征服桌上型计算机市场的前途一度相当渺茫。 Windows简史 在1981年秋天IBM PC推出之后不久,MS-DOS就已经很明显成为PC上的主流操作系统。MS-DOS代表Microsoft Disk Operating System(磁盘操作系统)。MS-DOS是一个小型的操作系统。MS-DOS提供给用户一种命令列接口,提供如DIR和TYPE的命令,也可以将应用程序加载内存执行。对于应用程序写作者,它提供了一组函数呼叫,进行文件的输入输出(I/O )。对于其它的外围处理-尤其是将文字或图形写到显示器上-应用程序可以直接存取PC的硬件。 由于内存和硬件的限制,成熟的图形环境缓慢地才到来。当苹果计算机公司不幸的Lisa计算机在1983年1月发表时,它提供了不同于文字模式环境的另一种选择,并在1984年1月成为Macintosh上图形环境的一种标准。尽管Macintosh的市场占有率在下降,但是它仍然被认为是衡量所有其它图形环境的标准。包括Macintosh和Windows的所有图形环境,其实都要归功于Xerox Palo Alto Research Center(PARC)在70年代中期所作的开拓性研究工作。 Windows是由微软在1983年11月(在Lisa之后,Macintosh之前)宣布,并在两年后(1985年11月)发行。在此后的两年中,紧随着Microsoft Windows早期版本1.0之后,又推出了几种改进版本,以支持国际商业市场,并提供新型视讯显示器和打印机的驱动程序。 Windows版本2.0是在1987年11月正式在市场上推出的。该版本对使用者接口做了一些改进。这些改进中最有效的是使用了可重迭式窗口,而Windows 1.0中使用的是并排式窗口。Windows 2.0还增强了键盘和鼠标接口,特别是加入了菜单和对话框。 至此,Windows还只要求Intel 8086或者8088等级的微处理器,以「实际模式」执行,只能存取地址在1MB以下的内存。Windows/386(在Windows 2.0之后不久发行的)使用Intel 386微处理器的「虚拟8086」模式,实现将直接存取硬件的多个MS-DOS程序窗口化和多任务化。为了统一起见,Windows版本2.1被更名为Windows/286。 Windows 3.0是在1990年5月22日发表的。它将Windows/286和Windows/386结合到同一种产品中。Windows 3.0有了一个很大的改变,这就是对Intel的286、386和486微处理器保护模式的支持。这能使WindowsWindows应用程序能存取高达16MB的内存。Windows用于执行程序和维护文件的「外壳」程序得到了全面的改进。Windows 3.0是第一个在家用和办公室市场上取得立足点的版本。 任何Windows的历史介绍都必须包括一些OS/2的说明,OS/2是对DOS和Windows的另一种选择,最初是由Microsoft和IBM合作开发的。OS/2版本1.0(只有文字模式)在Intel 286(或者后来的)微处理器上运行,在1987年末发布。在1988年10月的OS/2版本1.1中出现了管理图形使用者接口的PM(Presentation Manager)。PM最初的设计构想是成为Windows的一种保护模式版本,但是图形API改变程度太大,致使软件生产厂商很难提供对这两种平台的支持。 到1990年9月,IBM和Microsoft之间的冲突达到了高峰,导致这两个公司最后分道扬镳。IBM接管了OS/2,而Microsoft明确表示Windows将是他们操作系统策略的中心。虽然OS/2仍然拥有一些狂热的崇拜者,但是它远不及Windows这样的普及程度。 Microsoft Windows版本3.1是1992年4月发布的,其中包括的几个重要特性是TrueType字体技术(给Windows带来可缩放的轮廓字体)、多媒体(声音和音乐)、对象连结和嵌入(OLE:Object Linking and Embedding)和通用对话框。跟OS/2一样,Windows 3.1只能在保护模式下运作,并且要求至少配置了1MB内存的286或386处理器。 在1993年7月发表的Windows NT是第一个支持Intel 386、486和Pentium微处理器32位保护模式的Windows版本。Windows NT提供32位平坦寻址,并使用32位的指令集。(本章后面我会谈到一些寻址空间的问题)。Windows NT还可以移植到非Intel处理器上,并在几种使用RISC芯片的工作站上执行。 Windows 95是在1995年8月发布的。和Windows NT一样,Windows 95也支持Intel 386或更高等级处理器的32位保护模式。虽然它缺少Windows NT中的某些功能,诸如高安全性和对RISC机器的可移植性等,但是Windows 95具有需要较少硬件资源的优点。 Windows 98在1998年6月发布,具有许多加强功能,包括执行效能的提高、更好的硬件支持以及与因特网和全球信息网(WWW)更紧密的结合。 Windows方面 Windows 98和Windows NT都是支持32位优先权式多任务(preemptive multitasking)及多线程的图形操作系统。Windows拥有图形使用者接口(GUI ),这种使用者界面也称作「可视化接口」或「图形窗口环境」。有关GUI的概念可追溯至70年代中期,在Alto和Star等机器上以及SmallTalk等环境中由Xerox PARC所作的研究工作。该项研究的成果后来被Apple Computer和Microsoft引入主流并流行起来。虽然有一些争议,但现在已非常清楚,GUI是(Microsoft的Charles Simonyi的说法)一个在个人计算机工业史上集各方面技术大成于一体的最重要产物。 所有GUI都在点矩阵对应的视讯显示器上处理图形。图形提供了使用屏幕的最佳方式、传递信息的可视化丰富多彩环境,以及能够WYSIWYG(what you see is what you get:所见即所得)的图形视讯显示和为书面文件准备好格式化文字输出内容。 在早期,视讯显示器仅用于响应使用者通过键盘输入的文字。在图形使用者接口中,视讯显示器自身成为使用者输入的一个来源。视讯显示器以图标和输入设备(例如按钮和滚动条)的形式显示多种图形对象。使用者可以使用键盘(或者更直接地使用鼠标等指向设备)直接在屏幕上操纵这些对象,拖动图形对象、按下鼠标按钮以及滚动滚动条。 因此,使用者与程序的交流变得更为亲密。这不再是一种从键盘到程序,再到视讯显示器的单向信息流动,使用者已经能够与显示器上的对象直接交互作用了。 使用者不再需要花费长时间学习如何使用计算机或掌握新程序了。Windows让这一切成真,因为所有应用程序都有相同的基本外观和感觉。程序占据一个窗口-屏幕上的一块矩形区域。每个窗口由一个标题列标识。大多数程序功能由程序的菜单开始。用户可使用滚动条观察那些无法在一个屏幕中装下的信息。某些菜单项目触发对话框,用户可在其中输入额外的信息。几乎在每个大的Windows程序中都有一个用于开启文件的特殊对话框。该对话框在所有这些Windows程序中看起来都一样(或接近相同),而且几乎总是从同一菜单选项中启动。 一旦您了解使用一个Windows程序的方法,您就非常容易学习其它的Windows程序。菜单和对话框允许用户试验一个新程序并探究它的功能。大多数Windows程序同时具有键盘接口和鼠标接口。虽然Windows程序的大多数功能可通过键盘控制,但使用鼠标要容易得多。 从程序写作者的角度看,一致的使用者接口来自于Windows建构菜单和对话框的内置程序。所有菜单都有同样的键盘和鼠标接口,因为这项工作是由Windows处理,而不是由应用程序处理。 为便于多个程序的使用,以及这些程序间信息的交换,Windows支持多任务。在同一时刻能有多个Windows程序显示并运行。每个程序在屏幕上占据一个窗口。用户可在屏幕上移动窗口,改变它们的大小,在不同程序间切换,并从一个程序向另一个程序传送数据。因为这些窗口看起来有些像桌面上的纸(当然,这是计算机还未占据办公桌之前的年代),Windows有时被称作:一个显示多个程序的「具象化桌面」。 Windows的早期版本使用一种「非优先权式(non-preemptive)」的多任务系统。这意味着Windows不使用系统定时器将处理时间分配给系统中运行的多个应用程序,程序必须自愿放弃控制以便其它程序运行。在Windows NT和Windows 98中,多任务是优先权式的,而且程序自身可分割成近乎同时执行的多个执行绪。 操作系统不对内存进行管理便无法实现多任务。当新程序启动、旧程序终止时,内存会出现碎裂空间。系统必须能够将闲置的内存空间组织在一起,因此系统必须能够移动内存中的程序代码和数据块。 即使是在8088微处理器上跑的Windows 1.0也能进行这类内存管理。在实际模式限制下,这种能力被认为是软件工程一个令人惊讶的成就。在Windows 1.0中,PC硬件结构的640KB内存限制,在不要求任何额外内存的情况下被有效地扩展了。但Microsoft并未就此停步:Windows 2.0允许Windows应用程序存取扩充内存(EMS);Windows 3.0在保护模式下,允许Windows应用程序存取高达16MB的扩展内存。Windows NT和Windows 98通过成熟的32位操作系统及平坦寻址空间,摆脱了这些旧的限制。 Windows上执行的程序可共享在称为「动态链接库」的文件中的例程。Windows包括一个机制,能够在执行时连结使用动态链接库中例程的程序。Windows自身基本上就是一个动态链接库的集合。 Windows是一个图形接口,Windows程序能够在视讯显示器和打印机上充分利用图形和格式化文字。图形接口不仅在外观上更有吸引力,而且还能够让使用者传递高层次的信息。 Windows应用程序不能直接存取屏幕和打印机等图形显示设备硬件。相反,Windows提供一种图形程序语言(称作图形设备接口,或者GDI),使显示图形和格式化文字更容易。Windows虚拟化了显示硬件,使为Windows编写的程序可使用任何具有Windows设备驱动程序的视频卡或打印机,而程序无需确定系统相连的设备类型。 对Windows开发者来说,将与设备无关的图形接口输出到IBM PC上不是件轻松的事。PC的设计是基于开放式架构的原则,鼓励第三方硬件制造商为PC开发接口设备,而且开发了大量这样的设备。虽然出现了多种标准,PC上的传统MS-DOS程序仍不得不各自支持许多不同的硬设备。这对MS-DOS字处理软件来说非常普遍,它们连同1到2张有许多小文件的磁盘一同销售,每个文件支持一种特定的打印机Windows程序不要求每个应用程序都自行开发这些驱动程序,因为这种支持是Windows的一部分。 动态链接 Windows运作机制的核心是一个称作「动态链接」的概念。Windows提供了应用程序丰富的可呼叫函数,大多数用于实作其使用者接口和在视讯显示器上显示文字和图形。这些函数采用动态链接库(Dynamic Linking Library,DLL)的方式撰写。这些动态链接库是些具有.DLL或者有时是.EXE扩展名的文件,在Windows 98中通常位于\WINDOWS\SYSTEM子目录中,在Windows NT中通常位于\WINNT\SYSTEM和\WINNT\SYSTEM32子目录中。 在早期,Windows的主要部分仅通过三个动态链接库实作。这代表了Windows的三个主要子系统,它们被称作Kernel、User和GDI。当子系统的数目在Windows最近版本中增多时,大多数典型的Windows程序产生的函数呼叫仍对应到这三个模块之一。Kernel(日前由16位的KRNL386.EXE和32位的KERNEL32.DLL实现)处理所有在传统上由操作系统核心处理的事务-内存管理、文件I/O和多任务管理。User(由16位的USER.EXE和32位的USER32.DLL实作)指使用者接口,实作所有窗口运作机制。GDI(由16位的GDI.EXE和32位的GDI32.DLL实作)是一个图形设备接口,允许程序在屏幕和打印机上显示文字和图形。 Windows 98支持应用程序可使用的上千种函数呼叫。每个函数都有一个描述名称,例如CreateWindow。该函数(如您所猜想的)为程序建立新窗口。所有应用程序可以使用的Windows函数都在表头文件里预先声明过。 在Windows程序中,使用Windows函数的方式通常与使用如strlen等C语言链接库函数的方式相同。主要的区别在于C语言链接库函数的机械码连结到您的程序代码中,而Windows函数的程序代码在您程序执行文件外的DLL中。 当您执行Windows程序时,它通过一个称作「动态链接」的过程与Windows相接。一个Windows的.EXE文件中有使用到的不同动态链接库的参考数据,所使用的函数即在那些动态链接库中。当Windows程序被加载到内存中时,程序中的呼叫被指向DLL函数的入口。如果该DLL不在内存中,就把它加载到内存中。 当您连结Windows程序以产生一个可执行文件时,您必须连结程序开发环境提供的特定「引用链接库(import library)」。这些引用链接库包含了动态链接库名称和所有Windows函数呼叫的引用信息。连结程序使用该信息在.EXE文件中建立一个表格,在加载程序时,Windows使用它将呼叫转换为Windows函数。 WINDOWS程序设计选项 为说明Windows程序设计的多种技术,本书提供了许多范例程序。这些程序使用C语言撰写并原原本本的使用Windows API来开发程序。我将这种方法称作「古典」Windows程序设计。这是我们在1985年为Windows 1.0写程序的方法,它今天仍是写作Windows程序的有效方法。 API和内存模式 对于程序写作者来说,操作系统是由本身的API定义的。API包含了所有应用程序能够使用的操作系统函数呼叫,同时包含了相关的数据型态和结构。在Windows中,API还意味着一个特殊的程序架构,我们将在每章的开头进行研究。 一般而言,Windows APIWindows 1.0以来一直保持一致,没什么重大改变。具有Windows 98程序写作经验的Windows程序写作者会对Windows 1.0程序的原始码感觉非常熟悉。API改变的一种方式是进行增强。Windows 1.0支持不到450个函数呼叫,现在已有了上千种函数呼叫。 Windows API和它的语法的最大变化来自于从16位架构向32位架构转化的过程中。Windows从版本1.0到版本3.1使用16位Intel 8086、8088、和286微处理器上所谓的分段内存模式,由于兼容性的原因,从386开始的32位Intel微处理器也支持该模式。在这种模式下,微处理器缓存器的大小为16位,因此C的int数据型态也是16位宽。在分段内存模式下,内存地址由两个部分组成-一个16位段(segment)指针和一个16位偏移量(offset)指标。从程序写作者的角度看,这非常凌乱并带来了long或far指针(包括段地址和偏移量地址)和short或near指标(包括带有假定段地址的偏移量地址)的区别。 从Windows NT和Windows 95开始,Windows支持使用Intel 386、486和Pentium处理器32位模式下的32位平坦寻址内存模式。C语言的int数据型态也扩展为32位的值。为32位版本Windows编写的程序使用简单的平坦线性空间寻址的32位指针值。 用于16位版本WindowsAPIWindows 1.0到Windows 3.1)现在称作Win16。用于32位版本WindowsAPIWindows 95、Windows 98和所有版本的Windows NT)现在称作Win32。许多函数呼叫在从Win16到Win32的转变中保持相同,但有些需要增强。例如,图像坐标点由Win16中的16位值变为Win32中的32位值。此外,某些Win16函数呼叫返回一个包含在32位整数值中的二维坐标点。这在Win32中不可能,因此增加的新函数呼叫以不同方式运作。 所有32位版本的Windows都支持Win16 API(以确保和旧有应用程序兼容)和Win32 API(以运行新应用程序)。非常有趣的是,Windows NT与Windows 95及Windows 98的工作方式不同。在Windows NT中,Win16函数呼叫通过一个转换层被转化为Win32函数呼叫,然后被操作系统处理。在Windows 95和Windows 98中,该操作正相反:Win32函数呼叫通过转换层转换为Win16函数呼叫,再由操作系统处理。 在同一时刻有两个不同的Windows API集(至少名称不同)。Win32s (「s」代表「subset(子集)」)是一个API,允许程序写作者编写在Windows 3.1上执行的32位应用程序。该API仅支持已被Win16支持的32位函数版本。此外,Windows 95 API一度被称作Win32c(「c」代表「compatibility(兼容性)」),但该术语已被抛弃了。 现在,Windows NT和Windows 98都被认为能够支持Win32 API。然而,每个操作系统依然都支持某些不被别的操作系统支持的某些功能特性。因为它们的相同之处是相当可观的,所以有可能编写在两个操作系统下都可执行的程序。而且,人们普遍认为这两个产品最终会合而为一。 语言选项 使用C语言和原始的API不是编写Windows 98程序的唯一方法。然而,这种方法却提供给您最佳的性能、最强大的功能和在发掘Windows特性方面最大的灵活性。可执行文件相对较小且运行时不要求外部链接库(自然,Windows DLL自身除外)。最重要的是,不管您最终以什么方式开发Windows应用程序,熟悉API会使您对Windows内部有更深入的了解。 虽然我认为学习古典的Windows程序设计对任何Windows程序写作者都是重要的,我没有必要建议使用C和API编写每个Windows应用程序。许多程序写作者,特别是那些为公司内部开发程序或在家编写娱乐程序的程序写作者喜欢轻松的开发环境,例如Microsoft Visual Basic或者Borland Delphi(它结合了对象导向的Pascal版本)。这些环境使程序写作者将精力集中于应用程序的使用者接口和相关使用者接口对象的程序代码上。要学习Visual Basic,您也许需要参考Microsoft Press的一些其它图书,例如Michael Halvorson1996年着的《Learn Visual Basic Now》。 在专业程序写作者中-特别是那些开发商业应用程序的程序写作者-Microsoft Visual C++和Microsoft Foundation Class Library(MFC)是近年来流行的选择。MFC在一组C++对象类别中封装了许多Windows程序设计中的琐碎细节。Jeff Prosise的《Programming Windows with MFC,第二版》(Microsoft Press,1999年)提供了MFC程序的写作指南。 最近,Internet和World Wide Web的流行大力推广着Sun Microsystems的Java,这是一个受C++启发却与微处理器无关的程序设计语言,而且结合了可在几个操作系统平台上执行的图形应用程序开发工具组。Microsoft Press有一本关于Microsoft J++(Microsoft的Java)开发工具的好书,《Programming Visual J++ 6.0》(1998年),由Stephen R. Davis着。 显然,很难说哪种方法更有利于开发Windows应用程序。更主要的是,也许是应用程序自身的特性决定了所使用的工具。不管您最后实际上使用什么工具写作程序,学习Windows API将使您更深入地了解Windows工作的方式。Windows是一个复杂的系统,在API上增加一个程序写作层并未减少它的复杂性,仅仅是掩盖了它,早晚您会碰到它。了解API会给您更好的补救机会。 在原始的Windows API之上的任何软件层都必定将您限制在全部功能的一个子集内。您也许发现,例如,使用Visual Basic编写应用程序非常理想,然而它不允许您做一个或两个很简单的基本工作。在这种情况下,您将不得不使用原始的API呼叫。API定义了作为Windows程序写作者所需的一切。没有什么方法比直接使用API更万能的了。 MFC尤其问题百出。虽然它大幅简化了某些工作(例如OLE),我却经常发现要让它们按我所想的去工作时,会在其它特性(例如Document/View架构)上碰壁。MFC还不是Windows程序设计者所追求的灵丹妙药,很少有人认为它是一个好的对象导向设计的模型。MFC程序写作者从他们使用的对象类别定义如何工作中受益颇深,并会发现他们经常参考MFC原始码,搞懂这些原始码是学习Windows API的好处之一。 程序开发环境 在本书中,假定您正使用Microsoft Visual C++ 6.0,标准版、专业版和企业版都可以。经济的标准版足以应付本书中的程序设计需求。Visual C++ 还是Visual Studio 6.0中的一部分。 Microsoft Visual C++ 软件包中包括C编译器和其它编译及连结Windows程序所需的文件和工具等。它还包括Visual C++ Developer Studio,一个可编辑原始码、以交谈方式建立资源(如图标和对话框)以及编辑、编译、执行和测试程序的环境。 如果您正使用Visual C++ 5.0,则需要为Windows 98和Windows NT 5.0更新表头文件和引用链接库,这些东西可从Microsoft的网站上得到。在 http://www.microsoft.com/msdn/,选择「Downloads」,然后选择「 Platform SDK」(软件开发套件),您就能在选择的目录中下载和安装更新文件。要让Microsoft Developer Studio浏览这些目录,可以从「Tool」菜单项选择「 Options」然后按下「Directories」标签。 Microsoft网站上的msdn部分代表「Microsoft Developer Network(Microsoft软件开发者网络)」。这是一个向程序写作者提供了经常更新的CD-ROM的计划,这些CD-ROM中包含了程序写作者在Windows开发中所需的最新东西。您也可以订阅MSDN,这样就避免经常得从Microsoft的网站下载文件。 API文件 本书不是Windows API权威的正式文件的替代品。那组文件不再以印刷形式出版,它仅能从CD-ROM或Internet上取得。 当您安装Visual C++ 6.0时,您将得到一个包括API文件的在线求助系统。您可通过订阅MSDN或使用Microsoft网站上的在线求助系统更新该文件。连接到 http://www.microsoft.com/msdn/,并选择「MSDN Library Online」。 在Visual C++ 6.0中,从「Help」菜单项选择「Contents」项目开启MSDN窗口。API文件按树形结构组织,寻找标有「 Platform SDK」的部分,所有在本书中引用的文件都来自于该部分。我将向您介绍如何从「 Platform SDK」开始寻找以斜线分层分门别类的文件的位置。(我知道「Platform SDK」是整个MSDN知识库中较为晦涩的部分,但我敢保证那是Windows程序设计的基本核心。)例如,对于如何在Windows程序中使用鼠标的文件,您可参考/ Platform SDK / User Interface Services / User Input / Mouse Input。 我在前面提到Windows大致分为Kernel、User和GDI子系统。kernel接口在/ Platform SDK / Windows Base Services中,User界面函数在 / Platform SDK / User Interface Services中,GDI位于 / Platform SDK / Graphics and Multimedia Services / GDI中。 编写第一个WINDOWS程序 现在是开始写些程序的时候了。为了便于对比,让我们以一个非常短的Windows程序和一个简短的文字模式程序开始。这会帮助我们找到使用开发环境并感受建立和编译程序机制的正确方向。 文字模式(Character-Mode)模型 程序写作者们喜爱的一本书是《The C Programming Language》(Prentice Hall,1978年和1988年),由Brian W. Kernighan和Dennis M. Ritchie(亲切地称为K&R)编着。该书的第一章以一个显示「hello, world」的C语言程序开始。 这里是在《The C Programming Language》第一版第6页中出现的程序: main () { printf ("hello, world\n") ; } 以前C程序写作者在使用printf等C执行期链接库函数时,无需先声明它们。但这是90年代,我们愿意给编译器一个在我们的程序中标出错误的机会。这里是在K&R第二版中修正的程序: #include <stdio.h> main () { printf ("hello, world\n") ; } 该程序仍然是那么短。但它可通过编译并执行得很好,但当今许多程序写作者更愿意清楚地说明main函数的返回值,在这种情况下ANSI C规定该函数必须返回一个值: #include <stdio.h> int main () { printf ("hello, world\n") ; return 0 ; } 我们还可以包括main的参数,把程序弄得更长一些,但让我们暂且这样就好了-包括一个include声明、程序的进入点、一个对执行期链接库函数的呼叫和一个return语句。 同样效果的Windows程序 Windows关于「hello, world」程序的等价程序有和文字模式版本完全相同的组件。它有一个include声明、一个程序进入点、一个函数呼叫和一个return语句。下面便是该程序: /*------------------------------------------------------------------ HelloMsg.c -- Displays "Hello, Windows 98!" in a message box (c) Charles Petzold, 1998 --------------------------------------------------------------------*/ #include <windows.h> int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) { MessageBox (NULL, TEXT ("Hello, Windows 98!"), TEXT ("HelloMsg"), 0); return 0 ; } 在剖析该程序之前,让我们看一下在Visual C++ Developer Studio中建立新程序的方式。 首先,从File菜单中选New。在 New对话框中,单击Projects页面标签,选择 Win32 Application。在Location栏中,选择一个子目录,在 Project Name栏中,输入该项目的名称,此时该名称是HelloMsg,这便是在 Location栏中显示的目录的子目录。Create New Workspace复选框应该勾起来,Platforms部分应该显示 Win32,选择OK。 将会出现一个标题为Win32 Application - Step 1 Of 1的对话框,指出要建立一个Empty Project,并按下Finish按钮。 从File菜单中再次选择New。在 New对话框中,选择Files页面标签,选择 C++ Source File。Add To Project复选框应被选中,并应显示HelloMsg。在 File Name栏中输入HelloMsg.c,选中OK。 现在您可输入上面所示的HELLOMSG.C文件,您也可以选择Insert菜单和 File As Text选项从本书附带的CD-ROM上复制HELLOMSG.C的内容。 从结构上说,HELLOMSG.C与K&R的「hello,world」程序是相同的。表头文件STDIO.H已被WINDOWS.H所代替,进入点main被WinMain所代替,而且C语言执行时期链接库函数printf被Windows API函数MessageBox所代替。然而,在程序中有许多新东西,包括几个陌生的大写标识符。 让我们从头开始。 表头文件 HELLOMSG.C以一个前置处理器指示命令开始,实际上在每个用C编写的Windows程序的开头都可看到:
前言 从Windows出现开始,汇编语言似乎在慢慢地销声匿迹,但本书可以让人放弃这个观点,其实在Win32环境下,汇编语言依然强大。 Why——为什么选择Win32汇编 选择Win32汇编的理由是什么呢? 在DOS时代,学习汇编就是学习系统底层编程的代名词,仅要成为一名入门级的汇编程序员,就需要学习从CPU结构、CPU工作方式、各种硬件的编程方法到DOS工作方式等范围很广的知识。随着Windows时代的到来,Windows像一堵巨大的墙,把我们和计算机的硬件隔离开。对于DOS的汇编程序员来说,就像在一夜之间,我们发现自己曾经学过的几乎所有的东西都被Windows封装到内核中去了,由于保护模式的存在,我们又无法像在DOS下那样闯入系统内核为所欲为。在Windows下用任何语言编程都必须遵循Windows的规范,汇编也不例外,也就是说,汇编不再是一种“有特权”的语言。面对汹涌而来的Visual C++,Visual Basic,PowerBuilder和Java等各个领域的猛将,从DOS时代“为所欲为”的“系统警察”岗位下岗,在其他领域又没有一技之长,汇编语言似乎失去了生存的意义,有很多人在DOS转向Windows的时候放弃了汇编语言。 但是经过短暂的失落,摆正了自己在系统中的位置,我们发现从“系统警察”转换到遵循Windows规范的“好市民”后,汇编语言又慢慢地在这个世界流行起来了。毕竟,不能为所欲为也可以有好的一面,我们可以不必再考虑一些老大难的问题,如程序运行时会面对什么样的显示卡,如何驱动不同的打印机,内存不够了如何用磁盘交换,等等。我们也可以在了解更少硬件知识的情况下就可以掌握Win32的汇编编程。而且,我们惊喜地发现,做了“好市民”以后,我们反而拥有了和其他语言同样的权利——为了做图形和界面等方面的功能,汇编程序员在DOS时代连做梦都在羡慕C语言庞大的函数库,而现在,Windows为我们提供了比这还要多得多的函数,以至于其他大部分语言可以做出来的功能,汇编都可以做,而其他语言做不到的功能,汇编照样可以做!所以这就是理由之一:Win32汇编可以当做一种功能强大的开发语言使用,使用它完全可以开发出大型的软件来。 正因为Win32汇编看上去不再那样低级,于是有读者曾经提出:Win32汇编讲的都是用API来写程序,和高级语言差不多,以前在DOS下使用的中断什么的都不能用,所以没有什么新奇的了。还有读者认为本书只不过是MSDN的汇编版本而已。言下之意就是:学汇编就是为了了解高级语言底下一层的功能,但现在Win32汇编却使用和C++等语言相同的API接口,既然和高级语言处于同一个级别,我们为什么还要去和机器指令打交道呢,还不如去学Visual C++方便。 但是我们可以这样问一问自己: 问:在DOS汇编中我们为什么用中断功能? 答:为了使用DOS内核提供的功能。 问:在DOS中我们常常自己用操作I/O端口的方法读写硬盘或操作显卡吗? 答:不,我们用系统提供的int 13h和int 10h。 …… 同样,在Win32汇编里使用API也是为了使用Windows内核提供的功能。只不过使用的方式不再是中断方式而已,这不是Win32汇编语言“高级化”了,而是高级语言因为使用WindowsAPI接口而“低级化”了,其代价就是无法移植到其他系统,用Visual C++写的程序是无法移植到其他操作系统平台上的,只有和平台无关的ANSI C++等才能算是真正意义上的高级语言。 其实,任何汇编语言都是和操作系统密切相关的,不管是DOS汇编、Win32汇编,还是Linux汇编,都是基于特定的操作系统的,如果一定要绕过操作系统,那么就不会有DOS汇编和Win32汇编的区别了,但是这样的话我们不是在学汇编,而是在自己开发操作系统。高级语言在不同的操作系统上看起来都差不多,但作为一种低级语言,不同操作系统上的汇编就是不同的世界。所以,既然Windows和DOS是两个完全不同的操作系统,我们就必须抛弃DOS汇编中的大部分概念从头开始学习Win32汇编。这就是理由之二:Win32汇编是Windows环境下一种全新的编程语言。 Win32环境下的很多高级语言,如Visual C++和Visual Basic等,一如既往地对实现的细节进行了或深或浅的封装,就连最能表现Windows特征的部分,如消息循环和多线程的处理等内容也都被隐藏封装,使我们在使用它们进行可视化编程的同时,无法全面了解Win32程序运行的具体方式。在学习Win32汇编以后,这些隐藏在高级语言后面的细节就暴露出来了。 由于封装的关系,各种高级语言或多或少存在某种“缺陷”,比如VB不支持指针,结果很多需要使用指针的API用起来就很不方便,像多线程一类的特征在VB中就无法实现,PowerBuilder也是如此;C语言已经是最灵活的高级语言了,但还是无法在代码级别处理某些需求;而汇编语言见到的是一个最真实的操作系统,它可以用最灵活的方式使用各种系统功能,第13章中有关进程隐藏的内容就是最好的写照。所以理由之三就是:使用Win32汇编语言是了解操作系统运行细节的最佳方式。 最后的理由根本不是理由,而是必然的选择,当我们在Windows环境下进行加密解密、逆向工程,还有病毒、木马等有害代码的分析和防治工作时,Win32汇编是唯一的选择。在任何讨论这方面内容的书籍中,汇编代码的篇幅总是很大的。因此,要想深入了解这些内容的前提就是深入汇编编程。 How——如何学习Win32汇编 以往的汇编书籍往往把重点放在硬件结构和指令上,讲述了一大堆电路框图和指令列表,把大家搞得晕晕乎乎后,再举出一些重量级的例子,不是一些像数组、矩阵计算一类的复杂运算,就是开始图形模式画图,以至于大家看完以后就再也找不到北了!实际上,这些例子不是太难了,而是太枯燥了。有人说,学汇编就像考大学,千军万马过独木桥,太多的人中途放弃了,只有少数人坚持到最后。 笔者认为:学习汇编应该在轻松的环境下进行,在学习中使用的例子不一定太复杂,但一定要有吸引力。用汇编写复杂的运算程序固然会比C更有效率,但同样的事在C中用一个表达式就全部搞定了,从这里开始学汇编,给人的感觉就像从复杂的公式开始学算术,要知道,加法还没有学会呢!而对于高级语言封装起来的系统功能,用汇编解释起来就非常直接,非常自然,也更容易懂。以笔者自己学汇编的过程来说,那时候是1990年,刚好是中国第一次病毒大流行,大家的计算机上都是那个病毒的开山鼻祖——乒乓病毒,在流行DOS的时期,看着在屏幕上蹦的小球,心中就有一个问题:如何编出这样一个玩意来呢?要知道DOS是单任务的,而那个球在别的程序运行的时候照样蹦!这用当时流行的FORTRAN、C等课程中学到的任何知识都无法解释,因为这些课程中不可能有TSR、中断、引导区等内容。带着这样一个疑问学习汇编,在分析乒乓病毒的过程中啃一条条不懂的指令,病毒分析完了,汇编课也学完了,而且反过来看那些复杂的计算程序都是那么顺理成章,不攻自破了。实际上,从一些实用的系统功能开始学习汇编远比学矩阵计算容易理解。 正如最经典的C程序就是那个“Hello,World!”一样,这个程序的有名并不是因为它用高深复杂的语句放倒了一大批人,而是它以最简单易懂的方式让人们走入C语言的大门。对于Win32汇编也是如此,从最简单的例子开始总是没错的,笔者建议读者跟随本书中从简到繁的例子,努力做到理解并灵活引用这些例子中的各种功能,正如“熟读唐诗三百首,不会写诗也会吟”,最后能够熟练地使用Win32汇编来解决各种编程需求就是最大的胜利。 另外,正如前面讲到的,汇编语言的学习必须和操作系统紧密结合。经过简单的调查,笔者发现很多高校使用的汇编教程还是停留在清华91版《IBM-PC汇编语言程序设计》之类的教材上,虽然这些教材中基础知识部分永远不会过时,但涉及操作系统的部分还是停留在DOS阶段。随着DOS操作系统的悄然引退,继续把精力花在上面是一种浪费,因为任何语言都必须有应用的平台,否则课程学完之后会尴尬地发现没有地方可以应用。笔者认为,在《IBM-PC汇编语言程序设计》之类传统教材中的基础部分学习完毕以后,重点就应该转向Win32汇编,以及保护模式方面的知识。 关于本书的内容 本书尝试从编写应用程序的角度,从“Hello,World”这个简单的例子开始到编写多线程、注册表和网络通信等复杂的程序,通过70多个从简单到复杂的例子,逐步深入Win32汇编编程的方方面面。笔者从事汇编编程已经有十几年的历史了,从8086时代的DOS汇编编程开始到当前的Win32汇编编程,从一个初学者到现在能利用Win32汇编来解决大部分编程需求,中间也经过了很长时间的摸索和大量的挫折,所以笔者很清楚初学者在哪些地方会遇到问题,但是涉及Win32汇编的书籍却实在太少了。正是因为如此,笔者决心把本书的目标定为:能让读者入门并在最后能熟练掌握Win32汇编编程,而不是那种深入系统奥秘一类的书籍。 从这个目标出发,本书的选材中尽量去掉已经有其他书籍详细讨论的部分,因为要一本书涉及全部方面是不现实的。内容全面就必然不精,内容深刻就必须围绕一个中心点,所以本书的内容并不详细讨论一般汇编教材的基础部分,如处理器结构和保护模式等,也不准备涉及Windows驱动程序、COM编程或者其他能够冠以“密技”头衔的内容。本书主要的内容将放在32位宏汇编对比DOS汇编所不同的部分,以及Win32应用程序的汇编实现上。不求全面,只求精也!(说句老实话,也不敢对自己不精通的地方妄加评论,以免破坏自己的良好形象。
axios是一个基于Promise的HTTP客户端,用于发送HTTP请求。这里是一个简单的axios API封装示例: ```javascript import axios from 'axios'; // 创建一个axios实例 const instance = axios.create({ baseURL: 'http://api.example.com', // 设置基础URL timeout: 5000, // 请求超时时间 }); // 封装get请求 export function get(url, params) { return new Promise((resolve, reject) => { instance .get(url, { params }) .then(response => { resolve(response.data); }) .catch(error => { reject(error); }); }); } // 封装post请求 export function post(url, data) { return new Promise((resolve, reject) => { instance .post(url, data) .then(response => { resolve(response.data); }) .catch(error => { reject(error); }); }); } ``` 这个示例中,首先通过`axios.create`方法创建了一个axios实例,可以设置一些默认的配置参数,比如baseURL和timeout。 然后,我们封装了两个常用的请求方法:`get`和`post`。在这些封装的方法中,我们通过调用axios实例的对应方法来发送请求,并返回一个Promise对象。 这样,在其他地方使用封装好的axios API时,可以更加简洁地进行请求操作。例如: ```javascript import { get, post } from './api'; get('/users', { page: 1, limit: 10 }) .then(data => { console.log(data); }) .catch(error => { console.error(error); }); post('/login', { username: 'admin', password: '123456' }) .then(data => { console.log(data); }) .catch(error => { console.error(error); }); ``` 这样做的好处是,可以在项目中统一处理请求的配置和错误处理,提高代码的可维护性和复用性。同时,也方便了后续对axios的升级和配置调整。当然,具体的封装方式还可以根据实际需要进行更多的扩展和优化。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值