re: 被拿来主义给惯坏了 CowNew开源团队 2008-10-07 19:51
& 0xFFFF
我们的应用特点不会存在导致bug的因素,所以懒得写,呵呵
re: 被拿来主义给惯坏了 sumtec@beijing 2008-10-07 12:41
你的 HIWORD 函数有Bug,你想想看哪儿有Bug?
re: 三鹿公司网站被黑 丁学 2008-09-12 17:18
三鹿有罪,但是有的人罪更大~~~~~
re: 从技术人员角度看Google chrome Gray Zhang 2008-09-04 13:02
@非主流程序员
其实最早IE就是标准,只是mozilla,opera等看不爽了就合作弄了个标准给w3c,然后IE不得不慢慢向w3c靠拢,IE也很无耐啊
re: 从技术人员角度看Google chrome Phinecos(洞庭散人) 2008-09-04 11:09
我的观点:虽然IE份额大,但被搞死是早晚的事情,除非微软能彻底抛弃老版本IE的历史包袱,google最大的敌人应该是firefox,两者渊源极深(可以参见CB上的Chrome开发内幕),Mozilla做的不仅是一个浏览器,而是一个优秀的开发平台,握有add-ons这样的法宝,遵循W3C标准,可扩展性极佳,我是FF粉丝,不过更希望google能在可扩展性方面超过firefox
但是,貌似是IE自己不支持标准啊,只是IE成了事实上的标准。
IE8在ACID3下只有不到20分啊,可Chrome有70多分。Safari是100分。不信你去试试。
@tshwangq
这个隐私跟google的关系可大着了
re: 从技术人员角度看Google chrome tshwangq 2008-09-04 00:10
@bangbang@
如果真就为了拼个隐私,也太不大气了。
况且他google再厉害,要和微软单纯的拼浏览器肯定拼不过的。
但是如果考虑的未来的互联网趋势,以及诸如webos之类的东西。
把浏览器看成一个操作系统或者网络客户端,那那家都会眼红的。
哈哈。
re: 从技术人员角度看Google chrome bangbang 2008-09-04 00:00
看来Google出这个浏览器,确实是为了对付微软的IE,IE8的隐私功能,绝对会影响Google的利益,Google对这个浏览器完全没有跨平台的打算嘛,吃死了跑在Windows平台。
re: 从技术人员角度看Google chrome tshwangq 2008-09-04 00:00
唉,又多了一个要支持的浏览器。
web开发容易么?
IE8 beta2现在如果一个tab死掉了,也不会导致整个窗口关闭,而且速度和Chrome一样快,因为我实在说不上谁快,反正当我一点图标的时候,都是瞬间就弹出来了。但是Chrome有些网页还是有问题。而且有些页面打开的时候速度慢。当然我们可以说那是网站制作本身的问题,但是我们也不能要求网站多么按照标准做,不能说别人的代码烂。至少IE无论网站的代码多么烂,都能正常显示,Chrome还是差很多。因为本身期待所有人和所有网站都遵循标准,就是一件不可能的事情。
举个例子:你给用户写个程序,总要进行输入检查吧,比如发帖子时里面不能包含<script>标签,我们假设内容不能包含<script>标签为一个标准,那么当我们用户违反这个标准的时候,我们的程序通常会怎么做,三种做法:
1:不管,那么后果很严重
2:提示用户违反标准,结果就是用户完不成固定的操作,必须去修改自己的输入。这好像就是很多类似Chrome这种浏览器干的事情。和标准有些不符就显示的一团糟。
3:知道用户违反标准了,但是自动去掉了<script>标签,将用户输入自动转换位合法的。OK,用户再也不用为自己的输入是不是标准的而操心了。我想大多客户都希望有这样的软件系统。这也正是IE干的时期。可以说IE是有着极其良好的兼容性的,这也是程序健壮性的一种体现。
我想如果你在为某个企业做个系统,任何情况都按照第二种来处理的话,估计肯定会被你的客户骂死。
re: 从技术人员角度看Google chrome longlongage 2008-09-03 23:35
极端情况下,当一个页面中的chrome崩溃的时候其他页面不会受影响。??
我今天怎么一个标签崩溃,其他的全卡住?然后自动关闭
re: 从技术人员角度看Google chrome dannyplus 2008-09-03 23:13
@ 飞不动了
就是,下次做网站的时候,附带一个浏览器,看看他们谁更牛...
我今天也试了一下这玩意,并用它跑一下公司的系统。
发现一些页布局变样了,还有一些脚本不能正确运行。
一些自己写的控件也不能用了。看来以后做web更困难了,更多的东西要考虑了。
NND,软件界对浏览器也不搞个标准,这一套那一套的,让做程序的受苦。
@Rivers Zhao
我看了看没看出来哪里烂啊,你说说有本事。
楼主的研究精神值得敬赏。
我曾经忘情于两汉的歌赋,我曾经惊讶于李杜的诗才,我曾经流连于宋元的词曲。但现在,看了楼主的帖子,我才知道我有多么浅薄!
re: 从技术人员角度看Google chrome icewater 2008-09-03 21:21
至今还守侯在WIN2003系统下,没一款浏览器看起来比IE6舒服,因为已经习惯了.上次用了一下WIN2008很快就也习惯了IE7.看来我是跟着系统走的.对其他的再好的浏览器都不太再意,IE做得不差就够了.没必要手动去习惯另一个相同功能的软件
re: 从技术人员角度看Google chrome CowNew开源团队 2008-09-03 19:58
@金色海洋(jyk)
兄弟你在开玩笑吗???
re: 从技术人员角度看Google chrome 金色海洋(jyk) 2008-09-03 19:33
大家有没有用过遨游2呢?
IE8也是每个标签单进程 做的比google的更好
re: 从技术人员角度看Google chrome hoodlum1980 2008-09-03 17:47
我尝试分析chrome的实现机理,一开始我认为每个页面就是一个进程窗口,只不过chrome将这些窗口通过SetParent这样的方式展示到一个父窗口中而已。但是使用Spy++进行探测后我大吃一惊,每个页面以及主窗口页面的ProcessId是同一个
-----------------------------------------
我不知道这有什么可惊奇的,好像只有IE才是开多个进程的吧。进程只是个容器。
今天用Google的时候也看到了,目前也正在使用中。。。该浏览器界面非常简洁,功能也不多。但我有点担心的是,对我们的数据安全性会不会有问题,比如Google公司会不会把你的帐号信息给偷过去???当成一个情报工具 呢???
re: 从技术人员角度看Google chrome Rivers Zhao 2008-09-03 17:36
--引用--------------------------------------------------
布尔: 对139邮箱兼容性极差,大家去试一下吧
--------------------------------------------------------
不是对139邮箱兼容性差,是139邮箱本身的代码就非常的烂。你看下139邮箱的代码就知道了,不符合一点标准和规范。
re: 从技术人员角度看Google chrome jillzhang 2008-09-03 17:13
@GoGoSonny
功能要一点一点完善嘛,哪能一步登天
re: 从技术人员角度看Google chrome GoGoSonny 2008-09-03 16:49
感觉Chrome就是Opera第二,很快,但功能还是离FireFox差点。
多进程,多内存啊,看看内存消耗吧。。。
re: 从技术人员角度看Google chrome CowNew开源团队 2008-09-03 16:34
@路人假
我的测试的目的是看长时间的运算页面之间是否会互相影响,而不是耗光内存。
@badnewfish
这个东西确实会把浏览器搞死。这也是我曾经希望浏览器有的功能,也就是一个页面中的模式对话框不会阻塞其他页面,无奈乎CHROME也没实现这个功能。我目前做的一套图形库能够实现页面中的模式对话框不会阻塞其他页面,呵呵,:)
迴圈內再生一些東西出來,把記憶體用光,這樣才像暴力測試
re: 从技术人员角度看Google chrome badnewfish 2008-09-03 16:27
一句代码搞死所以流行标签式浏览器:
protected void Page_Load(object sender, EventArgs e)
{
Response.Write("<script language='JavaScript'>alert('哈哈哈');window.location=location;</script>");
}
re: 从技术人员角度看Google chrome CowNew开源团队 2008-09-03 16:16
@Gray Zhang
我从来没否认过有了chrome这样的东西就不用进行算法优化了,工具在强大,该优化还是要优化。
你说的树的排序已经涉及到界面层次了,与我这里说的计算逻辑关系不大,页面线程只有一个,因此对页面进行频繁的操作肯定会非常卡。
re: 从技术人员角度看Google chrome Gray Zhang 2008-09-03 16:09
@CowNew开源团队
资源再多CPU也是顺序执行的,比如排序问题,1000个左右的数据扔到客户端用extjs排序一下会卡好几秒,用extjs的树来加载1000个左右的node也卡,这不是浏览器换一个就能改变的,依旧要从读取的问题上去优化,而不是把这种计算全交给客户端
re: 从技术人员角度看Google chrome CowNew开源团队 2008-09-03 16:06
@Gray Zhang
客户端有着非常丰富的计算资源,应该把不涉及到数据安全、数据机密的计算都放到客户端来,这样可以大大降低服务器的压力。现在的网页连多线程实现起来都费劲,更别提多核运算,很多用户的CPU占用率都只有百分之几(中木马病毒的除外,呵呵),这完全是对客户端资源的极度浪费。
re: 从技术人员角度看Google chrome Chinaren 2008-09-03 15:59
沙发,尝试了,确实是这样。
re: 从技术人员角度看Google chrome Gray Zhang 2008-09-03 15:59
没弹出警告并不是说没消耗客户端资源了,CHROME这是对不应该出现的大计算量的纵容,到时候再出点内存或者什么方面的问题,客户端死都不知道自己是怎么死的
re: 有人为我写诗了,谢谢啊 like%'远远'% 2008-08-10 08:51
我顶你个肺 o(∩_∩)o...
re: 有人为我写诗了,谢谢啊 金色海洋(jyk) 2008-08-09 14:32
心情好,吃嘛嘛香,呵呵。
re: 不用IIS跑.net web应用 CowNew开源团队 2008-08-09 13:22
用start方式启动就可以不一只留着cmd窗口了,这个和WebDev.WebServer.exe无关,是批量脚本解释器的事情。
re: 不用IIS跑.net web应用 kuafoo 2008-08-09 01:18
这个不好用 最好是用Visual studio 2008 带的 这个比较好点 不用一直留着cmd窗口
re: 我眼中的.net的缺点(和Java比较) CowNew开源团队 2008-07-25 16:45
@Rick Carter
可是在Eclipse中调试Java的时候可以随便改,不用停下来才能改;而且随时可以改,不会像VS那样弹出那个讨厌的“Edit、Restart”对话框来。
re: 我眼中的.net的缺点(和Java比较) Rick Carter 2008-07-25 09:15
楼主说的不对吧!!
我只看了第一条,让程序一边调试一边修改代码。
什么叫在非常苛刻的几个情况下才可以实现在调试状态下修改代码?我觉得vs对这个要求并不苛刻,你只要在要修改代码的地方设置断点,然后让程序执行到断点位置停下来,这时你就可以随意修改任何位置的代码,但如果你要是修改的是接下来不会运行的代码它将不会立刻相应,而要在下次重新执行到这个代码时才起效。
一旦代码段被执行过了就肯定不允许再修改了?!!!这个不对吧,你设置一个断点,程序执行停下来了就可以修改的。
你说的应该是vs与Eclipse的比较......
treeview1.Text=treeview1.ID.ToString();
re: WPF中嵌入普通Win32程序的方法 CowNew开源团队 2008-04-25 11:54
@Zhongkeruanjian
银行
re: WPF中嵌入普通Win32程序的方法 Zhongkeruanjian 2008-04-25 11:53
主要是WPF太耗性能了,问问楼主你们公司是给企业做,还是做桌面软件的?
re: WPF中嵌入普通Win32程序的方法 A.Z! 2008-04-25 10:11
--引用--------------------------------------------------
panlei_pl: 一直想弄明白,WPF的优势在哪里~~~
--------------------------------------------------------
估计等你弄明白了,市面上的公司也不缺人手写了。
re:WPF中嵌入普通Win32程序的方法 Yannic Yang 2008-04-25 07:41
“眼巴巴等着 hwndhost 这个爹给他发 消息”
呵呵
我总觉得这个问题有什么更好的办法……研究中
re: WPF中嵌入普通Win32程序的方法 簡簡單單.. 2008-04-24 23:15
re: WPF中嵌入普通Win32程序的方法 panlei_pl 2008-04-24 15:24
一直想弄明白,WPF的优势在哪里~~~