Chinaunix

标题: 对于windows系统，不知道大家看到这个是什么想法 [打印本页]

作者: walleeee 时间: 2012-05-18 00:04
标题: 对于windows系统，不知道大家看到这个是什么想法
本帖最后由 walleeee 于 2012-05-18 00:21 编辑

rt有什么想法？可以对比其他操作系统来说

当然，欢迎讨论为什么windows要如此，以及软件分发二进制兼容方面的技巧，以及c/c++二进制兼容的问题等等都可以讨论。
欢迎大家踊跃发言，不要怕说胡话，但是要尽力保证不说胡话。

图中时间显示有乱码，不过不影响整体。

捕获.PNG (89.02 KB, 下载次数: 40)

作者: walleeee 时间: 2012-05-18 00:05
据说gnu/linux 20g就几乎可以安装完全部软件。

反正我安装最多（绝对足够多）软件的时候不过占用15g磁盘

作者: zylthinking 时间: 2012-05-18 00:09
和windows有屁关系，你要是愿意也能在 /bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin 以及 /var/applications/A /var/applications/B 或者 /var/applicaitons/C 下都放一个 zlib1.so

作者: walleeee 时间: 2012-05-18 00:11
回复 3# zylthinking

问题是你愿意这样做么？我的意思是如果它们完全一样

作者: zylthinking 时间: 2012-05-18 00:17
在windows上不介意，为什么在linux下就介意了？
莫非还真是淮北为栀淮南为橘么？

本是不同系统下的不同习惯而已，有什么高下之分？你听说过windows下需要什么包管理系统了？？

作者: walleeee 时间: 2012-05-18 00:21
回复 5# zylthinking

在windows上不介意，为什么在linux下就介意了

你从那一句看出我不介意？我怎么看怎么都是在表达很介意的意思。

本是不同系统下的不同习惯而已

纯属无稽之谈，这是你自己无意识的说法。

你听说过windows下需要什么包管理系统了

所以乱七八糟？

作者: zylthinking 时间: 2012-05-18 00:29
你从那一句看出我不介意？我怎么看怎么都是在表达很介意的意思。
你那一句看出我介意？我怎么看怎么都是在表达很不介意的意思。

纯属无稽之谈，这是你自己无意识的说法。
无稽对无稽，仅此而已

所以乱七八糟
纯属无稽之谈，这是你自己无意识的说法。

决心远离口水战，低调
我着相了，再见再见

作者: walleeee 时间: 2012-05-18 00:51
回复 7# zylthinking

对，我知道你是不太介意的意思，问题是我比较介意，我是忍耐已久，结果你已经习以为常

无稽对无稽，仅此而已

我哪里无稽？
你这是在自以为无稽了么？

我着相了，再见再见

前段时间你不是说你开小号来么？你小号叫什么？何必躲躲藏藏。
比如我上次被send关时就造了个小号叫walleeee1，只不过就登录过2，3次。

还有，你对二进制兼容方面有什么经验可谈，或者看法也可以？

作者: zylthinking 时间: 2012-05-18 01:17
算了，就胡扯两句：
windows下有这现象，很显然都是商业软件，独自发行，说不定还要卖钱，人家需要考虑如何保证他的软件只要安装就能正常运行; *nix下多半是不考虑这个的。
*nix有PATH变量， windows又不是没有，你将所有 zlib1.dll删除了，保留一个放到 windows/sysytem32下，还不是大家都通用了？和 unix又有什么区别？？？将软件发行商家行为当作喷windows的理由，微软表示躺着中枪。

我没有测试通过快捷方式能不能让windows加载dll成功，如果成功了，那我估计unix通过软链接区分版本号的说辞也用不上了。
二进制兼容方面我没经验，我又不负责拯救地球，管他娘的，近来心境破局，以前斤斤计较的事情已经懒得理了，人就这么一辈子，技术最高境界也就是一个最最感兴趣的爱好，和老婆孩子家人比起来不在一个等级，可以钻研，甚至熬夜，生命皆可抛确实万万做不到的。

小号开了一个，密码忘记了，妈的现在居然连ID也忘记了，不过也算了，反正就用这个ID也无所谓，我潜水谁还能刺传我的氧气管不成。

睡觉去了

作者: zylthinking 时间: 2012-05-18 01:19
再贴一个， slackedit, linux下的商业软件，看看他的目录下有什么；别说这个不是 linux 平台：

