70,037
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
oyd 2004-10-29
- 打赏
- 举报
API借用了C Runtime的通用部分写了点东西
C Runtime的系统相关部分也借用了API来实现
还有 C Runtime更多的是意念上的东西(很多时候直接链接到程序内部)，API在系统中有实体(dll)
综上，这个问题没有答案，钦此！
realmz 2004-10-29
- 打赏
- 举报
看来多数人认为api更底层嘛
kobefly 2004-10-29
- 打赏
- 举报
顶一个
babam 2004-10-29
- 打赏
- 举报
api
sharp02 2004-10-29
- 打赏
- 举报
联系电话：010-82645151 详细参见：www.fcsoft.com.cn
什么是eform开发平台?
eform是基于浏览器的表单自定义工具,eform是页面设计工具,eform内含大量构件.不用写一行代码便能用eform开发出来常见的功能点.
使用eForm平台有如下好处:
1、用eform平台开发能降低开发人员的技术门槛,使很低水平的人就能开发一个软件项目中常见的功能.例如数据库的数据增删改查打印等等,而这部分功能往往也占居了一个软件项目的大部分.这样一个软件项目开发成员中可以有一大部分人是中专生甚至是高中生就能胜任.从而大大降低了整个软件项目的开发成本.另一方面因为低水平的开发人员很容易招聘到,这样也使软件项目更加容易完成.
2、用eform平台开发的代码一致性比较好,以后维护升级方便.因为只有个性化的功能才需要编写事件代码.所以代码量很少,大量的调用底层的代码,这样代码的集成度高.以后维护升级时修改的代码量非常少.
3、用eform平台开发能大大提高开发效率.eform平台采用对常见的功能和控件内置的方法,使得开发一些常见的功能(如数据库的增删改查,树控件,表格控件)非常容易方便.几乎不用写一行代码.直接通过控件的拖拉然后再设置属性和事件即可完成.开发程序的工作就象是打字员的工作一样.(如图所示开发效率对比示意图)
4、用eform平台开发能很好地应对软件开发项目成员的流动的问题.因为程序员的离职而造成整个项目瘫痪的事例很多.而用eform平台,因为大家都是采用同一模式开发的表单,因而一个人开发的表单很容易被另一个人看懂和使用.这样就使开发人员的流动造成的影响大大降低.企业不再受制于人.
5、用eform平台开发可以使项目不再没完没了,无法关闭.因为可以培训最终用户中的精英,让他们掌握eform平台的使用方法,这样大多需求他们便可以自己做好,而不用麻烦软件开发商了.
eform的设计思路是将数据库程序开发中常用的控制或功能点在eform平台中设计好,通过简单的设置参数或属性即可调用.而遇到很个性化的功能点则可以用传统的代码方式进行开发.因为一个数据库程序开发中大量是增,删,改,查,打印,报表,图表,数据校验等常见的功能点,而这些功能点在eform平台中都做好了,只要简单地设置一下即可完成这些功能点,而且这个设置过程也是可视化的,有相应的设置界面.这样做这些常见的功能点就非常简单快速.而少量的特别的功能点又可通过写代码的方式来完成.也就是说在一张表单中可以一部分功能是直接通过简单的设置一下来完成,另一部分功能是用代码来硬写出来的.这样就达到了常见的功能可以直接调用eform底层的api来实现以提高开发效率,但一个表单又不限定只能实现这些常见功能,你也可随意地用代码来进行无限扩充.这样就达到了既提高了开发效率又能实现很复杂的功能.
eform开发平台分为eform.j2ee和eform.net两个版本.eform.j2ee是用java编写的,面向j2ee应用.eform.net是用.net编写的,面向.net应用.实际上整个eform开发平台共有三部分的代码,① 一部分是htc js dhtml等前台的代码,② 一部分是java的代码,③ 一部分是.net的代码(c#语言的),其中java的代码完成的功能和.net的代码完成的功能完全相同.用①和②就组成了eform.j2ee版本,用① 和③ 就组成了eform.net.这样就得到了两个版本.由此可知,eform.j2ee和eform.net的接口和操作是完全相同的.只是运行环境和使用的编程语句不同罢了.这样做的好处是当需要从j2ee平台转到.net平台或是从.net平台转到j2ee的平台时,使用eform编写的表单和程序可以完全保留下来直接使用.可以轻松地跨越当今两大主流的开发平台.
使用eform开发平台开发出来的表单可以直接在浏览器中运行,不但如此,而且其设计工具也是在浏览器中运行的.也就是说,开发人员也是在IE中(拖拉控件)开发的.开发人员再也不用为了搭建开发环境而装一大堆软件了,这一点对于远程协作开发非常有利.
eform内置了常见的大量的开发构件,如树控件,表格,图表控件,打印控件,上传控件,查询等,也内置了象单表输入,一对多表输入等常见的数据库程序的功能点.通过使用这些可以大大提高开发的速度,降低开发这些常见功能的门槛,只需知道很少的知识便可以开发.使用eform生成的表单结构和格式一致,非常便于以后的维护升级.
eform开发平台开发出来的表单可以脱离eform平台单独运行,也很容易和其它程序进行集成.一个项目的程序往往是大量常用功能用eform平台开发,而少量功能用其它方式开发.然后把它们集成在一起而成的.
eform开发平台是专门为软件开发商或需要开发数据库程序的人而设计的.它采用开放版权的销售方式.对于用户开放100%的源代码,也就是说将eform开发平台的源代码全部提供给用户,同时还包括相应的开发文档和典型示例都提供给用户,而且用户用eform开发平台开发出来的程序可以自由分发.用户购买了eform后,就相当于eform是自己开发出来的一样.而且北京方成公司还提供一年的免费服务和技术支持.
eform的销售没有任何加密和license之说.是一种特别的销售方式.销售的过程实际上是完成知识和价值的转移的过程.相当于方成公司帮用户开发了一个平台然后再帮助用户把它使用起来,用户使用eform开发的软件可以自由销售,和方成公司没有任何关系,更不需要再收费用.由此可见,购买eform和自已招聘员工开发一个平台相比,无论是时间还是费用以及风险都是购买eform比较合算.
什么是eform开发平台?
eform是基于浏览器的表单自定义工具,eform是页面设计工具,eform内含大量构件.不用写一行代码便能用eform开发出来常见的功能点.
使用eForm平台有如下好处:
1、用eform平台开发能降低开发人员的技术门槛,使很低水平的人就能开发一个软件项目中常见的功能.例如数据库的数据增删改查打印等等,而这部分功能往往也占居了一个软件项目的大部分.这样一个软件项目开发成员中可以有一大部分人是中专生甚至是高中生就能胜任.从而大大降低了整个软件项目的开发成本.另一方面因为低水平的开发人员很容易招聘到,这样也使软件项目更加容易完成.
2、用eform平台开发的代码一致性比较好,以后维护升级方便.因为只有个性化的功能才需要编写事件代码.所以代码量很少,大量的调用底层的代码,这样代码的集成度高.以后维护升级时修改的代码量非常少.
3、用eform平台开发能大大提高开发效率.eform平台采用对常见的功能和控件内置的方法,使得开发一些常见的功能(如数据库的增删改查,树控件,表格控件)非常容易方便.几乎不用写一行代码.直接通过控件的拖拉然后再设置属性和事件即可完成.开发程序的工作就象是打字员的工作一样.(如图所示开发效率对比示意图)
4、用eform平台开发能很好地应对软件开发项目成员的流动的问题.因为程序员的离职而造成整个项目瘫痪的事例很多.而用eform平台,因为大家都是采用同一模式开发的表单,因而一个人开发的表单很容易被另一个人看懂和使用.这样就使开发人员的流动造成的影响大大降低.企业不再受制于人.
5、用eform平台开发可以使项目不再没完没了,无法关闭.因为可以培训最终用户中的精英,让他们掌握eform平台的使用方法,这样大多需求他们便可以自己做好,而不用麻烦软件开发商了.
eform的设计思路是将数据库程序开发中常用的控制或功能点在eform平台中设计好,通过简单的设置参数或属性即可调用.而遇到很个性化的功能点则可以用传统的代码方式进行开发.因为一个数据库程序开发中大量是增,删,改,查,打印,报表,图表,数据校验等常见的功能点,而这些功能点在eform平台中都做好了,只要简单地设置一下即可完成这些功能点,而且这个设置过程也是可视化的,有相应的设置界面.这样做这些常见的功能点就非常简单快速.而少量的特别的功能点又可通过写代码的方式来完成.也就是说在一张表单中可以一部分功能是直接通过简单的设置一下来完成,另一部分功能是用代码来硬写出来的.这样就达到了常见的功能可以直接调用eform底层的api来实现以提高开发效率,但一个表单又不限定只能实现这些常见功能,你也可随意地用代码来进行无限扩充.这样就达到了既提高了开发效率又能实现很复杂的功能.
eform开发平台分为eform.j2ee和eform.net两个版本.eform.j2ee是用java编写的,面向j2ee应用.eform.net是用.net编写的,面向.net应用.实际上整个eform开发平台共有三部分的代码,① 一部分是htc js dhtml等前台的代码,② 一部分是java的代码,③ 一部分是.net的代码(c#语言的),其中java的代码完成的功能和.net的代码完成的功能完全相同.用①和②就组成了eform.j2ee版本,用① 和③ 就组成了eform.net.这样就得到了两个版本.由此可知,eform.j2ee和eform.net的接口和操作是完全相同的.只是运行环境和使用的编程语句不同罢了.这样做的好处是当需要从j2ee平台转到.net平台或是从.net平台转到j2ee的平台时,使用eform编写的表单和程序可以完全保留下来直接使用.可以轻松地跨越当今两大主流的开发平台.
使用eform开发平台开发出来的表单可以直接在浏览器中运行,不但如此,而且其设计工具也是在浏览器中运行的.也就是说,开发人员也是在IE中(拖拉控件)开发的.开发人员再也不用为了搭建开发环境而装一大堆软件了,这一点对于远程协作开发非常有利.
eform内置了常见的大量的开发构件,如树控件,表格,图表控件,打印控件,上传控件,查询等,也内置了象单表输入,一对多表输入等常见的数据库程序的功能点.通过使用这些可以大大提高开发的速度,降低开发这些常见功能的门槛,只需知道很少的知识便可以开发.使用eform生成的表单结构和格式一致,非常便于以后的维护升级.
eform开发平台开发出来的表单可以脱离eform平台单独运行,也很容易和其它程序进行集成.一个项目的程序往往是大量常用功能用eform平台开发,而少量功能用其它方式开发.然后把它们集成在一起而成的.
eform开发平台是专门为软件开发商或需要开发数据库程序的人而设计的.它采用开放版权的销售方式.对于用户开放100%的源代码,也就是说将eform开发平台的源代码全部提供给用户,同时还包括相应的开发文档和典型示例都提供给用户,而且用户用eform开发平台开发出来的程序可以自由分发.用户购买了eform后,就相当于eform是自己开发出来的一样.而且北京方成公司还提供一年的免费服务和技术支持.
eform的销售没有任何加密和license之说.是一种特别的销售方式.销售的过程实际上是完成知识和价值的转移的过程.相当于方成公司帮用户开发了一个平台然后再帮助用户把它使用起来,用户使用eform开发的软件可以自由销售,和方成公司没有任何关系,更不需要再收费用.由此可见,购买eform和自已招聘员工开发一个平台相比,无论是时间还是费用以及风险都是购买eform比较合算.
kobefly 2004-10-29
- 打赏
- 举报
mark
pengzhenwanli 2004-10-28
- 打赏
- 举报
win32API更底层，C的一些库要依赖于他们的实现。
庄鱼 2004-10-28
- 打赏
- 举报
Wolf0403(完美废人)(短歌马甲 No.1——正身即日起宣布作废)
不说 Win32，看看一个 glibc 可以在各个不同版本的 Linux、BSD 上通用，也几乎可以用 uclibc 替代，就可以判断这个 c runtime library 只能是一个高层的东西了。
---------------------------
我对这种推论不敢苟同，就象：∵△ABC，∴∠A+∠B+∠C=180°∵∠ABD是△ABC∠ABC的外角∴∠A+∠C=∠ABD！这样的证明一样搞笑！
我的推理很简单：早期的winAPI函数都是在DOS基础上开发的，是以RTL为基础的，但是现在的API在很大程度上为了性能的需要重写了很多底层函数，有的甚至直接用汇编对口地址进行操作，凡RTL有的函数，在API里基本上都能找到相应的影子，因此很难再评价谁更低级这样一个问题。为此无聊的问题争论确实很不值得，因为如果重写自己的图形操作系统，我想没有人去用API，而是自己用C与汇编写一个接口与winAPI相似的API库，为了性能的需要，RTL也有可能被重写，如果有人问你，你的RTL与API哪个更低级，你会怎么回答？你是不是觉得他很无聊？
不说 Win32，看看一个 glibc 可以在各个不同版本的 Linux、BSD 上通用，也几乎可以用 uclibc 替代，就可以判断这个 c runtime library 只能是一个高层的东西了。
---------------------------
我对这种推论不敢苟同，就象：∵△ABC，∴∠A+∠B+∠C=180°∵∠ABD是△ABC∠ABC的外角∴∠A+∠C=∠ABD！这样的证明一样搞笑！
我的推理很简单：早期的winAPI函数都是在DOS基础上开发的，是以RTL为基础的，但是现在的API在很大程度上为了性能的需要重写了很多底层函数，有的甚至直接用汇编对口地址进行操作，凡RTL有的函数，在API里基本上都能找到相应的影子，因此很难再评价谁更低级这样一个问题。为此无聊的问题争论确实很不值得，因为如果重写自己的图形操作系统，我想没有人去用API，而是自己用C与汇编写一个接口与winAPI相似的API库，为了性能的需要，RTL也有可能被重写，如果有人问你，你的RTL与API哪个更低级，你会怎么回答？你是不是觉得他很无聊？
你我他111 2004-10-28
- 打赏
- 举报
如heartlove所说，因为涉及到系统方面的，如malloc要调用api,从这个角度说api更底层（有些系统调用是用asm实现的）。
carylin 2004-10-28
- 打赏
- 举报
你搞嵌入式的，应该问在嵌入式开发下哪个更底层。^_^
heartlove 2004-10-28
- 打赏
- 举报
在windows下，C库的实现改写了，为了适合win32的编程，凡是库里面涉及到系统调用的都是调用API，例如malloc，里面就是调用heapalloc之类的API
night_gale 2004-10-28
- 打赏
- 举报
应该是API更基础一些啊!!
sharkhuang 2004-10-28
- 打赏
- 举报
不是一个概念啊
Wolf0403 2004-10-28
- 打赏
- 举报
呵呵，用 VC 7.1 的，连接到调试版 CRT 看看就知道了。
Win32 API 就是 Win32 系统提供给其它程序进行调用的接口，类似于 Linux 的所谓 syscall 核心调用。正如 glibc 是基于 syscalls 的一个封装一样，Win32 上的 CRT 也是基于 Win32 API 的一个封装。不断跟踪 malloc 很容易发现诸如 HeapAlloc 之类的 Win32 API 调用。传统意义的 C 库是来自 Unix 的，在 Windows 系统成形以前很久就流传在各个 Unix 平台上了。Windows 系统为了提供一些编程接口的可移植性，因此在 Win32 API 的基础上封装了一组 C 标准库。
不说 Win32，看看一个 glibc 可以在各个不同版本的 Linux、BSD 上通用，也几乎可以用 uclibc 替代，就可以判断这个 c runtime library 只能是一个高层的东西了。
Win32 API 就是 Win32 系统提供给其它程序进行调用的接口，类似于 Linux 的所谓 syscall 核心调用。正如 glibc 是基于 syscalls 的一个封装一样，Win32 上的 CRT 也是基于 Win32 API 的一个封装。不断跟踪 malloc 很容易发现诸如 HeapAlloc 之类的 Win32 API 调用。传统意义的 C 库是来自 Unix 的，在 Windows 系统成形以前很久就流传在各个 Unix 平台上了。Windows 系统为了提供一些编程接口的可移植性，因此在 Win32 API 的基础上封装了一组 C 标准库。
不说 Win32，看看一个 glibc 可以在各个不同版本的 Linux、BSD 上通用，也几乎可以用 uclibc 替代，就可以判断这个 c runtime library 只能是一个高层的东西了。
双杯献酒 2004-10-28
- 打赏
- 举报
看来API和运行库是相互搅在一起了。
庄鱼 2004-10-28
- 打赏
- 举报
有啥好争的！编写一个简单函数做个测试不就知道了？API似乎是更高一级的，但如果是重新改写的话，那就应该与RTL的效率是一样的，不同的仅仅是形式。毕竟没有彻底重写过API没有发言权，仅仅是臆测，可是那个争论有意义吗？编程序难道不是关心功能的实现，而是关心这些枝节，这不是精力过于旺盛了吗？
chinapp 2004-10-28
- 打赏
- 举报
kobefly(科比---不惧挑战!) 估计连问题都没有看懂。
zgy166 2004-10-28
- 打赏
- 举报
本人对windows API约懂皮毛，说一说我的观点：
Windows API大部分是建立在C库的基础上，当然，也许microsoft也许会为了更好的实现windows里面的机制而对库做一些优化或者调整，但是，Windows API大部分是建立在C库的基础上这一点是肯定的。
当然，为了速度等要求，Windows API除了调用C库以外还会调用汇编。
最后，别把Windows API看得那么神圣，它还不就是一个接口，windows平台和应用的接口。
大家有兴趣的话可以拿我的《API for Windows 2000/XP》看一下，欢迎指点。
Windows API大部分是建立在C库的基础上，当然，也许microsoft也许会为了更好的实现windows里面的机制而对库做一些优化或者调整，但是，Windows API大部分是建立在C库的基础上这一点是肯定的。
当然，为了速度等要求，Windows API除了调用C库以外还会调用汇编。
最后，别把Windows API看得那么神圣，它还不就是一个接口，windows平台和应用的接口。
大家有兴趣的话可以拿我的《API for Windows 2000/XP》看一下，欢迎指点。
kobefly 2004-10-28
- 打赏
- 举报
让鄙视来得更猛烈些吧
我想了解着方面得东西啊,看来我是理解错了
请指教
我想了解着方面得东西啊,看来我是理解错了
请指教
jumpandfly 2004-10-28
- 打赏
- 举报
win32API是直接和系统交互的,当然要更底层,但有些库函数并不需要系现服务,这种情况下,如果win32api和C运行库都提供了函数的话,有可能它们谁都不依赖谁.
另外,kobefly(科比---不惧挑战!)太搞笑了,Linux下的程序能在windows下的C运行库上运行吗?Linux有Linux下的C运行库,windows有windows下的C运行库,为了移殖性,它们的接口大多一样,但内部实现是不一样的.Linux下的程序要想在windows下运行,至少要和cygwin重新编译吧.C语言和C语言的运行库并不是一个概念!
另外,kobefly(科比---不惧挑战!)太搞笑了,Linux下的程序能在windows下的C运行库上运行吗?Linux有Linux下的C运行库,windows有windows下的C运行库,为了移殖性,它们的接口大多一样,但内部实现是不一样的.Linux下的程序要想在windows下运行,至少要和cygwin重新编译吧.C语言和C语言的运行库并不是一个概念!
加载更多回复（1）
