simple: because Windows 2000 Server, Advanced Server and Datacenter are the only server products that Microsoft sells. The Windows.NET Server range (based on XP) hasn't shipped yet.
yes you can, there's a keyboard shortcut for opening each of the dockable frames (eg the Visual C++ 2.0 bindings use Alt-2 for the output window, Ctrl-K for the callstack, etc...) and once the focus is in a dockable window you can use Escape to return to the current MDI child, or Shift-Escape to close the dockable window.
jesus, named pipes are for networking not for IPC. shows how much IBM know about win32 programming. CreateNamedPipe() creates a pipe that is accessible across a network, whereas the results of UNIX's pipe() command are only accessible within that process (until it's forked). there are much better ways of doing IPC on windows than using named pipes.
all of the control panel options disappeared, replaced with the ever-crappy, crashing pile of MMC.
oh my god, don't you realise that with this simple UI change came th amazing powerful fact that all thos options that are now covered in the MMC are now exposed as COM components and are therefore scriptable from WSH?
This has to have been onee of the most significant improvements to the usability of the OS...
Re:Netscape 4.x Is the Problem, Not 6.x
on
Netscape 6.2
·
· Score: 2
hmmm... four things that piss me off about Mozilla/5:
you still can't script legacy plugins. ugh, how hard would this be to add, seriously?
LiveConnect. 'nuff said.
the <NOLAYER> <LAYER> mess.
XSL support is still buggy and slow
as far as I'm concerned the first three are regressions from netscape 4.x (and IE). Supporting new standards is great, but breaking existing code is just not acceptable. Sorry.
i think you're missing the point. XML is a formatted text file, and namespaces are the description of how they are laid out.
The difference being that for an XML file, the code for loading and parsing the data into an object model, manipulating and querying it is the same for every XML document. Whereas, for plain text files and human-readable descriptions you need a programmer to write and test code for each type of file. For XML this code has already been written and tested.
I don't agree with the 'diff' example either, for example the diff between two text files tells you nothing about the context of the diff, ie what the meaning of the change is (and no, just knowing the few lines above/below doesn't necessarily tell you anything, either). You have to manually refer to the original document and the description of the file-format in order to work out what has changed: just knowing that a particular line changed doesn't tell you what that change actually means. With an XML document it's easy to automatically derive the context of the diff, and there are already many programs which will do this.
addendum: for extra security you should make your ASP scripts run as a domain user that only has access to the SQL server, specifically only has access to those tables/SPs on the server that are necessary to run the application. You should also disallow access to the SQL server by all other users except an admin group, none of which have access to log onto the IIS boxes. the reason for this is that even if security is breached on the IIS box, whatever user they run code as will still not have destructive access. it would also require a hacker to write a specific hack for your system in order to access the DB, which, while not being perfectly secure, will greatly reduce the possibilty of a 'script' attack and the likeliness that someone will bother to embark on such a hack will be diminished. of course, if you have really sensitive data then you should hire a security expert (which I am not).
yup, you shouldn't be running IIS and SQL Server one the same machine. Ideally, you'd run SQL Server alone on the big machine and have a cluster of load-balanced inexpensive boxes running stateless ASP/ISAPI pages connecting to the DB over the LAN. You'll be free to patch the IIS boxes as needed and you can put them in a DMZ for extra security.
Yeah, VNC is OK. but it's too sloooow. I haven't had much of a problem using it with Win2K (ie all of our boxes). I use an 8-port switch (can't rember the brand, but it's not belkin or linksys) on my desktopp and it's great. I also use Timbuktu Pro which is really quick, but often it has problems authenticating domain users on client machines which is a royal pain-in-the-arse (tm) (ugh, i have to actually get up and walk the 10 feet to authenticate myself on the machine...)
why would it be costly for the rest of us? since the only code that's vulnerable to virii like codered and nimda is closed-source, there's absolutely no advantage i can see of being able to view the code for an exploit.
Well, because when that software is installed on a machine and is used then whatever value is gained from that software has been gained without financial recompense to Microsoft. The value of the software, and therefore its price is governed by the demand for it in the marketplace. If the market is diluted with pirate copies then the demand for the real thing decreases and so does its value. That decrease in value is caused by piracy and in the end the software industry has to increase prices in order to offset the lost value.
If you don't even install the software then it's irrelevant - you might as well have a CD with a picture of Schrodinger's Cat on it. But still, if you give or sell that CD to someone else who installs it, then you're conspiring to commit theft.
The real question, though, is: why are you committing a crime by pirating software when you have no use for it? It obviously has a value to you, that's why you do it. And it's that value that you're stealing.
The argument that you couldn't afford it doesn't stick either. You're either too lazy to afford it, or you don't need it.
Sorry, but yours is the argument of thieves and fools.
You are stealing the opportunity to make a sale. It is that opportunity of sale that is the fundamental basis of a trade economy, and arguably the basis of civilization: a move beyond nomadic subsistence into communication. I hate to get all philosophical on you, but it really is a question of simple economics.
If you believe that copyright infringement is a victimless crime then you are deluding yourself. It is theft, just a surely as is stealing the box from a store-shelf.
Remember that you're not buying the software, you're buying a license to use that software. It's the same for most distributed media/services, and it's been like that for a while.
now you know another VIM MS developer (actually, I worked on a VI emulation for an unreleased version of VisualC++ when I interned at MS in '92). vim 6.0 does the collapsing I'm talking about, do ':help folding'.
yeah, but with.NET you don't have to convert data-types from one environmnt to another because there is only one environmnt -.NET . The data-types are identical. As are the exception mechanisms, memory allocation/garbage collection, inheritance, threading models, etc...
sure, bridges like the one you describe are nice (Microsoft's extensions to Java did exactly this with COM), but they often have limitations (for example, how do you marshal a block of memory allocated using malloc() into the Java world, or a (void*)?). The nice thing about.NET is that it provides a programming environment where such things are unnecessary: the types in one language are the same as the types in another, only the syntax is different.
question: with the bridge that you describe, is it possible to write a class in ObjC, then derive from that class in Java?
It also comes with a tool (jbimp.exe) that converts a bunch of.class files (java bytecode) into a.NET Assembly (CIL.EXE/.DLL).<p>
Re:Stupid Question from a Non-Programmer
on
J#
·
· Score: 2
the main reason is that instead of having to conform to a different object/memory/exception/threading model than the language natively supports, the models that the CLR supports are now native to the language so you don't have to jump through hoops to use them.
Visual Studioo allows you to collapse sections of code, and will do this automatically for XML comments. You only need to see them if you want to.
One of the major advantages is that they're automatically integrated into the intelllisense argumnent completion stuff, so when you're writing a call to a method that is XML commented, a tooltip appears which show the type of the current argument and a free-text description of that parameter.
check this article for an excellent overview. if nothing else, check out the last screen-shot for an example of the power of XML/XSL.
Re:Initial reactions
on
J#
·
· Score: 3, Informative
actually J# does alot more than you think: it includes.NET implementations of the (albeit outdated) Java APIs. for example, the following namspaces (corresponding to java packages) appear in the library:
java.applet
java.awt
java.beans
java.io
java.lang
java.math
java.net
java.security
java.sql
java.text
java.util
along with a bunch of 'com.ms.*' packages.
I just compiled a couple of small java applications one (TCPMapper) uses sockets and another was a multi-threaded AWT app. Both compiled without changes into small.EXEs (11K & 25K respectively) and ran fine.
Also, I downloaded PC Labs' JMark1.1 which comes only as.class files (no source) and used J#'s jbimp.exe which converts.class files to a.NET assembly (.EXE/.DLL) - very cool. It ran fine also, and gave reasonable results, although MS's JVM was quicker overall. Still some room for improvement on performance there, but given that the JVM's been around for a while, and both J# and the.NET system it uses are still in beta, it's pretty imprssive nonetheless.
yes, but there's more to consider than just a CALL instruction, you have to consider the binary represntation of data-types, marshalling those types, handling exceptions, threading, garbage collection, etc... In most situations calling from one language to another requires a lot of support in order to get these things right. COM, CORBA, JNI are examples of systems that provide this kind of support, and there's always performance and convenience overheads associated with them. With.NET this is no longer an issue, since you're not calling between languages, you're just calling one.NET method from another. The fact that they were compiled with different languages is irrelevant.
But these things really aren't the bst part of.NET, sure having multiple languages is nice, but personally I wouldn't touch VB with a 10' barge pole. The real benifit lies in the libraries and OS integration: ADO.NET (traditional/XML data access), ASP.NET (WebForms, Web Services), WinForms (GDI+), etc... that are great improvements whatever language you choose.
Re:You really need to stop smoking that cheap shit
on
J#
·
· Score: 2
there's nothing in the CLR that is windows-specific. sure, right now the only fully-functional version publicly available is Microsoft's which runs on Windows, but there's nothing in the spec that requires windows featurs. In fact, there's nothing in the Win32 API that requires windows, either (see Wine).
Slashdot Mirror
simple: because Windows 2000 Server, Advanced Server and Datacenter are the only server products that Microsoft sells. The Windows .NET Server range (based on XP) hasn't shipped yet.
what you are advocating is anarchy, not capitalism. there's a subtle difference: laws.
jesus, named pipes are for networking not for IPC. shows how much IBM know about win32 programming. CreateNamedPipe() creates a pipe that is accessible across a network, whereas the results of UNIX's pipe() command are only accessible within that process (until it's forked). there are much better ways of doing IPC on windows than using named pipes.
This has to have been onee of the most significant improvements to the usability of the OS...
- you still can't script legacy plugins. ugh, how hard would this be to add, seriously?
- LiveConnect. 'nuff said.
- the <NOLAYER> <LAYER> mess.
- XSL support is still buggy and slow
as far as I'm concerned the first three are regressions from netscape 4.x (and IE). Supporting new standards is great, but breaking existing code is just not acceptable. Sorry.The difference being that for an XML file, the code for loading and parsing the data into an object model, manipulating and querying it is the same for every XML document. Whereas, for plain text files and human-readable descriptions you need a programmer to write and test code for each type of file. For XML this code has already been written and tested.
I don't agree with the 'diff' example either, for example the diff between two text files tells you nothing about the context of the diff, ie what the meaning of the change is (and no, just knowing the few lines above/below doesn't necessarily tell you anything, either). You have to manually refer to the original document and the description of the file-format in order to work out what has changed: just knowing that a particular line changed doesn't tell you what that change actually means. With an XML document it's easy to automatically derive the context of the diff, and there are already many programs which will do this.
addendum: for extra security you should make your ASP scripts run as a domain user that only has access to the SQL server, specifically only has access to those tables/SPs on the server that are necessary to run the application. You should also disallow access to the SQL server by all other users except an admin group, none of which have access to log onto the IIS boxes. the reason for this is that even if security is breached on the IIS box, whatever user they run code as will still not have destructive access. it would also require a hacker to write a specific hack for your system in order to access the DB, which, while not being perfectly secure, will greatly reduce the possibilty of a 'script' attack and the likeliness that someone will bother to embark on such a hack will be diminished. of course, if you have really sensitive data then you should hire a security expert (which I am not).
hope this helps, though.
yup, you shouldn't be running IIS and SQL Server one the same machine. Ideally, you'd run SQL Server alone on the big machine and have a cluster of load-balanced inexpensive boxes running stateless ASP/ISAPI pages connecting to the DB over the LAN. You'll be free to patch the IIS boxes as needed and you can put them in a DMZ for extra security.
Yeah, VNC is OK. but it's too sloooow. I haven't had much of a problem using it with Win2K (ie all of our boxes). I use an 8-port switch (can't rember the brand, but it's not belkin or linksys) on my desktopp and it's great. I also use Timbuktu Pro which is really quick, but often it has problems authenticating domain users on client machines which is a royal pain-in-the-arse (tm) (ugh, i have to actually get up and walk the 10 feet to authenticate myself on the machine...)
why would it be costly for the rest of us? since the only code that's vulnerable to virii like codered and nimda is closed-source, there's absolutely no advantage i can see of being able to view the code for an exploit.
If you don't even install the software then it's irrelevant - you might as well have a CD with a picture of Schrodinger's Cat on it. But still, if you give or sell that CD to someone else who installs it, then you're conspiring to commit theft.
The real question, though, is: why are you committing a crime by pirating software when you have no use for it? It obviously has a value to you, that's why you do it. And it's that value that you're stealing.
The argument that you couldn't afford it doesn't stick either. You're either too lazy to afford it, or you don't need it.
Sorry, but yours is the argument of thieves and fools.
You are stealing the opportunity to make a sale. It is that opportunity of sale that is the fundamental basis of a trade economy, and arguably the basis of civilization: a move beyond nomadic subsistence into communication. I hate to get all philosophical on you, but it really is a question of simple economics.
If you believe that copyright infringement is a victimless crime then you are deluding yourself. It is theft, just a surely as is stealing the box from a store-shelf.
did you tell Microsoft and the FBI?
Remember that you're not buying the software, you're buying a license to use that software. It's the same for most distributed media/services, and it's been like that for a while.
now you know another VIM MS developer (actually, I worked on a VI emulation for an unreleased version of VisualC++ when I interned at MS in '92). vim 6.0 does the collapsing I'm talking about, do ':help folding'.
sure, bridges like the one you describe are nice (Microsoft's extensions to Java did exactly this with COM), but they often have limitations (for example, how do you marshal a block of memory allocated using malloc() into the Java world, or a (void*)?). The nice thing about .NET is that it provides a programming environment where such things are unnecessary: the types in one language are the same as the types in another, only the syntax is different.
question: with the bridge that you describe, is it possible to write a class in ObjC, then derive from that class in Java?
sure, Managed C++ doesn't support templates or multiple inheritance (because CIL doesn't support them yet), but otherwise it's C++.
It also comes with a tool (jbimp.exe) that converts a bunch of .class files (java bytecode) into a .NET Assembly (CIL .EXE/.DLL).<p>
the main reason is that instead of having to conform to a different object/memory/exception/threading model than the language natively supports, the models that the CLR supports are now native to the language so you don't have to jump through hoops to use them.
One of the major advantages is that they're automatically integrated into the intelllisense argumnent completion stuff, so when you're writing a call to a method that is XML commented, a tooltip appears which show the type of the current argument and a free-text description of that parameter.
check this article for an excellent overview. if nothing else, check out the last screen-shot for an example of the power of XML/XSL.
- java.applet
- java.awt
- java.beans
- java.io
- java.lang
- java.math
- java.net
- java.security
- java.sql
- java.text
- java.util
along with a bunch of 'com.ms.*' packages.I just compiled a couple of small java applications one (TCPMapper) uses sockets and another was a multi-threaded AWT app. Both compiled without changes into small .EXEs (11K & 25K respectively) and ran fine.
Also, I downloaded PC Labs' JMark1.1 which comes only as .class files (no source) and used J#'s jbimp.exe which converts .class files to a .NET assembly (.EXE/.DLL) - very cool. It ran fine also, and gave reasonable results, although MS's JVM was quicker overall. Still some room for improvement on performance there, but given that the JVM's been around for a while, and both J# and the .NET system it uses are still in beta, it's pretty imprssive nonetheless.
But these things really aren't the bst part of .NET, sure having multiple languages is nice, but personally I wouldn't touch VB with a 10' barge pole. The real benifit lies in the libraries and OS integration: ADO.NET (traditional/XML data access), ASP.NET (WebForms, Web Services), WinForms (GDI+), etc... that are great improvements whatever language you choose.
there's nothing in the CLR that is windows-specific. sure, right now the only fully-functional version publicly available is Microsoft's which runs on Windows, but there's nothing in the spec that requires windows featurs. In fact, there's nothing in the Win32 API that requires windows, either (see Wine).