./bin/libexpat.so.0
./bin/mozilla/libnss3.so
./bin/mozilla/libgmodule-1.2.so.0
./bin/mozilla/libxpcom.so
./bin/mozilla/libplc4.so
./bin/mozilla/gtk/themes/engines/libthinice.so
./bin/mozilla/gtk/themes/engines/libraleigh.so
./bin/mozilla/gtk/themes/engines/libnotif2.so.0.0.0
./bin/mozilla/gtk/themes/engines/libhicontrast.so
./bin/mozilla/gtk/themes/engines/libredmond95.so
./bin/mozilla/gtk/themes/engines/libpixmap.so
./bin/mozilla/gtk/themes/engines/libmetal.so
./bin/mozilla/gtk/themes/engines/libnotif.so
./bin/mozilla/libxpistub.so
./bin/mozilla/libglib-1.2.so.0
./bin/mozilla/res/samples/soundtest.html
./bin/mozilla/res/viewsource.css
./bin/mozilla/res/html/gopher-sound.gif
./bin/mozilla/plugins/libnullplugin.so
./bin/mozilla/libplds4.so
./bin/mozilla/libprldap50.so
./bin/mozilla/libsmime3.so
./bin/mozilla/libmozz.so
./bin/mozilla/libgtkembedmoz.so
./bin/mozilla/libgtksuperwin.so
./bin/mozilla/libssl3.so
./bin/mozilla/libnspr4.so
./bin/mozilla/libjsj.so
./bin/mozilla/libxpcom_compat.so
./bin/mozilla/components/talkback/talkback.so
./bin/mozilla/components/libfileview.so
./bin/mozilla/components/libtransformiix.so
./bin/mozilla/components/libtypeaheadfind.so
./bin/mozilla/components/libcomposer.so
./bin/mozilla/components/libxremoteservice.so
./bin/mozilla/components/libwallet.so
./bin/mozilla/components/libgfxps.so
./bin/mozilla/components/libnsprefm.so
./bin/mozilla/components/liboji.so
./bin/mozilla/components/libmozfind.so
./bin/mozilla/components/libappcomps.so
./bin/mozilla/components/jsconsole-clhandler.js
./bin/mozilla/components/libcookie.so
./bin/mozilla/components/libwebsrvcs.so
./bin/mozilla/components/libnecko.so
./bin/mozilla/components/librdf.so
./bin/mozilla/components/libmork.so
./bin/mozilla/components/libcaps.so
./bin/mozilla/components/libwidget_gtk.so
./bin/mozilla/components/libwebbrwsr.so
./bin/mozilla/components/libchrome.so
./bin/mozilla/components/libgklayout.so
./bin/mozilla/components/libwalletviewers.so
./bin/mozilla/components/libxpconnect.so
./bin/mozilla/components/libjar50.so
./bin/mozilla/components/libpippki.so
./bin/mozilla/components/libpipboot.so
./bin/mozilla/components/libuconv.so
./bin/mozilla/components/libimglib2.so
./bin/mozilla/components/libmozldap.so
./bin/mozilla/components/libp3p.so
./bin/mozilla/components/libhtmlpars.so
./bin/mozilla/components/libprofile.so
./bin/mozilla/components/libnsappshell.so
./bin/mozilla/components/libgfxxprint.so
./bin/mozilla/components/libautoconfig.so
./bin/mozilla/components/libpref.so
./bin/mozilla/components/libxremote_client.so
./bin/mozilla/components/libnecko2.so
./bin/mozilla/components/libuniversalchardet.so
./bin/mozilla/components/libjsd.so
./bin/mozilla/components/libpipnss.so
./bin/mozilla/components/libtxmgr.so
./bin/mozilla/components/libxmlextras.so
./bin/mozilla/components/libxpinstall.so
./bin/mozilla/components/libxpcom_compat_c.so
./bin/mozilla/components/libjsdom.so
./bin/mozilla/components/libembedcomponents.so
./bin/mozilla/components/libgfx_gtk.so
./bin/mozilla/components/libi18n.so
./bin/mozilla/components/libaccessibility.so
./bin/mozilla/components/libdocshell.so
./bin/mozilla/components/libqfaservices.so
./bin/mozilla/components/libgkplugin.so
./bin/mozilla/components/libucvmath.so
./bin/mozilla/components/libeditor.so
./bin/mozilla/libgtk-1.2.so.0
./bin/mozilla/libldap50.so
./bin/mozilla/libsoftokn3.so
./bin/mozilla/libgdk-1.2.so.0
./bin/mozilla/libxlibrgb.so
./bin/mozilla/libgkgfx.so
./bin/mozilla/libnssckbi.so
./bin/mozilla/libsoftokn3.chk
./bin/mozilla/libgtkxtbin.so
./bin/mozilla/libmozjs.so

