Re: OK, lets talk portability.
От | cbbrowne@cbbrowne.com |
---|---|
Тема | Re: OK, lets talk portability. |
Дата | |
Msg-id | 20020507220651.6199138B3F@cbbrowne.com обсуждение исходный текст |
Ответ на | Re: OK, lets talk portability. ("Dann Corbit" <DCorbit@connx.com>) |
Список | pgsql-hackers |
> Translation from UNIX to Win32: > http://www.byte.com/art/9410/sec14/art3.htm The problem here is that the strategies getting sold aren't "How Do We Make it Portable?" ones, but rather "How do we port it to Windows, and throw away the Unix version?" The "neat technologies" are _not_ portability ventures, but rather porting ventures, one way trips down the "Richmond Highway." To have something that will truly be portable, it can't directly use fork(). It has to use [something else] which gets translated at compile time to fork(), on Unix, and presumably to CreateProcess() on Windows. It's probably possible; I doubt it's simple nor much of an improvement. And it begs the question: Is it really greatly advantageous to invoke a lot of "breakage" on existing code just to get the engine to work on Windows, when "Windows 2004" will probably have some built-in DBMS technology that tries to kill off _all_ Windows-based DBMSes that don't come from Microsoft? -- (reverse (concatenate 'string "gro.gultn@" "enworbbc")) http://www.cbbrowne.com/info/rdbms.html It is better to be a smart ass than a dumb ass. -- (concatenate 'string "chris" "@cbbrowne.com") http://www.cbbrowne.com/info/linuxdistributions.html "The primary difference between computer salesmen and used car salesmen is that used car salesmen know when they're lying to you."
В списке pgsql-hackers по дате отправления: