Re: Inheritance

From: cristalink (cristalink_at_nospam.nospam)
Date: 02/16/05 

Date: Thu, 17 Feb 2005 12:55:08 +1300

// we've defaulted to 32/64 forever. don't want to change this now...

Isn't that brilliant? Can you imagine your feelings when you tracked down a
problem to this line of code? I however appreciate MS published the class
drivers sources. They saved a few days of my life.

Now what am I supposed to do? Go hooking to fix bugs in MS code?
Unfortunately, I can't change filesystems that fail because of this bug.
>From my point of view, the best solution would be MS promptly releasing a
patch I could refer my customers to. I am dreaming... 

-- 
http://www.firestreamer.com - NTBackup to DVD and DV
"cristalink" <cristalink@nospam.nospam> wrote in message 
news:%23c8TVlHFFHA.1836@tk2msftngp13.phx.gbl...
>I remember getting some prize from OSR bugbash campaign a few years ago. 
>Apart from that, I made a few attempts to post bug reports into this 
>newsgroup. Now I have a feeling that MS is not really interested in bug 
>reports for whatever reasons. I understand they don't want to hear end user 
>complaints. But they could possible provide an email for bug reports from 
>professional developers. I would be happy to submit a report if I received 
>an automatic reply saying MS is looking into it, even if they trashed the 
>report straight away. The problem is that to my knowledge there is no such 
>an email address, for kernel bugs in particular. There's a site for 
>reporting bugs in VS 2005 beta. There's no site for reporting bugs in VS 
>2003. I understand that nobody will fix 2003. All updates will come with a 
>new version several years later. The same is probably true for all the 
>rest.
>
> I've got a few fresh dumps of crashes in Win2k3 atapi.sys code called from 
> ISR. Should I post them here? Do you think somebody will actually be 
> looking into this, especially because they have SP1 RC?
>
> IEEE-1394 stack is extremely buggy. It should be just rewritten. I don't 
> believe it will be. Moreover, MS seems to gradually remove support for 
> 1394.
>
> CLASSPNP's handling of media change notifications and events is a mess. 
> There's no reliable way of getting the MCN status of a device, unless 
> polling it yourself with IOCTL_STORAGE_CHECK_VERIFY. I am talking about a 
> lots of options in different places which affect MCN. There's no way to 
> consistently receive eject notifications when a user pressed a button on a 
> drive. If someone is sending GET EVENT STATUSes to a device then this 
> screws up the notifications. I've just recalled a problem with MS Media 
> Player 9 that didn't want to update the content of an audio CD when I had 
> AutoRun=0. With a new CD in the drive WMP displayed the content of the old 
> CD. When I clicked on any title, WMP began playing with the LBA remembered 
> for the old disk. As a result, WMP played new tracks from some random 
> positions in the middle. I haven't found a workaround except of restarting 
> WMP.
>
> The most recent problem that made me angry is in CDROM.SYS. 
> IOCTL_DISK_GET_DRIVE_LAYOUT and IOCTL_DISK_GET_PARTITION_INFO return the 
> CDROM capacity different from IOCTL_GET_DISK_GEOMETRY due to the following 
> nice piece of code in src\storage\class\cdrom\ioctl.c:
>
>
>    //
>    // we've defaulted to 32/64 forever.  don't want to change this now...
>    //
>    fdoExtension->DiskGeometry.TracksPerCylinder = 0x40;
>    fdoExtension->DiskGeometry.SectorsPerTrack = 0x20;
>    fdoExtension->DiskGeometry.Cylinders.QuadPart = (LONGLONG)((lastSector 
> + 1) / (32 * 64));
>    commonExtension->PartitionLength.QuadPart =
>        (commonExtension->PartitionLength.QuadPart << 
> fdoExtension->SectorShift);
>
> They rounded the number of sectors to (32*64) for DISK_GEOMETRY, while 
> returning the correct capacity for DRIVE_LAYOUT. This effectively prevents 
> certain filesystems on a CD/DVD from being mounted.
>
> The bottom line. I need fixes from MS now. The best I can expect is to 
> have them in a few months, if I am lucky enough. So I count on myself 
> only. For my last projects, I spent more time finding workarounds for bugs 
> in MS code rather than fixing my ones. Why should I bother trying to find 
> an appropriate contact at Microsoft if I won't receive a reply anyway, or 
> the reply I expect from them - "there's a small chance it will be fixed in 
> some future versions".
>
> -- 
> http://www.firestreamer.com - NTBackup to DVD and DV
>
>
> "Don Burn" <burn@stopspam.acm.org> wrote in message 
> news:a_OQd.12587$9J.2626@fe06.lga...
>> Well if you see a bug are you reporting it?  Microsoft has been extremely 
>> good about fixing problems with the samples, which is why you should 
>> always be using the latest DDK.  Reporting it can be as simple as posting 
>> here or on ntdev.
>>
>>
>> -- 
>> Don Burn (MVP, Windows DDK)
>> Windows 2k/XP/2k3 Filesystem and Driver Consulting
>> Remove StopSpam from the email to reply
>>
>>
>>
>>
>>
>> "cristalink" <cristalink@nospam.nospam> wrote in message 
>> news:OHtJV2GFFHA.3492@TK2MSFTNGP12.phx.gbl...
>>>
>>> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message 
>>> news:%23Tb5ksGFFHA.1408@TK2MSFTNGP10.phx.gbl...
>>>>> which is actually nothing more than heaps of rubbish. Frankly, I have 
>>>>> not
>>>>> seen any, let alone C++, good code at all, except of my one.
>>>>
>>>> I'm also not free from such attitude :-), though MS's OS-level sources 
>>>> from DDK
>>>> samples are rated high by me :-)
>>>
>>> Really? Well, I was hesitant about including a remark about DDK samples 
>>> in my previous post... Here it goes. They look a bit messy and buggy 
>>> IMHO. No wonder Windows kernel programming is so hard.
>>>
>>>> But the question is another. Dirty C++/OO code is by far worse then 
>>>> dirty C :-)
>>>
>>> Agree.
>>>
>>> -- 
>>> http://www.firestreamer.com - NTBackup to DVD and DV
>>>
>>>
>>>>
>>>> -- 
>>>> Maxim Shatskih, Windows DDK MVP
>>>> StorageCraft Corporation
>>>> maxim@storagecraft.com
>>>> http://www.storagecraft.com
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>