Slashdot Mirror

I can think of one very big reason to upgrade to IE7 (unless Opera/Firefox is an option) and that's better web standards support. The web development community is going to drop support for IE6 very quickly (I give it approx. 6 months) because the standards support is so bad.

IE7 has a long way to go with this, but it's a massive improvement over 6. It's not as if it costs any money, aside from bandwidth, to download it.

Obviously I would advise them to just use Opera or Firefox and switch to Linux while they're at it. But if that isn't an option they should at least take the free IE upgrade. The decision to not upgrade Office is a sound one though.

Where did you obtain that delicious piece of misinformation?

For Niels Ferguson's take on these conspiracy theories (he is one of the lead developers of BitLocker), see http://blogs.msdn.com/si_team/archive/2006/03/02/5 42590.aspx.

As it seems, they are really trying to fool people about Google. A lot of posts about Google in the Microsoft hiring blog:

http://blogs.msdn.com/jobsblog

It would be interesting to know how easy it is to spoof the dimmed screen, you don't have to Ctrl-Alt-Delete to enter the password. I think you've raised pertinent questions. Without getting into the nuts and bolts, which I hope to do in the following weeks, I would rather defer the question to others. However it should be more difficult: http://blogs.msdn.com/vishalsi/archive/2006/11/30/ what-is-user-interface-privilege-isolation-uipi-on -vista.aspx IIRC the UAC prompt operates in something called the secure desktop which would also have to be compromised. The devil is in the detail though, so I'll hedge my bets.

Q: Won't this wear out the drive? A: Nope. We're aware of the lifecycle issues with flash drives and are smart about how and when we do our writes to the device. Our research shows that we will get at least 10+ years out of flash devices that we support. From http://blogs.msdn.com/tomarcher/archive/2006/06/02 /615199.aspx Besides - as the data is encrypted on its way to the flash memory - it should detect if incorrect data is read back.

Perhaps even more interestingly, Visual Studio 2003 is not supported on Vista. Microsoft's advice for those of us who still need to develop for .Net 1.1 on Windows, but would also like to upgrade to Vista is

a. Run VS 2003 in a virtualized XP environment. (!?!?!?) or
b. Don't worry...it will *mostly* work - just don't try and 'complex debugging'. (!?!?!?)

Behold: http://msdn2.microsoft.com/en-us/vstudio/bb188244. aspx http://blogs.msdn.com/somasegar/archive/2006/09/26 /772250.aspx

Not only that but VS 2005 - yes, the latest version - requires a Vista compatibility service pack, after which it still complains about incompatibility and needing a FICTIONAL *Vista* update. (Though, it does work if you press 'Continue').

So, is it really any suprise that it doesn't officially support major products from other vendors? *Sigh*

Safer than giving up and running as Administrator is to use Filemon and Regmon to find out what exactly the broken application is doing that it shouldn't, then changing the ACL for just those files or registry keys.

Windows non-administrator LUA/UAC advice, tips and tricks.

If you had read the link I posted regarding signed ActiveX, you would see that it only allows signed ActiveX installations if group policy explicitly allows that particular company's software. In other words, only if the IT department says that particular control or company is OK.

This makes Vista far more secure than XP in the sense that users will no longer have to be admin simply to access the controls they need to get their job done. They can run as a standard user and still install the control(s) they need.

However, there is a brokering mechanism that enables users to download files to any location they have access to, or to install browser plugins and extensions, and the like. So users are still invited to make a mess of their systems, and no doubt many will, while Microsoft has a chance to shift blame away from itself.

Uh huh. First, you can't install plugins/extensions (with the exception of signed ActiveX) without admin privs. Period. Second, how, exactly, would you propose the user be able to save files to their Documents folder, or do any other file operation in their profile (or basically anyplace on the system) without this brokering mechanism? Would you prefer that Microsoft not allow users to download *any* files via the browser? Ya, that would work out well.

However, IE7 on Vista does still write to parts of the registry in protected mode.