作者: 0xC1988 时间: 2012-05-18 01:20
这个没什么大不了的了

习惯了
至少在一定程度上规避了应用程序对同名不同版本的动态链接库的兼容问题

作者: walleeee 时间: 2012-05-18 01:33
回复 11# 0xC1988

我的想法是新版本的动态库该兼容老版本的动态库，换句话说老程序连接到新的动态库应该一样可以运行。
这样系统只需要保存一份最新的动态库。

不知道做到这个的难度，和，各个程序自己带一份拷贝占用磁盘和内存以及维护上面的混乱，两者之间的平衡如何考虑和权衡。

希望能说说看法和技巧。

作者: walleeee 时间: 2012-05-18 01:52
回复 9# zylthinking

你说的商业这个问题，我觉得有道理。
问题是如此混乱的动态库版本是不是也会带来维护上的问题和消耗？之间是如何平衡的？

至于删除共同的动态库，这带来几个问题：
1)我还没疯，没那么多精力
2)不是人人都知道去删除相同的
3)我不知道大家是不是尊艘某些约定，比如很难预料将来是不是又个程序也叫zlib1.dll（这里可以换个不那么出名的程序）
4)windows上程序依赖动态库的版本不同，但是名字又相同，你看我截图中就有好几个是名字一样，但是版本显然不同的（让然，有几个是的确完全一样的），这时你这个办法就不行，又不能改动态库名字（非真正的动态加载，比如在编译时的动态连接）
5)如果MS不是历史上某些时候有鼓励这种行为，或者短时而不加约束，怎么会走到如今这种场面？
6)直接创建的快捷方式不行，mklink可以成功

看来你已经顿悟了，难得，难得

随意，无所谓了

你是说slickedit么？拼写错误？这个？
http://www.slickedit.com/

作者: niumingchao 时间: 2012-05-18 07:01
呵呵，有意思

作者: L_kernel 时间: 2012-05-18 08:11
没什么想法。那是Microsoft的东西，想改变？不行。
没什么想法。那是第三方Windows应用程序生产商的东西，也想改变？不行。

作者: 0xC1988 时间: 2012-05-18 09:37

walleeee 发表于 2012-05-18 01:33
回复 11# 0xC1988

一直向下兼容的可能性不大，而不是所有软件都能处于一直升级一直处于有维护的状态，这就是矛盾，自带库起码能保证程序是可运行的
有厂商还会对库进行定制以实现自己的需求，这也需要自带了

商业上的Zy的也说过了

就是linux下也有类似的情况不是，有些软件要求特定的库，虽然大多数时候link一下就可以，但有的时候非再装不可

作者: aychxm 时间: 2012-05-18 09:53
这关微软什么事，分明是各软件开发者自己定义的
如果某个库是开源的，我还可以做下修改，然后在做成.dll，那样的话，我能放在某个公共的lib文件夹么？我何不独立弄一个更省事

作者: wwwsq 时间: 2012-05-18 09:54
这个特性说明windows比linux先进。
linux太搓了。

你从centos 5.7下面拿几个安装包去 5.3 下面装装试试，就知道了。

作者: aychxm 时间: 2012-05-18 10:00
另外，楼主
如果linux的应用软件也达到windows下软件的数量，你看它乱不乱
什么war3啊，qq啊，cs啊，各种乱七八糟的游戏啊，聊天工具，作图工具，安全软件，等等，反正一堆软件
你去天空软件园、太平洋软件、霏凡下载、华军等等一些列软件下载的地方看，
如果有大量公司肯把这大量软件都做个linux版本出来，你再装几个，你看他们乱不乱，你看他们还敢都放在一个公共的lib库里头么
lz井底之蛙，自以为写了点linux程序，就可以鄙视windows上的软件开发者啦！

作者: Sevk 时间: 2012-05-18 10:35
提示: 作者被禁止或删除内容自动屏蔽

作者: reiase 时间: 2012-05-18 10:58
回复 1# walleeee

