`

[回溯本源] Unix Fork和Windows CreateProcess可以比较吗?

阅读更多
进程是现代操作系统的一个最基本的概念。书本上说:进程是一个具有独立功能的程序关于某个数据集合的一次运行活动。它可以申请和拥有系统资源,是一个动态的概念,是一个活动的实体。它不只是程序的代码,还包括当前的活动,通过程序计数器的值和处理寄存器的内容来表示。

详细点说:进程的概念主要有两点:

第一,进程是一个实体。每一个进程都有它自己的地址空间,一般情况下,包括文本区域(text region)、数据区域(data region)和堆栈(stack region)。文本区域存储处理器执行的代码;数据区域存储变量和进程执行期间使用的动态分配的内存;堆栈区域存储着活动过程调用的指令和本地变量。

第二,进程是一个“执行中的程序”。程序是一个没有生命的实体,只有处理器赋予程序生命时,它才能成为一个活动的实体,我们称其为进程。

在Unix系统中,我们通常用fork来创建一个进程,相应的,在Windows操作系统里,我们用的是CreateProcess,一些对两个平台不熟悉的程序员,常常误以为二者是等同的,并得出了诸如在Windows创建进程比在Unix慢许多等错误结论。

fork时发生了什么?
当fork()系统调用发生时,子进程会拷贝其父进程的所有页面,并将其加载入操作系统为它分配的一片独立内存中。这些拷贝的动作很消耗时间,而且在某些情况下并不需要这么做。如果子进程马上执行了"exec"系统调用(用来执行任何可执行文件)或者Fork()之后就退出进程,拷贝父进程的页面就很不划算,因为exec后包括代码段,数据段和堆栈等都已经被新的内容取代,只留下进程ID等一些表面上的信息仍保持原样,而如果fork完之后我们马上就调用exec,这些辛辛苦苦拷贝来的东西又会被立刻抹掉。

在这种情况下,一种叫copy-on-write (随拷随写)(COW)的技术被采用了,当fork发生时,父进程的页面并没有被拷贝到子进程中,相反,这些页面被父进程和子进程所共享。无论父子进程中谁要去修改页面,系统就为该进程拷贝一个独立的特定页面,然后再对其进行修改。该进程以后就只使用这个新拷贝的页面而不再是共享的那个,而别的进程则继续使用共享的页面。这项技术就叫随拷随写,因为当有进程要写页面的时候,就需要先拷贝页面。

采用了COW技术,Fork时,子进程只需要拷贝父进程的页面表就可以了。产生这种设计是因为有时兼容POSIX的操作系统在Fork之后,并不需要执行Exec,比如apache Web Server就因此而受益,这时候的fork让你想起点什么?恩,有点接近Windows的CreateThread。

socket_accept()
fork()
if (child)
    handleRequest()
else
    goOnBeeingParent()


COW技术使得创建子进程的代价小了许多,但是现实情况下,很多时候Fork会紧跟着一个EXEC,因为Exec必须装载所有的映像,unix还是得花很大的代价来创建一个进程。

阐述到这里,比较公平的比较是 Fork近似于NtCreateThread 而CreateProcess 近似于 fork + execve.

这里为什么说比较公平而已,因为还有别的因素我们还未涉及。

相对于Unix,Windows的设计更有弹性,它是一个多层次的而且更加组件化的操作系统,Windows拥有许多子系统,我们通常说的Windows,只是它的子系统之一,称为WoW(Windows On Windows),其他子系统还包括Wow64,Posix和OS2。 Windows NT内核也支持COW fork,但是只为SFU(Microsoft's UNIX environment for Windows)所使用,SFU进程和Win32进程是不同的东西。

回到Win32的进程创建上来,你会发现Windows为Win32进程创建的过程添加了许多枝节。首先,它需要通知CSRSS进程被创建,CSRSS又调用了LPC,而它要求至少kernel32(NTDll.dll)等动态库要被加载,然后它又要处理许多预保留的工作项目,之后该进程才能被认为是一个Win32进程,之后还有许多枝节要去处理比如解析manifests,程序兼容性检查,程序的限制策略等等等等,这些附加在原始进程创建过程之后枝节,无疑拖累了进程创建速度。

这些巴拉巴拉的事情,让我想起了struts,一个又一个filter被插入一次http request之后。

MS提供了一个组策略可以禁用兼容性检查,这样可以大大提高进程的创建速度。此外Win32的运行库(kernel32.dll等等)还带来了大量注册表读操作和初始化。这些东西对 UNIX, SFU或者原生进程都是不存在的。

不带任何子系统的原生进程的创建速度是很快的,而创建SFU进程要比Win32进程简单得多,也快得多,尽管Win32花了许多力气在加载这些枝节之上,但是一方面,它提高了对客户的友好,另一方面,运行库的预加载使得图形界面的处理速度更快,或者Win32进程天生就是为图形处理做准备的。

运行在Windows里Unix Subsystem之上的XClock.



SFU不是unix仿真系统:


  • 大小: 61.7 KB
  • 大小: 21.8 KB
分享到:
评论
22 楼 ray_linn 2010-07-14  
seen 写道
mallon威武
大姨妈退散


我现在对javaeye已经连争论的兴趣都没有了。
21 楼 seen 2010-07-14  
mallon威武
大姨妈退散
20 楼 mathgl 2010-07-05  
rubynroll 写道
理论上“微内核”架构可以有更灵活的配置,系统可以更轻巧,更容易裁剪。

只是很不幸,臃肿的Windows设计糟蹋了“微内核”的声誉。

所谓过犹不及,过多的分层,过多的抽象,结果就是臃肿。

本应该是“笨重”的mono Linux内核,不仅运行效率高,而且借助Open Source的模式弥补了架构上的不足,反而博得“轻巧灵活”的好名声。

开发过Windows的驱动,也开发过Linux的驱动;感觉一个是地狱,一个是天堂。

体系结构自然有高低,但更重要的是看怎么实践。


windows驱动 早期的VxD确实是噩梦。。不过现在好上许多了...
19 楼 rubynroll 2010-07-04  
理论上“微内核”架构可以有更灵活的配置,系统可以更轻巧,更容易裁剪。

只是很不幸,臃肿的Windows设计糟蹋了“微内核”的声誉。

所谓过犹不及,过多的分层,过多的抽象,结果就是臃肿。

本应该是“笨重”的mono Linux内核,不仅运行效率高,而且借助Open Source的模式弥补了架构上的不足,反而博得“轻巧灵活”的好名声。

开发过Windows的驱动,也开发过Linux的驱动;感觉一个是地狱,一个是天堂。

体系结构自然有高低,但更重要的是看怎么实践。
18 楼 mallon 2010-06-19  
对了我说你这句话“我们通常说的Windows,只是它的子系统之一,称为WoW(Windows On Windows)”是错的。

完整地用三句话讲(应该没有把柄了吧...)

1、“WOW”专指32位Windows NT系统上的16位Windows兼容层,你在32位系统里跑个16位的Windows程序,会在任务管理器中看到“ntvdm.exe”和“wowexec.exe”两个东东,就是这玩意儿;

2、“WOW64”专指64位Windows NT系统上的3位2Windows兼容层。

3、总结地讲,“WOW..”指的是XX位Windows NT系统上的YY位Windows兼容层,XX =/= YY,根本不可能有所谓的XX位Windows NT系统上的XX位子系统一说,其实英文单词“on”已经很清楚了,怎么可能自己“on”自己呢?就好像说“我是我儿子”一样可笑。
17 楼 mallon 2010-06-19  
第三,可能有些不准确。准确讲,NT时代的Microsoft POSIX subsystem、XP/2000时代的Microsoft Windows Services for UNIX (SFU)以及2003 R2/Vista/2008时代的Subsystem for UNIX-based Applications (SUA)都工作在用户态,都是围绕内核吃饭的“应用程序”,和CygWin没什么两样,不准确讲就是“Win32API的包装”了,呵呵

参见:
http://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem
http://en.wikipedia.org/wiki/Microsoft_Windows_Services_for_UNIX
http://en.wikipedia.org/wiki/Subsystem_for_UNIX-based_Applications
还有参见你自己贴出来的图。

可能你会说:NFS不是在内核里面吗?我反驳道:NFS是Windows自带的吗?还不是之后像装软件一样装上去的。可能你又会说,类似IIS一样虽然是之后装的,但也属于Windows的一部分啊,IIS的http.sys也工作在内核态呢...这我就说不清了,到底打上Microsoft商标的软件装上去就可以看作操作系统的一部分,还是不能这样看呢?运行在内核态的程序(NFS、http.sys、设备驱动...)算不算做内核的一部分呢?要选地球作为参照系的话,太阳都是绕着地球转的呢...

不谦虚地讲,我的能耐也只到这里为止了,让我再拿出更加深入的证据和你辩论确实无能为力,也不想自寻烦恼,呵呵。微软的东西早让我疲惫不堪了,那些广告似的体系结构图、花哨的命名和句子等也不足以让我意淫,所以你也得拿点更深入的东西才能让我信服。但是我估计很难,Windows内核源代码毕竟是不公开的,Hack再深入还是Hack,上不了正道的。

当然了,Windows很多地方也是相当成功的,比如Win95之后焕然一新、引领潮流的桌面风格;还有NT内核里的对象结构,设计得非常精美,“一切皆对象”和Unix里的“一切皆文件”如出一辙,可惜还是那句老话,历史包袱太重,往上层越包装越丑陋(举个例子:文件路径)
16 楼 mallon 2010-06-19  
其二,Windows的OpenGL就是DirectX的Wrapper。你在Windows下面用OpenGL编程,肯定得链接opengl32.lib库,而opengl32.lib肯定是链到opengl32.dll上。

然后,引述:
http://www.opengl.org/wiki/Getting_started#Windows
http://bbs.games.sina.com.cn/thread-186836-1-1.html
Windows下的OpenGL默认实现(上面讲了,也就是opengl32.dll)在Win98、ME、2000下是纯粹软件实现的,支持到OpenGL 1.1,Windows XP下是Direct3D的包装,支持到OpenGL 1.1,Windows Vista以上也是Direct3D的包装,支持到OpenGL 1.4,如果安装了驱动,那么opengl32.dll会转到驱动提供的dll(前提是如果有的话),由驱动提供的dll调用底层的驱动实现,微软说“关我鸟事,我给你开个门,你厂商爱怎么折腾怎么折腾去”呵呵。
15 楼 mallon 2010-06-19  
我的语文确实很差劲,只能尽力把意思表达清楚吧。

微内核只提供最基本的系统服务,而把其他服务独立出去,指的是功能上的“微”而不是体积上的“微”,模块之间按理讲应该是结构清晰的,但是Windows确是藕断丝连,比如,你能用Windows微内核(这里咬文嚼字一下,Windows内核也并不是完全意义上的“微”,省得又被你抓住什么把柄)加上一些基本的服务,启动一个简单的字符模式的Shell吗?可能你会说可以,“故障恢复控制台”不是典型的例子吗?但是你能在“故障恢复控制台”下面启动系统服务、打开网络吗?藕断丝连的问题出来了吧。可能你会讲,要微软下点功夫改改肯定行的,问题是任何东西“改改”总能实现的,只是难度不同而已,呵呵。

所以第一个问题我的观点是:Windows从内核到上层应用,各个模块之间的耦合是紧凑而且错综复杂的,以至于很难(咬文嚼字一下,差点用了“不可能”这个词而留下把柄,呵呵)用单独一两个模块不拖泥带水地完成某些看似简单的功能。
14 楼 ray_linn 2010-06-19  
mallon 写道

再举个例子,Windows内核再“微”,用PE、Embedded裁减再小也得几十兆,图形界面是肯定得带的,而且随便加一个程序,比如“记事本”、“任务管理器”都得伤筋动骨的,依赖性太强了,记事本的“打开”对话框依赖的是Shell的一整套结构,看看Server 2008 Core里的记事本,“打开”对话框是不是很简陋?微软有源代码,所以他能够“巧妙地”解决一些问题,而我们不能。


你莫非认为微内核=微小的内核?Micro Kernel=Small Kernel? 哪些东西是内核的,那些不是内核的,麻烦回去翻翻书。

你想阐明个什么道理呢?除了带非所问的太极推手之外。能不能老老实实回到最初的地方

OpenGl不是简单Wrap了DirectX?
Posix子系统是不是简单Wrapp了Win32API?


这些观点是不是全是误导人民群众?
13 楼 ray_linn 2010-06-19  
mallon 写道
七猫说的还是很有道理的,我承认很多东西没有深入研究过,但是ray你说“OpenGL32.dll提供了多少个API: 368个,1:368,果然是一叶障目啊,你还真奸猾,真能扯淡”我真要笑了,提醒你一下吧,DirectX走的是COM架构,而COM里申请对象一个函数足矣...

反正Windows也就这样了,新的技术出啊出啊出啊...程序员学啊学啊学啊...活到老学到老,呵呵



申请对象一个函数足矣,但用了其中多少个函数呢?如此证据不足的东西能作为理论依据,我算服了。
12 楼 mallon 2010-06-19  
再继续举例子,看看微软的上层设计,从OLE到COM到DCOM到COM+,微软用C++搭建了一套完整的分布式体系结构的大厦,但是这座大厦确是建筑在C++的沙地上的,最后呢,和同时期同样建筑在C++之上的CORBA一样轰然倒塌。当然很多人会驳斥说C++是好的不是坏的,确实我以前也是这样想的,从哲学上讲任何东西只要不坏都是好的,但是有没有想过和更好的东西比较一下呢?用COM、CORBA编写大型软件,写得吐血,改得便血的时候,有没有想到解放一下自己呢?

没想到?微软倒是想到了,于是模仿Java的基于虚拟机架构的.NET出来了,微软很聪明,从来不讲自己这套东西是基于虚拟机的,而是用一个很学术化的名次“CLR”,说.NET程序是“托管”的,乍一听好像是一套很高明的函数库或者类库,看起来也像,所有.NET程序都链接到了mscoree.dll上,于是乎一大帮“半瓶子水”又开始样样自得起来,以为又学到了什么“博大精深”的东西了。

.NET架构确实做得不错,但是微软是一家商业公司,历史的包袱不得不背,“兼容”“兼容”“兼容”...越做越大,而且真正用起来,稀奇古怪的问题层出不穷,光看帮助没GOOGLE还真搞不定...

微软以前的程序员还是很厉害的,但是这些年新招的程序员貌似是越来越烂了,举个例子,安装SQL Server 2008,那个安装程序一个又一个不同风格不同款式对话框弹出来,有些大字体有些小字体,有些按钮文本款歪在一边,甚至C#图形程序默认的图标都没改,估计是临时工做的吧,笑死...
11 楼 mallon 2010-06-19  
可能有些地方大家都说得不精确,以至于看似观点截然相反,事实上讨论的完全不是一个东西。

确实Windows的分层很清晰,这个我承认,至少从框架图上看是如此,但是一到实用场合就傻眼了,我是个实用主义者,所谓“不看广告看疗效”。

举个例子,写个获取CPU占用的程序,可以直接使用API、或者WMI、或者PDH,厉害点的直接用Native API,选哪个技术呢?用WMI,那早期的NT4上就跑不了了(除非装了WMI)、而且效率也是问题。

再举个例子,Windows内核再“微”,用PE、Embedded裁减再小也得几十兆,图形界面是肯定得带的,而且随便加一个程序,比如“记事本”、“任务管理器”都得伤筋动骨的,依赖性太强了,记事本的“打开”对话框依赖的是Shell的一整套结构,看看Server 2008 Core里的记事本,“打开”对话框是不是很简陋?微软有源代码,所以他能够“巧妙地”解决一些问题,而我们不能。
10 楼 mallon 2010-06-19  
七猫说的还是很有道理的,我承认很多东西没有深入研究过,但是ray你说“OpenGL32.dll提供了多少个API: 368个,1:368,果然是一叶障目啊,你还真奸猾,真能扯淡”我真要笑了,提醒你一下吧,DirectX走的是COM架构,而COM里申请对象一个函数足矣...

反正Windows也就这样了,新的技术出啊出啊出啊...程序员学啊学啊学啊...活到老学到老,呵呵
9 楼 七猫 2010-06-19  
单单从导入库来猜测有时候并不一定正确。

我虽然不能说对windows内核很熟悉,但windows的组件即使依赖性很强,也比linux要好些。
8 楼 七猫 2010-06-19  
不要很显然的就:opengl是directx的封装了。
7 楼 七猫 2010-06-19  
晕了,我贴一段opengl的吧,也是从网上copy的。
OpenGL硬件加速

  在Windows平台上,OpenGL驱动可能有三种模式:纯软件、MCD和ICD:

    *

      纯软件模式:微软提供一个OpenGL的软件实现,所有渲染操作均由CPU完成,速度很慢。如果安装系统时使用Windows自带的显卡驱动程序,那么 OpenGL程序就会运行在软件模式下。而且由于微软有自己的Direct3D,所以对OpenGL的支持很消极,它的OpenGL纯软件实现只支持 OpenGL1.1,而目前OpenGL的最新版本为1.4
    *

      MCD(Mini Client Driver):MCD是早期微软在Windows NT上支持OpenGL时,为了简化驱动开发时使用的一个模型。在这个模型中,OpenGL渲染管线的变换、光照部分仍然由软件实现,而光栅化部分则由硬件厂商实现,因此只要硬件支持,MCD可以硬件加速光栅化部分。MCD虽然可以简化驱动开发,但是功能限制太大,现在市面上的3D加速卡均支持硬件变换和光照,MCD却不能利用这一特性,看上去MCD已经没有存在的价值
    *

      ICD(Installable Client Driver):ICD是一个完整的OpenGL驱动模型,比MCD复杂得多。硬件厂商要实现完整的OpenGL渲染管线,如变换、光照、光栅化等,因此只要硬件支持,ICD可以硬件加速整个OpenGL渲染管线。我们通常说的OpenGL硬件加速就是指的通过ICD模型获得的硬件加速,而现在硬件厂商提供的OpenGL驱动程序也都是依照ICD模型开发的。主要硬件厂商的ICD已经可以支持OpenGL的最新版1.4

 

  Windows怎么实现OpenGL硬件加速呢?OpenGL32.dll是微软的OpenGL 1.1纯软件实现,我们的程序都要动态链接到这个 dll。如果安装3D芯片厂商的驱动程序,会将一个不同名字的dll放到Windows系统目录下,比如在Windows 2000下安装 nVIDIA GeForce2 MX的驱动程序,会在系统目录下放一个nvoglnt.dll(这就是nVIDIA的OpenGL驱动),并在注册表中登记nvoglnt.dll,让Windows知道硬件加速OpenGL驱动的名字,以后运行OpenGL程序,OpenGL32.dll就会把 OpenGL调用直接转到nvoglnt.dll。

 

    Windows平台上,一个OpenGL程序是否使用硬件加速由三个因素决定,这三个因素缺一不可,否则程序都会运行于纯软件模式:

    *

      是否有一块3D加速卡
    *

      是否安装了显卡厂商提供的最新的驱动程序,Windows自带的显卡驱动程序并不会提供 OpenGL硬件加速能力
    *

      指定的像素格式是否被显卡硬件所支持
6 楼 ray_linn 2010-06-19  
mallon 写道
WOW是WOW(专指16位环境),WOW64是WOW64,呵呵不玩文字游戏,我说那些子系统和OpenGL是API Wrap是有根据的,看图

很显然opengl32.dll调用的是ddraw.dll(至于第三方的OpenGL实现,例如SGI的,那就不得而知了),而psxdll.dll最终依赖的是ntdll.dll,众所周知ntdll.dll是用户态的最底层,但是并不是内核态的,微软不是傻子,能够依赖现有实现的,怎么会重来一次呢?

所谓微内核巨内核纯粹炒的是概念,微内核好在哪里?结构清晰合理?那结构清晰合理又得到了什么好处?Who cares?大多数时候关心的是整体架构设计,单单一个内核决定不了什么。

Windows确实层次多,但从来没有实现过真正的组件化,组件之间的依赖性是非常大的,上午还有事就不深入讲了吧,反正真正深入研究过Windows底层的都知道的。




第一、WOW很显然是你在玩文字游戏了。莫非我的写上WOW16,WOW64好骗取稿费?

第二、子系统和API有截然的不同,不要顾左右而言它。至于结构图,我已经贴在上面。我想你根本没玩过子系统。胡乱猜测而已。你也可以去dump一下posix.exe,依赖的win32 api只有寥寥几个而已。

第三、你扯OpenGL32.dll wrap了ddraw.dll里,那么请问用了的哪些个API呢?还是让我们看看你砍到的那些图的余下部分,有图有真相



OpenGL32.dll提供了多少个API: 368个,1:368,果然是一叶障目啊,你还真奸猾,真能扯淡

至于ntdll.dll,那是WOW进入内核态的总入口,OpenGL不是子系统,只是WOW的一部分,不调用ntdll.dll才见鬼了。
5 楼 mallon 2010-06-19  
WOW是WOW(专指16位环境),WOW64是WOW64,呵呵不玩文字游戏,我说那些子系统和OpenGL是API Wrap是有根据的,看图






很显然opengl32.dll调用的是ddraw.dll(至于第三方的OpenGL实现,例如SGI的,那就不得而知了),而psxdll.dll最终依赖的是ntdll.dll,众所周知ntdll.dll是用户态的最底层,但是并不是内核态的,微软不是傻子,能够依赖现有实现的,怎么会重来一次呢?

所谓微内核巨内核纯粹炒的是概念,微内核好在哪里?结构清晰合理?那结构清晰合理又得到了什么好处?Who cares?大多数时候关心的是整体架构设计,单单一个内核决定不了什么。

Windows确实层次多,但从来没有实现过真正的组件化,组件之间的依赖性是非常大的,上午还有事就不深入讲了吧,反正真正深入研究过Windows底层的都知道的。

我从一开始写程序就接触的Windows,持续了很多年,也曾为搞懂一个诸如API Hook、Native API之类的问题而沾沾自喜,当时想的是Windows确实“博大精深”啊!但是现在已经厌倦了这一切。俗话讲由简入繁易,由繁入简难,“博大精深”并不能说明所谓的“先进”,“大道至简”才是最高境界
4 楼 七猫 2010-06-18  
1、opengl似乎不是directx的简单包装。
2、个人认为windows内核设计比linux内核设计要先进。不知道为什么多层次更加组件化其实正是缺点。
3 楼 ray_linn 2010-06-18  
mallon 写道
1、WOW提供的是16位Windows的兼容层,可以把它看成是一个16位的模拟器,类似于NTVDM模拟16位DOS一样

2、很多所谓的“子系统”,例如Posix,其实只是一个或几个DLL,按照Posix的标准把底层的API包装了一下而已,甚至大名鼎鼎的OpenGL也是对DirectX的简单包装

3、Windows的设计其实是很拙劣的,文中最后所讲的“Windows的设计更有弹性,它是一个多层次的而且更加组件化的操作系统”等等其实正是Windows的缺点,没办法,商业化带来的后果就是设计思想的匮乏和越积越多的历史包袱


1...WOW是16位兼容层。。。汗,那WOW64呢?

2...我说了半天,您一个字儿都不看?Wrap API那是CygWin做的事情,那是不折不扣在Win32 API上模拟POSIX。举个简单的东西, 你在Win32里模拟出COW给我看看?

3...您一句话就把业界公认的更先进的微内核设计打回老家去了?Windows是混合内核,但比起linux的单一内核,它更像微内核

相关推荐

    创建新进程:fork函数:fork函数干什么? fork函数与vfork函数的区别在哪里?为何在一个fork的子进程分支中使用_exit函数而不使用exit函数?

    fork 函数是 UNIX 统操作系统中用于创建新进程的系统调用。它创建了一个完全相同的子进程副本,并返回一个进程标识符(PID)。fork 函数的返回值在父进程和子进程中不同:在父进程中,返回子进程的 PID;在子进程中...

    Git-Fork for Windows

    https://git-fork.com/update/win/ForkInstaller.exe windows桌面版的图形化Git管理工具

    linux下socket和fork结合使用的例子

    `socket`用于创建通信端点,允许不同进程间进行数据交换,`fork`则是Unix/Linux系统中用于创建新进程的关键系统调用。本示例中,我们将深入探讨如何将它们结合使用,以实现一个简单的服务器程序,该程序可以接收...

    VC编程-UNIX与Windows移植.doc

    例如,UNIX中的fork()函数在Windows中没有直接等价物,需要使用CreateProcess()或Spawn*()函数来创建新进程。同时,进程间通信在两个系统中也有所不同,UNIX使用管道、消息队列和共享内存,而Windows则有自己的一套...

    Fork目前发现最好用的git-ui免费客户端(mac + Window版本)备忘

    在众多的Git UI客户端中,Fork被誉为macOS和Windows平台上的优秀选择。本文将详细探讨Fork作为Git UI客户端的优势及其核心特性。 标题中的"Fork目前发现最好用的git-ui免费客户端"表明,Fork在用户界面设计、功能集...

    git客户端fork安装包

    8. **Stash和Unstaged Changes**:Fork支持暂存区和未暂存区的操作,用户可以轻松地将更改暂时保存,以便稍后再进行提交。 9. **SSH密钥管理**:Fork可以方便地配置和管理SSH密钥,确保安全地连接到远程Git仓库。 ...

    带注释的fork文件.rtf

    * linux/kernel/fork.c * * (C) 1991 Linus Torvalds */ /* * 'fork.c' contains the help-routines for the 'fork' system call * (see also system_call.s), and some misc functions ('verify_area'). *...

    fork(Mac & Windows).zip

    高颜值的git客户端——fork,高度集成git操作,方便好用,add、commit、solve conflict 变得形象而简单。可以免费使用,偶尔会提醒购买软件,点击忽略即可。包含 Mac 和 Windows 安装包。

    Fork-1.0.91.1.dmg

    适用于Mac和Windows的快速友好的git客户端 Fork日新月异,我们很高兴与您分享我们的成果。 Fork会轻松地向您通知有关GitHub通知的信息,而不会令人烦恼。 使用合并冲突帮助程序和内置的合并冲突解决程序可以轻松...

    fork()编程fork()编程fork()编程

    在Linux和Unix操作系统中,`fork()`函数是创建新进程的核心机制。`fork()`编程是系统调用的一个重要部分,它允许一个正在运行的进程(父进程)创建一个与自身几乎完全相同的副本(子进程)。这个特性使得多进程编程...

    nohup、&、setsid、fork和fg、bg究竟有啥区别?

    子进程从父进程继承了:SessionID、进程组ID和打开的终端。子进程如果要脱离这些,代码中可通过调用setsid来实现。,而命令行或脚本中可以通过使用命令setsid来运行程序实现。setsid帮助一个进程脱离从父进程继承而...

    unix程序员手册.zip_UNIX_unix程序员手册

    通过《UNIX程序员手册》,新手不仅可以学习到UNIX系统的基础知识,还能深入理解其设计哲学和工作原理,为后续的系统级编程和高级应用开发打下坚实基础。这本书不仅是入门工具,更是长期参考资料,值得反复研读和实践...

    Fork 解读

    1.1 定义:Fork是Unix/Linux操作系统提供的一种系统调用,通过这个调用,一个正在运行的进程(父进程)可以创建出一个与其完全一样的新进程(子进程)。两个进程拥有相同的内存空间布局,包括代码、数据和堆栈,但...

    tar for windows windows运行tar打包工具

    在Windows操作系统中,通常我们使用的是与Unix/Linux系统不同的文件管理和打包工具,如7-Zip或WinRAR。然而,对于习惯于Unix/Linux环境的开发者和系统管理员,`tar`命令是一个不可或缺的工具,它能方便地进行文件...

    fork3()编程fork3()编程fork3()编程fork3()编程fork3()编程

    在Linux和Unix操作系统中,`fork3()`是一个不常见的术语,通常我们使用的进程创建函数是`fork()`. 可能这里的`fork3()`是某种特定情境下的命名或者误解,但在此我们将基于标准的`fork()`函数来讨论进程创建的相关...

    在win系统下模拟linux中的fork()函数执行过程与基础通信过程

    在win系统下模拟linux中的fork()函数执行过程与基础通信过程 备注清晰。

    Fork安装包,Git可视化操作工具

    在 Fork 的主界面上,你可以看到仓库的提交历史,分支列表以及其他信息。 创建分支: 在 Fork 中,你可以点击 "Branches"(分支)按钮来查看分支列表。 点击 "New Branch"(新建分支)按钮来创建一个新的分支,然后...

    FORK工具git管理工具

    2. **智能提示与预览**: 在提交前,FORK可以自动检测和提示未添加到暂存区的文件,同时支持对即将提交的更改进行预览,确保提交的内容符合预期。 3. **分支管理**: FORK支持一键创建、合并分支,以及通过可视化图表...

    unix系统编程源代码

    本源代码分析着重于理解和解析这些底层机制。 一、进程与线程管理 Unix系统中的进程是程序执行的实例,每个进程都有独立的内存空间。通过`fork()`函数可以创建新进程,`exec()`系列函数用于加载新的程序到已创建的...

    fork1() 编程fork1() 编程fork1() 编程fork1() 编程

    它通常用于表示一个进程创建新进程的过程,这是Unix和类Unix系统(如Linux)中的一个核心功能。`fork1()` 可能是`fork()` 函数的一个特例或变体,但在标准的POSIX系统调用中,并没有`fork1()` 这个单独的函数,通常...

Global site tag (gtag.js) - Google Analytics