IE7 is running as an extremely low-rights user. This does *not* mean that it doesn't have the ability to write to any part of the registry. It means that the register's ACLs must explicitly allow write access to the IE's low-rights user. Certain locations have been explicitly marked as write-safe for the low integrity process. The example given by The Register is one of them. In other words, it's not an issue.

However, DEP, when full on, may cause a number of applications to crash, or interfere with their installation. I'm betting that a majority of users will opt for the more conservative setting, and this of course means less defense for everyone.

You're betting that the majority of users, most of whom think "DEP" is an actor's last name, will go and hunt down the DEP setting and turn it off because it will supposedly cause lots of applications to crash? Really? You mean they won't selectively turn it off via the dialog box that comes up after a DEP-related crash that asks if you want to turn it off just for this application? Oh, and what quantitative study are you sighting that shows that lots of commonly used applications will crash because of DEP? Give me a break.

User Account Control (UAC) is another good idea, because it finally, finally, finally allows the machine's owner to work from a standard user account, and still perform administrative tasks by supplying admin credentials as needed on a per-action basis. You know, the way Linux has been doing it forever.

Windows has supported running individual processes as admin (or any other account) since NT4. It was integrated into the GUI in Windows 2000. That is not the point of UAC, and it's not how Linux does it at all. If you try and run an application or perform an operation on Linux or Unix that requires admin access, it will fail. It doesn't prompt you. It's a subtle, but big difference. And it's a critical difference in the Windows world where that vast majority of applications won't work without admin privs.

Of course, it only works if everyone stays out of the admin account as much as possible, and if everyone with an admin password knows better than to install a questionable program with admin privileges. And there's the catch: "Windows needs your permission to install this cleverly-disguised Trojan nifty program. Click Yes to get rooted continue."

Wrong. It works regardless of what user you *think* you're running as. An admin account on Vista (with UAC enabled) is NOT AN ADMIN ACCOUNT. It's a limited user. The *only* difference is that an admin account isn't prompted to t

However, there is a brokering mechanism that enables users to download files to any location they have access to, or to install browser plugins and extensions, and the like. So users are still invited to make a mess of their systems, and no doubt many will, while Microsoft has a chance to shift blame away from itself.

Uh huh. First, you can't install plugins/extensions (with the exception of signed ActiveX) without admin privs. Period. Second, how, exactly, would you propose the user be able to save files to their Documents folder, or do any other file operation in their profile (or basically anyplace on the system) without this brokering mechanism? Would you prefer that Microsoft not allow users to download *any* files via the browser? Ya, that would work out well.

However, IE7 on Vista does still write to parts of the registry in protected mode.

IE7 is running as an extremely low-rights user. This does *not* mean that it doesn't have the ability to write to any part of the registry. It means that the register's ACLs must explicitly allow write access to the IE's low-rights user. Certain locations have been explicitly marked as write-safe for the low integrity process. The example given by The Register is one of them. In other words, it's not an issue.

However, DEP, when full on, may cause a number of applications to crash, or interfere with their installation. I'm betting that a majority of users will opt for the more conservative setting, and this of course means less defense for everyone.

You're betting that the majority of users, most of whom think "DEP" is an actor's last name, will go and hunt down the DEP setting and turn it off because it will supposedly cause lots of applications to crash? Really? You mean they won't selectively turn it off via the dialog box that comes up after a DEP-related crash that asks if you want to turn it off just for this application? Oh, and what quantitative study are you sighting that shows that lots of commonly used applications will crash because of DEP? Give me a break.

User Account Control (UAC) is another good idea, because it finally, finally, finally allows the machine's owner to work from a standard user account, and still perform administrative tasks by supplying admin credentials as needed on a per-action basis. You know, the way Linux has been doing it forever.

Windows has supported running individual processes as admin (or any other account) since NT4. It was integrated into the GUI in Windows 2000. That is not the point of UAC, and it's not how Linux does it at all. If you try and run an application or perform an operation on Linux or Unix that requires admin access, it will fail. It doesn't prompt you. It's a subtle, but big difference. And it's a critical difference in the Windows world where that vast majority of applications won't work without admin privs.

Of course, it only works if everyone stays out of the admin account as much as possible, and if everyone with an admin password knows better than to install a questionable program with admin privileges. And there's the catch: "Windows needs your permission to install this cleverly-disguised Trojan nifty program. Click Yes to get rooted continue."

Wrong. It works regardless of what user you *think* you're running as. An admin account on Vista (with UAC enabled) is NOT AN ADMIN ACCOUNT. It's a limited user. The *only* difference is that an admin account isn't prompted to t

Why does Windows keep your BIOS clock on local time?

Of course, I found the link I was looking for in my previous reply: Why does Windows keep your BIOS clock on local time?

Seems like there was a good reason to remove the control from Vista. Also, it appears there are solutions for desktop apps that use the control.

Why? Is saving as "Word 97-2003" document difficult?

Also, folks using Word 2000 and later can use the new formats with a compatibilty pack

Your understanding is incorrect.

There is a 5 month technical review period to iron out technical details and to get the standard through the balloting process:

http://blogs.msdn.com/brian_jones/archive/2007/02/ 08/update-on-openxml-at-iso.aspx

It is the utterly lackluster performance of older hard drives and less than 2 gigs of memory that is killing most of the Vista installs I have seen. 5400 rpm drives are constantly seeking even for the most mundane tasks in Vista. A clean install of XP x64 pro on my old AMD 3000 1 gig ran gloriously for 2 years. Tried the Ultimate version last weekend on the same machine. Besides the Nvidia driver problem in Vista I have come up against a brick wall trying to get my old PCI IDE card working.

Then the article is wrong. You can manifest an installer or exe to default to admin and UAC prompts, or AsInvoker if you know you can install without special access (installing to a user directory only for example). You can see more information here: http://channel9.msdn.com/Showpost.aspx?postid=2112 71

Really? Because, your rant notwithstanding, the numbers tell otherwise.

PC sales for the week of Vista's release are up 173% compared to the week previous, and up 67% versus the same week in 2006.

A lot of this is because of the massive FUD campaign against Vista that seems to be prevelent in the media. It is too early for most users to upgrade, but Vista isn't going to destroy the internet or eat your children. It's a solid, stable OS.

They seem like great places were a couple of developers could just be given the job to fix them up. Yet they never seem to improve.

I find it ironic when people complain that Calc and Notepad haven't changed. In fact, both programs have changed. (Notepad gained some additional menu and status bar options. Calc got a severe workover.)

I wouldn't be surprised if these are the same people who complain, "Why does Microsoft spend all its effort on making Windows 'look cool'? They should spend all their efforts on making technical improvements and just stop making visual improvements."

And with Calc, that's exactly what happened: Massive technical improvements. No visual improvement. And nobody noticed. In fact, the complaints just keep coming. "Look at Calc, same as it always was."

Does Vista represent a wholesale breakage of backwards compatibility or have too many companies (Apple) jsut become lazy in not heeding the warning that the API's really were being deprecated? Or am I completely off base here?