俺的第一感觉：
Windows下库好少，都跑去移植Linux下的库用

作者: zoulie 时间: 2012-05-18 11:02
很奇怪楼主有没有在windows下做过商用软件开发
仅凭这个就喷linux比windows优秀，这是怎样的一朵奇葩啊

作者: shanehan 时间: 2012-05-18 12:14
竟然会讨论这问题。。。

作者: zheguzai 时间: 2012-05-18 12:45
贴的那张图是干嘛的啊，每个目录下面都哟那个库么

作者: chinesedragon 时间: 2012-05-18 13:10
我记得是软件组织方式不一样

作者: walleeee 时间: 2012-05-18 14:27
回复 16# 0xC1988

有厂商还会对库进行定制以实现自己的需求，这也需要自带了

这个有道理

一直向下兼容的可能性不大

难在哪里？

而不是所有软件都能处于一直升级一直处于有维护的状态

这是“一直向下兼容的可能性不大”的原因还是什么？如果是原因，那既然都不维护，不升级了，怎么又会“一直”？

作者: walleeee 时间: 2012-05-18 14:30
回复 25# chinesedragon

目前看起来显然不一样，问题是为什么要这样？

作者: walleeee 时间: 2012-05-18 14:40
回复 17# aychxm

问题貌似很多程序依赖的公共库都不需要做什么修改，当然不排除某些厂商对库有调整。

问题是很多的确完全一样的库也被拷贝很多分，复制的到处都是，这是为什么？

作者: walleeee 时间: 2012-05-18 14:42
回复 18# wwwsq

你这个是系统降级却去运行高级别的软件。这不成立。

换句话说，你去用一个支持win7(调用了win7特有功能)的程序，放到xp下去运行（即便让带上你的各种库），能行么？

ps，
这里我们没有讨论到你说的那么远，目前只到了动态库维护以及组织的问题。

作者: walleeee 时间: 2012-05-18 14:46
回复 19# aychxm

你觉得linux目前的软件比win少？

有测评数据么？不然就是你臆想了。我尽管没有直接证据，但是凭常识和意识，我觉得提供给linux绝对比win不知道要多多少倍。

还有，凭什么说我是井底之蛙（尽管有可能）？你又是怎么知道我写了点linux程序（万一我没写过，只是用了几天linux）？
还有，你那一点看出我是在鄙视win的软件开发者？我鄙视的是这种行为，懂不懂？或者说我想看看这种行为有没有合理的解释，懂不懂？

引zk的话，“口水战就没意思了”

作者: walleeee 时间: 2012-05-18 14:48
回复 20# Sevk

所3q这些东西么？。。。。

有时候真悲哀，连用个计算机这么逻辑简单的东西，就是一些客观的计算，也会被某些人监视。

在程序搞后门（恶意后门）的开发者，真该下地狱。

作者: walleeee 时间: 2012-05-18 14:50
回复 21# reiase

win封闭，谁愿意给他搞？

他自己能力有不是无穷无尽，所以也搞不出像*nix那样丰富多彩的世界（尽管表面上看起来他丰富多彩）。

国内不知道多少闭源程序在用着gpl的东西，真要搞它们，不知道要死多少。

作者: walleeee 时间: 2012-05-18 14:51
回复 22# zoulie

没有做过。

我没有喷linux比windows优秀，这只是一个客观看法，你既然做过商业软件，那应该有有道理的看法，请指教，而不用人身攻击，不然就没意思了。另外，请回头再看我1L的文字。

作者: walleeee 时间: 2012-05-18 14:52
回复 24# zheguzai

图上面显示了zlib1.dll（zlib库）的存在。

作者: fhchina 时间: 2012-05-18 19:55
这说明不了任何问题：
1. Java虚拟机，常常装多套，更不用说jar的胡乱分发了。
2. .NET上的assembly, 也是如此。
3.Linux下， .so文件也可以到处放。

根本问题是：package的分发，不是一种受管的系统。不是一种从云中来的系统。因此，处于一种混乱，各自为政的状态。尤其是dll, so, 就是文件，可以乱拷。DLL地狱的问题，Linux上也有，只不过大家遵守版本号约定，冲突情况就少一些。如果遇到恶意改写共享so的情况，出问题也不可避免。Windows Vista开始，有WinSxS即Side by Side多版本并存，集中管理机制，应当是从.NET GAC的机制启发发展而来。

