God help us if that ever gets popular... you'll need a quad Xeon just to run a small website.
I recently noticed that Carpoint now seems to be running on ASP.NET (the default page still has.asp extension, but the rest are.aspx). Definitely not a small site.
You can see the linker version using this command:
dumpbin %systemroot%\system32\ntdll.dll/headers
Re:standardized locations, etc.
on
Is RPM Doomed?
·
· Score: 1
I do agree with Windows' conventions on DLL use - '.' is always in the DLL search path, and it's conventional when starting GUI programs to chdir() to their "bin" directory...
Yes, this is more user-friendly. However, it is also an enormous security risk. If someone were to put a libc.so in your current directory (which quite often is not your home directory), then the system would use that instead of standard libc.
Now, you could try to patch things up the microsoft way, fixing one hole at a time, but a better solution is to simply fix the underlying architecture, and not have . in your LD_LIBRARY_PATH.
Yes, it's a security risk, and MS is aware of it. On XP, setting HKLM\System\CurrentControlSet\Control\SessionManag er\SafeDllSearchMode to 1 will cause "." to be searched after the system directory.
On.NET Server I think "." will be removed from the DLL search path by default.
For me the "showstopper" for C# is the lack of checked exceptions. I predict this will kill C# software reliability. I fear many people don't understand in time what a fatal mistake this is. Otherwise, I might have liked it.
Well, many people believe that checked exceptions in Java do more harm than good for large projects. For example:
I'll never understand why 'end process' in the task manager won't work and the 'kill' utility which you have to get from another CD only sorta works. You'd think that the desingers of NT might have thought to include the ability to properly terminate a rogue process
Truly unkillable processes are rare.
I'm not sure but I think task manager issue was fixed in XP/.NET server - it now allows you to kill all processes except for the ones that would bluescreen the machine if killed.
On Win2K/NT4 there are several ways to kill any process using only built in tools. You can attach a debugger (right click, Debug in Task Manager or ntsd -p <pid>, then 'q' from cmd line). Or you can launch Task Manager in the System logon session using 'at/interactive' - this will effectively give you LocalSystem rights.
Re:Not only does XP have the command prompt
on
MS DOS: A Eulogy
·
· Score: 1
Actually XP/Win.NET has many new command line tools that make my life as a developer somewhat easier. Off the top of my head:
- usable text-mode debugger (ntsd)
- taskkill and tasklist (finally!)
- command line interface to perfmon (logman, relog)
- command line interface to WMI (wmic)
Re:Stupid Question from a Non-Programmer
on
J#
·
· Score: 2, Interesting
COM(+) runtime layer is very thin. When you make a COM call, you essentially call raw native code. Which means there is no easy way to implement integrated services like cross-language exception handling, garbage collection, reflection, sandbox security etc.
Slashdot Mirror
Q244139: Windows Feature Allows a Memory.dmp File to Be Generated with Keyboard
Or you can just kill the csrss.exe process.
I recently noticed that Carpoint now seems to be running on ASP.NET (the default page still has .asp extension, but the rest are .aspx). Definitely not a small site.
You can see the linker version using this command:
dumpbin %systemroot%\system32\ntdll.dll /headers
Yes, this is more user-friendly. However, it is also an enormous security risk. If someone were to put a libc.so in your current directory (which quite often is not your home directory), then the system would use that instead of standard libc.
Now, you could try to patch things up the microsoft way, fixing one hole at a time, but a better solution is to simply fix the underlying architecture, and not have . in your LD_LIBRARY_PATH.
Yes, it's a security risk, and MS is aware of it. On XP, setting HKLM\System\CurrentControlSet\Control\SessionManag er\SafeDllSearchMode to 1 will cause "." to be searched after the system directory.
On .NET Server I think "." will be removed from the DLL search path by default.
http://www.microsoft.com/HWDEV/PLATFORM/server/hea dless/default.asp
= /library/en-us/xpehelp/htm/xeconHeadlessSystem.asp
http://msdn.microsoft.com/library/default.asp?url
Well, many people believe that checked exceptions in Java do more harm than good for large projects. For example:
c eptions a butz03-1.asp
http://www.mindview.net/Etc/Discussions/CheckedEx
http://www.java-zone.com/free/articles/Kabutz03/K
Adding checked exceptions to CLR is even less appealing because you'd have to implement them for all languages.
Truly unkillable processes are rare.
I'm not sure but I think task manager issue was fixed in XP/.NET server - it now allows you to kill all processes except for the ones that would bluescreen the machine if killed.
On Win2K/NT4 there are several ways to kill any process using only built in tools. You can attach a debugger (right click, Debug in Task Manager or ntsd -p <pid>, then 'q' from cmd line). Or you can launch Task Manager in the System logon session using 'at /interactive' - this will effectively give you LocalSystem rights.
Actually XP/Win.NET has many new command line tools that make my life as a developer somewhat easier. Off the top of my head:
- usable text-mode debugger (ntsd)
- taskkill and tasklist (finally!)
- command line interface to perfmon (logman, relog)
- command line interface to WMI (wmic)
COM(+) runtime layer is very thin. When you make a COM call, you essentially call raw native code. Which means there is no easy way to implement integrated services like cross-language exception handling, garbage collection, reflection, sandbox security etc.
CLR provides all that and much more.