The APIs in Vista are largely backwards-compatible. I have games over 10 years old that still run on Vista (Civilization 1 for Windows 3.1, SimTower). The biggest change on Vista that can break apps is likely UAC: Whereas on XP users ran as Administrators, even the admin account on Vista starts off with regular user privileges. On XP apps could freely write to Program Files and modify HKLM--not so on Vista. There are other possibilities for compat breaking, such as bug fixes in the Win32 API (yes, this happens; see Raymond Chen's blog for stories), other security changes (such as moving services to a separate window desktop), and just plain changes that affect an app because it uses an API in an odd way.

In that case, two things:

1. Just because it's news to you, doesn't mean it hasn't happened.
2. What rock have you been living under?

Anyhow, here's a jumping off point, and here is a particularly appropriate entry from that list.

In that case, two things:

1. Just because it's news to you, doesn't mean it hasn't happened.
2. What rock have you been living under?

Anyhow, here's a jumping off point, and here is a particularly appropriate entry from that list.

I challenge you to find a SINGLE Windows "Logo" certified application that does not run on Vista. Just one. (Not counting things like anti-virus, which use file system filters that were dramatically overhauled in Vista.)

The fact of the matter is that the vast majority of backwards compatibility issues with Vista are due to the fact those applications are poorly written.

Microsoft publishes some fairly simple rules that developers should follow to make sure their software is compatible with future (and current) versions of Windows. Rules like "Don't store your freaking user settings in Program Files". Not exactly hard to follow.

Yet most apps that don't follow these rules STILL work on Vista. Microsoft actually wrote code that detects when crappy applications do stupid stuff that violates their Logo rules, and will automatically redirect their output to temp folders under the user's profile.

But there is only so much they can do.

Apple has had more than a year to get their software ready for Vista. In my opinion, the only explanation for them not doing so is because they want to try and influence users to not upgrade to Vista.

I still find it incredible that software that is over 20 years old still runs on Vista.

Google's word processor and spreadsheet app have an interface which have a striking similar UI to that of Microsoft Office 2007's (see http://en.wikipedia.org/wiki/Microsoft_Office_2007 #User_interface)

According to http://en.wikipedia.org/wiki/Google_Docs_&_Spreads heets, docs and spreadsheets went public in October 2006, but Microsoft publicly showed Office 12 as early as September 2005 (see http://blogs.msdn.com/jensenh/archive/2005/09/13/4 64879.aspx)

Why hasn't anyone called out Google on this? Had Microsoft done it, Slashdot would have been up in arms!

And no, I'm not new here.

Brian Jones, "father" of the OOXML format, appears to think that OOXML would meet the description of the TX bill just fine: http://blogs.msdn.com/brian_jones/archive/2007/02/ 06/texas-looks-at-the-interoperability-of-file-for mats.aspx#1619559

So much for the mistaken religious fanatics around here who appear to think there's some kind of war going on between document formats... Everyone who's a TX voter, write to your reps and encourage them to approve this bill. Everyone on "both sides" will thank you, it's a win-win situation! ;)

Probably until it [...] opens up it's source.

I want to be clear that our intent is to build a platform that fully complies with the appropriate web standards

My advice is simple: Boycott IE. It's a cancer on the Web that must be stopped. IE isn't secure and isn't standards-compliant, which makes it unworkable both for end users and Web content creators.

See: http://blogs.msdn.com/michael_howard/archive/2004/ 10/15/242966.aspx

Brian Jones, head of Microsoft's OOXML effort, seems to have no problem with Texas' bill.
http://blogs.msdn.com/brian_jones/default.aspx

See: http://blogs.msdn.com/michael_howard/archive/2004/ 10/15/242966.aspx
See: http://rmh.blogs.com/weblog/2005/05/is_microsoft_i i.html

Those posts are somewhat old, but the trend apparently continues if you go check Secunia, or your favorite vulnerability lists.

This article mentions "kernel patching" which is definitely an area that was locked down in Windows Vista for improved security. If Apple was hacking the kernel as part of their DRM implementation, their technique could well run afoul of this change. I personally equate the conspiracy theories in this thread with the idea that a secret cabal is really running the entire world. It's appealing to some people and it makes them feel safer than the more likely reality that nobody is doing this stuff intentionally or that any specific intellect is truely behind it all, much in the same way our ancestors found it comforting to think they were being boned by Zues or Hera on purpose instead of bad things just happening. Microsoft is not the same company it was in 1995, large numbers of the old timers from those days have retired or at least moved on to other areas of the company, and much of the daily work on the code is being done by people who've only been with the company on the order of 2 or 3 years. There is an entire department concerned with legal compliance, and between them and the security groups have most of the real authority these days. Microsoft did more than best effort to educate the world about the changes coming in the new OS. Lots of companies either convinced themselves that it would never ship, that their software was too "important" for Microsoft to break and not hack up their OS to make it work, choose willful ignorance, or saw it as an opportunity to shiv each other and/or Microsoft in the press for their own gains. The final builds of the OS were available to MSDN Subscribers and through the Beta programs in November of last year, so it was technically possible to have most compatibility issues resolved well before Jan 30th. The reality is that corporations do not typically operate on a rational, logical basis. More often priorities are set based on mandates from ill-informed executives in combination with reactive in-bound support issues. Even many Microsoft teams took the same "we'll deal with it after the building is on fire instead of before" attitude, so it really shouldn't' surprise anyone that the entire software industry has a similar attitude. Still, you have to start somewhere and after a five year lull, things in the world of Windows software has gotten "interesting" (in that Chinese proverb kind of way for some) again.

I'm pretty sure Apple ported OS X for the same reason as Microsoft ported Windows CE.

Since WinCE is not in any way a "port" of Windows, that statement doesn't really mean anything. Heck, WinCE is not even what many smartphones use - they use Windows Mobile (which is based on WinCE but offers the common Windows-looking GUI which WinCE does not include).

That's one of the points the article was making, WinCE and Symbian are not full OS'es scaled down, but custom built OS'es meant to run on small devices. The level of computing power has finally reached the point where this is no longer nessecary, yet the phone market moves on bound by this constraint in development. Developing a Windows Mobile app is not going to be the same as developing a Windows app. The release of Vista means little to Windows Mobile users. OS X on the iPhone offers the advantage of being able to use things like CoreImage, and CoreAnimation along with all the standard GUI calls. It means that OS updates can be migrated to the phone in short order.

Obviously the GUI programming will be a little different because of the touch screen but it means Apple gets to use all the developer tools (including optimization tools) they have today, which should make for rapid development of applications on the phone.

One area the article doesn't explore very well I think are Linux based smart phones, since that is a real OS and API scaled down for a smaller device, but something which would be quite happier in more powerful hardware as well without as many development limitations as other platforms. It does have a more fractured UI approach from different people though.

Well
it
might
be
because
iTunes
sucks

I tried it so I could listen to some of the iTunes shares my housemates have but it kept crashing periodically and in the end I still prefer winamp's look and feel.

It seems to me Vista has had a lot of its inner gears re-tooled so that others can add-on the new applications. The sound features alone seemed to have been re-oriented more than people might be aware of.

"Vista redefines the audio landscape, but is it a landscape of forced obsolescence?"

http://pc.ign.com/articles/759/759538p1.html

In this blog there is video about how the audio stack in Windows Vista has been rewritten so people can have per-app audio control.

http://channel9.msdn.com/Showpost.aspx?postid=1163 47

I don't have Vista and am not in a rush to get it, but I think perhaps in time there could be more benefits to Vista than meets the eye. Certainly the 64 bit security functions don't seem exciting but if they block remote code execution then that's something to like.

Actually, I just found it - interview with Tony Williams of Microsoft. He would have saved himself a lot of trouble by just reading ESR's free book....

By the way, does Vista dump if you change your motherboard like XP does because of the IDE drivers only being changeable during an install?

• CD-ROM/CD-RW/DVD-ROM (1 point)

• IDE adapter (3 point)

• Physical operating system-hard disk - new hard disk S/N (11 points)

• Graphics card (1 point)

• SCSI adapter (2 points)

• Sound card (2 points)

• NIC - new MAC address (2 points)

• Processor - CPU (3 points)

• RAM (0->512MB, 512MB->1GB, 2GB->4GB, etc) (1 point)

• BIOS (bios ID) (not bios upgrade) (9 points)

A lot of people simply don't care to learn the difference between the search box and the address bar. "If I type what I want into this box here, I sometimes get a strange error message. But if I type it into that box there, then I get what I want. Therefore, I'll use that box there for everything." And you know what? It doesn't bother me that they don't care. In fact, I think it's good that they don't care. Computers should adapt to people, not the other way around.

http://blogs.msdn.com/oldnewthing/archive/2006/11/ 27/1160055.aspx

People seem to constantly suggest that the future is either with thin clients or with thick clients, but they never really explain why.

I think this is a false dichotomy. Thin clients and thick clients each have their uses. Thin clients are great as some things (deployment, maintenance, cross-platform capabilities, client security, etc.), where as thick clients are great at others (leveraging the local machine, UI flexibility, speed, privacy, etc.)

The successful applications utilizing AJAX are those applications which really don't need to the capabilities of the local machine. Those that try to do what a local app is much better at are doomed to fail, at least for the time being. (AJAX office suites, for instance.)

I see the line between these two kinds of applications slowly but surely blurring. I really doubt that HTTP/Javascript/XML will take us a whole lot further than we're seeing now. It just wasn't meant for this kinda stuff. While the various implementations of "rich" web applications are quite ingenious, they're hacks, and hacks can only take you so far.

Instead, I see HTTP and the browser being the primarily delivery mechanism for rich applications running inside a sandbox on the client. Essentially the Java model, but done right. (And, perhaps more accurately, done at the right *time*.)

You can see the beginnings of this with technologies like XUL, ClickOnce, XAML, XBAP, and WPF/E.

It's just a matter of time before these things catch on.

People seem to constantly suggest that the future is either with thin clients or with thick clients, but they never really explain why.

I think this is a false dichotomy. Thin clients and thick clients each have their uses. Thin clients are great as some things (deployment, maintenance, cross-platform capabilities, client security, etc.), where as thick clients are great at others (leveraging the local machine, UI flexibility, speed, privacy, etc.)

The successful applications utilizing AJAX are those applications which really don't need to the capabilities of the local machine. Those that try to do what a local app is much better at are doomed to fail, at least for the time being. (AJAX office suites, for instance.)

I see the line between these two kinds of applications slowly but surely blurring. I really doubt that HTTP/Javascript/XML will take us a whole lot further than we're seeing now. It just wasn't meant for this kinda stuff. While the various implementations of "rich" web applications are quite ingenious, they're hacks, and hacks can only take you so far.

Instead, I see HTTP and the browser being the primarily delivery mechanism for rich applications running inside a sandbox on the client. Essentially the Java model, but done right. (And, perhaps more accurately, done at the right *time*.)

You can see the beginnings of this with technologies like XUL, ClickOnce, XAML, XBAP, and WPF/E.

It's just a matter of time before these things catch on.

Currently compiler support for parellelization is not very automatic. You need to provide hints like OpenMT pragmas.
A lot of good libraries are available which help in multi-threaded execution: For example Concurrency and Coordination Runtime is a excellent framework.

I use OpenMT for a lot of my work, it scales well for upto 8 processors beyond that shared memory has proved to a bottleneck (I don't have NUMA hardware)

Don't you just hate how they are paying people to fill Wikipedia with this kind of spam? No bother, the truth will out.

Do you realise that none of the text that you quoted to support your claim was from the Wikipedia entry? It was all from the referenced MSDN blog. Surely you can't blame Microsoft from paying their "Program Manager for the Windows SDK Tools and Build Environment" to write an blog entry on their own Microsoft Developer Network website?

Readyboost is encrypted and is not a swap file. Pages are not swapped out of RAM to a readyboost device. Readyboost is primary for fast reading of commonly accessed files. See the following post from the MS ReadyBoost program manager: http://blogs.msdn.com/tomarcher/archive/2006/06/02 /615199.aspx

For those interested in what he does theres a video interview on channel9 site:

http://channel9.msdn.com/ShowPost.aspx?PostID=4989 1

Ever hear of the hybrid hard drive?

Using ReadyBoost-capable flash memory devices for caching allows Windows Vista to service random disk reads with performance that is typically 8-10 times faster than random reads from traditional hard drives. This caching is applied to all disk content, not just the page file or system DLLs. Flash devices are typically slower than the hard drive for sequential I/O, so to maximize performance, ReadyBoost includes logic to recognize large, sequential read requests and then allows these requests to be serviced by the hard drive. When a compatible device is plugged in, the Windows AutoPlay dialog offers an additional option to use it to speed up the system; an additional "ReadyBoost" tab is added to the drive's properties dialog where the amount of space to be used can be configured. ReadyBoost may also be able to use spare RAM on other networked Vista PCs in a future release. ReadyBoost

Q: Isn't user data on a removable device a security risk?
A: This was one of our first concerns and to mitigate this risk, we use AES-128 to encrypt everything that we write to the device.

Q: Won't this wear out the drive?
A: Nope. We're aware of the lifecycle issues with flash drives and are smart about how and when we do our writes to the device. Our research shows that we will get at least 10+ years out of flash devices that we support.

Q: How much of a speed increase are we talking about?
A: Well, that depends. On average, a RANDOM 4K read from flash is about 10x faster than from HDD. Now, how does that translate to end-user perf? Under memory pressure and heavy disk activity, the system is much more responsive; on a 4GB machine with few applications running, the ReadyBoost effect is much less noticeable. ReadyBoost Q&A

Informative? How ironic :-(

Microsoft SQL Server (which is Sybase in diguise)

How many times do we have to repeat it? This was true for old versions, there's not much left in from Sybase nowadays in SQL Server. Please get yourself informed instead of perpetuating wrong informations: http://blogs.msdn.com/euanga/archive/2006/01/19/51 4479.aspx

has an in-memory lock structure;

I have no clue why you point out that the lock structures are in-memory, which is btw good from a performance standpoint, but it doesn't imply anything in how the locking model works.

if your transaction acquires too many row locks, your locks are escalated (to page locks or table locks). While these rows are locked, readers are blocked.

First of all I must point out that readers are, of course, blocked only if the locks they are trying to get are not compatible with other locks being held on the same resource. The simplest case is when a writer has an esclusive lock which is incompatible with a shared lock trying to be granted to a reader. What is important, though, is that this is a perfectly valid model which is very useful in many scenarios. Furthermore it has been extensively documented at the theoretical level for dozens of years including the locking hierarchy escalation model to consume less resources.

Please se also my other comments at another post about this: http://developers.slashdot.org/comments.pl?sid=219 402&cid=17807944

Because of this, your are encouraged to keep your SQL Server transactions as short as possible.

It's not because of this, it's because if your scenario needs such a transactional isolation, it means you have to block and it follows that you need to hold locks for short periods if you want more concurrency.

By default, isql DML commits after every statement, and you must use a BEGIN TRANSACTION/COMMIT if this is not what you want.

Yes, and I'll argue that it's a good idea for several reasons.

First of all, let me clear this out, it is a good reason in a system that implements only locking (no row versioning) because people may leave uncommitted transaction blocking other transactions and the regular maintenance of write-ahead logs.

Secondly, even using a row versioning mechanism you can have problems leaving uncommitted transactions. More precisesly logical problems. What if you update some important metrics and forgot to commit? Maybe someone else makes some decisions based on the previously committed values instead on the new ones. This may or may not have a dramatic impact in your process.

Thirdly, it is required in transactional theory to mark all multi-statement transactions with a begin work and either a commit or rollback work. The way some database systems works is just by opening a transaction behind the scenes which is absolutely not intuitive. Expecially for people learning and when faced with immediate checking transactions (eg. primary key violation, what happens? has the transaction rolled back or only the last command?).

Oracle does not use a memory structure for row locks, and Oracle never escalates a lock (although lock types can be converted). Oracle records a pre-DML image of the row in a "rollback" or "undo" area, and any SELECTS against uncommitted DML will silently pull from the old version.

Again, it doesn't matter whether it's a memory structure or not, nor if it's implemented using logs. It's just a row versioning model, another well known theory for decades. Perfect in many situations, like reporting, but incorrect in many other (think at the classic banking account scenario).

This has a few i

I would like to hear the "inventor"'s explaination of this and why they shouldn't be prosecuted for perjury and/or fraud.
Gautam Goenka
Partho P Das
Umesh Unnikrishnan

I would like to hear the "inventor"'s explaination of this and why they shouldn't be prosecuted for perjury and/or fraud.
Gautam Goenka
Partho P Das
Umesh Unnikrishnan