设想一种Cloud Package Manager, 操作系统封闭，所有的共享组件安装都如同App Store一样，远程受控安装，类似WinSxS, GAC的机制就可以解决同一版本在系统中出现多份的问题。Java阵营中，Maven Repository具有类似能力，.NET 现在有个NuGet, 能够进行依赖管理，将需要的Assembly远程下载安装到GAC中。

本质上，这是一个由于当年技术局限问题，遗留到今天形成的一个商业政治问题。

作者: 0xC1988 时间: 2012-05-18 21:01

walleeee 发表于 2012-05-18 14:27
回复 16# 0xC1988

1、不是每家厂商都愿意提供向下兼容的软件和库的，即使是M$，每次系统升级，都会爆出不同程度的兼容性问题
2、由于软件依赖的库并不都是自己实现的，而在软件工程周期结束后，可能相应的依赖库还在升级并且不向下兼容了，这个时候这些被留下来的遗老遗少如果不使用自带的库，可能就无法正常工作了

作者: walleeee 时间: 2012-05-19 00:14

回复 35# fhchina

作者: walleeee 时间: 2012-05-19 01:07
回复 36# 0xC1988

不是每家厂商都愿意提供向下兼容的软件和库的

不知道我猜得对不对。。
让大家好买新的？

作者: 幻の上帝 时间: 2012-05-19 05:13
DLL hell么……
C++ module会不会给力点呢。
倒是一直不明白winsxs这么大有毛用。。。

作者: walleeee 时间: 2012-05-19 07:49
回复 39# 幻の上帝

C++的abi正好是另外一个难搞的东西。这也算是一个高手对c++的一个炮轰点。

作者: walleeee 时间: 2012-05-19 07:50
回复 39# 幻の上帝

如果c++碰到abi要考虑，那很多c++所谓的特性以及卖点都瞬间消失，或者变得及其复杂根本非常人能控

作者: walleeee 时间: 2012-05-19 07:51
回复 39# 幻の上帝

winsxs是什么

作者: chinesedragon 时间: 2012-05-19 08:38
我记得有一片文章上说过，但忘了什么名字了。意思是说Linux的库基本上是共用的，所以都放在/usr/lib之类的地方；Windows上的库不太容易共用，所以只能放在自家目录下。

walleeee 发表于 2012-05-18 14:30
回复 25# chinesedragon

作者: walleeee 时间: 2012-05-19 08:53
回复 43# chinesedragon

为什么不太容易共用？

作者: chinesedragon 时间: 2012-05-19 09:12
我想起来了，是CU上的一个帖子，内容就是提问为什么Linux同时只能安装一个程序。我搜不到了，你可以搜搜看

walleeee 发表于 2012-05-19 08:53
回复 43# chinesedragon

作者: 幻の上帝 时间: 2012-05-19 14:32
回复 42# walleeee

目录%WinDir%\winsxs。

作者: ecloud 时间: 2012-05-19 15:36
这不应该是什么商业软件的借口，你系统设计的有问题，人家想不包含库提供，敢么？Win敢还是Linux敢？

Ok, show you
反正我的Mac上装了很多商业软件

作者: ecloud 时间: 2012-05-19 15:46

从这张图就能发现一个问题
凡是GNU的软件，统统自己包含所有的库
除了Xcode里面给发开预备的N个版本的库以外
系统里再没别的软件自己包含库了
我就不信只有GNU的这几个软件用压缩？
为什么GNU不相信系统里有合适的库呢？有句话怎么说的来着？那啥啥看别人都是啥啥

作者: ecloud 时间: 2012-05-19 15:51
本帖最后由 ecloud 于 2012-05-19 15:55 编辑

另外我多说一句
SDK的库要跟runtime分开
这个Win做到了，Java做到了，Mac做到了，但是似乎linux没做到，或者说不愿意这样做？
当年我刚开始学Java的时候觉得这个jdk和jre还分成两份给装上（哪怕你装得是JDK），真是脱了裤子放屁。可当后来我把jdk的某个包弄坏了以后，终于明白了这个好处

似乎是linux（包括各种BSD）的理念一直把自己当做一个开发环境而不是使用环境，所以所有的库本质上都是SDK，没有runtime
当然还有更恶劣的
AIX作为一个应该是使用环境为主的系统，更坑爹，不光runtime跟SDK不分，而且版本之混乱令人绝望

作者: walleeee 时间: 2012-05-19 16:19
回复 45# chinesedragon

什么叫linux同时只能安装一个程序？你难道不可以自己安装到其他位置，zk不是说得很明白么？

作者: walleeee 时间: 2012-05-19 16:20
回复 46# 幻の上帝

孤陋寡闻了。我先看看再说，tks.

作者: walleeee 时间: 2012-05-19 16:23
回复 47# ecloud

用mac的人就是帅气

看起来真美观。用linux这些不管怎么美化，始终感觉有点山寨。。。难道是心理原因？
还有，你这个字体初看挺漂亮的，叫什么？你文档也是这种字体么？这种无衬线字体看久了也很蛋疼。

那个Go2Shell图标亮了

作者: walleeee 时间: 2012-05-19 16:26
回复 48# ecloud

什么叫“凡是GNU的软件，统统自己包含所有的库”

你这里面哪个是gnu的软件？

你莫不是看到了几个版本不一样的库？难道你不知道它们可能仅仅是软连接？

作者: 三月廿七 时间: 2012-05-19 16:28
本帖最后由三月廿七于 2012-05-19 16:29 编辑

walleeee 发表于 2012-05-19 16:26
回复 48# ecloud

你这种水平应该拉风投了，

作者: walleeee 时间: 2012-05-19 16:30
回复 49# ecloud

重新编辑麻烦高亮一下，不然看不到

传统的c/c++ sdk怎么分运行时？一般我常见是分调试和非调试。你怎么能拿java来说事？

AIX没用过，不懂

作者: ecloud 时间: 2012-05-19 16:31
本帖最后由 ecloud 于 2012-05-19 16:35 编辑

walleeee 发表于 2012-05-19 16:26
回复 48# ecloud

dia
inkscape
GPG
这些都是GNU的软件，你没仔细看图吧
至于你问是否是链接，我又确认了一下，真不是

WuMacBook-Air:~ root# ls -l /usr/local/MacGPG2/lib/libz.dylib
lrwxr-xr-x 1 root staff 16 May 15 23:51 /usr/local/MacGPG2/lib/libz.dylib -> libz.1.2.5.dylib
WuMacBook-Air:~ root# ls -l /usr/local/MacGPG2/lib/libz.1.2.5.dylib
-rwxr-xr-x 1 root wheel 239568 Jan 3 21:55 /usr/local/MacGPG2/lib/libz.1.2.5.dylib
WuMacBook-Air:~ root#

复制代码

再次强调一遍，系统自己有 /usr/lib/libz.dylib，也有/usr/lib/libz.1.2.5.dylib
而GPG还是自己要带lib
dia和inkscape也一样，都在自己的目录里有个libz，他们都是GNU的软件
除此之外，没有别的软件单独带libz库的

作者: walleeee 时间: 2012-05-19 16:36
回复 54# 三月廿七

拉屁。快讨论问题

作者: 三月廿七 时间: 2012-05-19 16:39

walleeee 发表于 2012-05-19 16:36
回复 54# 三月廿七

拉屁。快讨论问题

昨天我看到某些人写的代码，彻底崩溃了，

作者: ecloud 时间: 2012-05-19 16:40
本帖最后由 ecloud 于 2012-05-19 16:45 编辑

walleeee 发表于 2012-05-19 16:30
回复 49# ecloud

很简单啊，就像Xcode一样，单独在一个目录里存放所有的SDK库，跟系统runtime的/usr/lib分开
做开发调试的时候统统链接SDK的库，不跟系统runtime库发生任何关系

Windows好像也是这样的吧，我Win用的不多，印象中VS也是自己带一套SDK库的

作者: walleeee 时间: 2012-05-19 17:00
回复 58# 三月廿七

你要不就沉默，要不就贴出来供大家围观。

作者: 三月廿七 时间: 2012-05-19 17:03

walleeee 发表于 2012-05-19 17:00
回复 58# 三月廿七

我问了个技术问题，帮我解答一下

作者: walleeee 时间: 2012-05-19 17:05
回复 59# ecloud

你这种说法正式很多大型开发集成环境，比如vc，cbuild这些东西做的事情。

它们这么做重要原因之一是为了让在它们上面开发的程序能保证发布出去能运行（发布的时候带它们的东西）。

对linux这种开放系统而言，这个问题就被弱化了，因为大家都是这么用的，也就不存在是不是发不出去不能运行什么的了，所以直接连接/usr/lib下面的也可以理解。

但是你说runtime和sdk分开这算是一个想法。能保证开发环境和系统隔离。

对。winsdk就是包含编译器以及配套库的东西。

作者: ulovko 时间: 2012-05-24 15:53

zylthinking 发表于 2012-05-18 01:17
算了，就胡扯两句：
windows下有这现象，很显然都是商业软件，独自发行，说不定还要卖钱，人家需要考 ...

支持，我喜欢你！

作者: AD8018 时间: 2012-05-24 16:06
用户真的在乎你的程序大小，是5M还是1M吗？

我连mfc的dll都不愿意看到。
要么自带dll，要么静态链接。
用非系统原生的dll，是自杀行为。

作者: walleeee 时间: 2012-05-24 19:44
回复 64# AD8018

现在可能在乎不那么明显。但是也不少见，你看看很多开源程序小巧也是卖点。

静态连接的问题在于浪费了内存，这个带来的问题又更多了。

作者: 北河东林 时间: 2012-05-25 07:53
不觉得有什么不妥

作者: KanonInD 时间: 2012-05-25 17:43
回复 56# ecloud

dia 的文件列表：http://www.archlinux.org/packages/community/i686/dia/files/
inkscape的文件列表：http://www.archlinux.org/packages/extra/i686/inkscape/files/
gpg的文件列表：http://www.archlinux.org/packages/core/i686/gnupg/files/

没发现它们自带了各自的zip库。
你的情况可能表明了：在软件打包方式上，ios和windows长同一副德性。

作者: ecloud 时间: 2012-05-25 23:28

KanonInD 发表于 2012-05-25 17:43
回复 56# ecloud

dia 的文件列表：http://www.archlinux.org/packages/community/i686/dia/files/

你应该去看gnu.org上的文件列表，而不是某个发行版的
另，GNU软件标准的发布方式是源代码autoconfig编译安装，即configure,make,make install

作者: flw 时间: 2012-05-26 00:39
楼主是想说迅雷很垃圾吗？
居然这么久都没人提到迅雷。
那一堆重复的 dll 还不都是迅雷搞的。

作者: walleeee 时间: 2012-05-26 01:01
回复 69# flw

没有。我只是临时想起这个事情，随便搜了个。你换成其他dll也行。什么iconv.dll，zlib.dll，mscrt****.dll，xxx.dll

都行。

作者: KanonInD 时间: 2012-05-26 18:38
本帖最后由 KanonInD 于 2012-05-26 18:44 编辑

ecloud 发表于 2012-05-25 23:28
你应该去看gnu.org上的文件列表，而不是某个发行版的
另，GNU软件标准的发布方式是源代码autoconfig编译 ...

gnu.org上的文件列表？不好意思，你水平太次了，那可是特定软件的一堆源代码。好吧，emacs 的源码包在此，ftp://gnu.mirror.iweb.com/gnu/emacs/。

作者: ecloud 时间: 2012-05-26 18:51

KanonInD 发表于 2012-05-26 18:38
gnu.org上的文件列表？不好意思，你水平太次了，那可是特定软件的一堆源代码。好吧，emacs 的源码包在此， ...

我的机器上还真有emacs
问题是emacs并没有自带libz

作者: KanonInD 时间: 2012-05-26 19:11
本帖最后由 KanonInD 于 2012-05-26 19:22 编辑

ecloud 发表于 2012-05-26 18:51
我的机器上还真有emacs
问题是emacs并没有自带libz

dia和inkscape的源码包本身不也没libz吗？
看见iphone上dia 的binary package带了libz, 就以为所有其他系统的dia 的binary package都带libz?
是否自带动态库、动态链还是静态链接都是"给软件配置、编译、打包并发布的人"的决定, 不是显而易见的吗？

作者: ecloud 时间: 2012-05-26 22:32

KanonInD 发表于 2012-05-25 17:43
你的情况可能表明了：在软件打包方式上，ios和windows长同一副德性。

KanonInD 发表于 2012-05-26 19:11
是否自带动态库、动态链还是静态链接都是"给软件配置、编译、打包并发布的人"的决定, 不是显而易见的吗？

作者: zheguzai 时间: 2012-06-05 16:15
回复 34# walleeee

这个库是干什么用的？出现在那里不正常么？

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)