CommunityProgrammierenVista / Windows 7Windows APIMartin Richter - So 15 Feb 2009 19:04

Sorry for blogging in English. I know that I am breaking my own rules 😉

Reasons for this article:
In the last years I found it more an more complicated to get bugs fixed in current software produced by Microsoft. My experience showed me, that the Microsoft product teams always look for new versions and new features and the Microsoft support teams and engineers don’t produce enough pressure that well known bugs get fixed in the currently used software products.

The reason why the Microsoft support rejected a request for a fix was very often that not enough customers are affected by the problem or bug. And this is often a problem for me and my company. We are just a small ISV so we can’t point to millions of affected users. And yes I know that hotfixes are expensive.
So usually we have to be flexible and have to find work arrounds.
But my feeling is that there would be enough impact and pressure for a hotfix, if it would be known to the public what problems exist and that there are others who have a request to get a special problem fixed.
Also a lot of programmers tend to avoid the creation of a support request, because the experience  shows: You put energy, time (and money) into a support request and the answers are in most cases: Will not get fixed, by design, and so on…

Another experience in the last years was, that even being an MVP doesn’t help to get anything fixed by Microsoft even if a lot of MVPs point out that there is a real need for a change or fix. 

So I just want to choose a new way, because there is no way to get votes of other people to a standard bug in a Microsoft product like it is possible on Microsoft Connect. But Connect is absolutely worthless if the product is already shipped!
I want to collect votes for this problem via my blog. I also informed the Microsoft support engineer who cares about the current incident.

If you agree and if you see a larger problem in this bug too, or if you have the feeling or knowledge that it has impact on your own software, than please write a comment to this blog article. Please leave your real email address or homepage URL. The email address will not be visible to the public, and I will forward it only to Microsoft if the poster agrees.

Description of the bug:

On January 17th, 2009 I reported a reproducible bug in Windows Vista in the article DrawText unter Vista gegenüber XP um bis zu Faktor 50 langsamer!  (The article is written in German, you find a description in English below in the next lines)

Fact:
Windows Vista and Window 7 are up to 50 times slower in the execution of a simple DrawText function with DT_CALCRECT set compared to Windows XP.
You can find the source code for a sample code (VS-2005 MFC project) that shows the bug here:  TestDrawText.zip. If you are just interested in the executable you can find it here TestDrawTextExe.zip.

And as far as I can see the overall performance of DrawText is affected.

My request:
If you find it important that this need a fix, or if you have the feeling or the knowledge, that you software might be effected. Please leave a comment here ❗

Or feel free to vote on the bug I filed for Windows 7 on Microsoft Connect:
https://connect.microsoft.com/windows7/feedback/ViewFeedback.aspx?FeedbackID=401007

Thank you

Final Note (11.07.2009):
Read on here
http://blog.m-ri.de/index.php/2009/07/11/ausloesung-drawtext-unter-vista-gegenueber-xp-um-bis-zu-faktor-50-langsamer/

InternetOfficeSoftwareSupportMartin Richter - Do 12 Feb 2009 18:50

Microsoft SharedView 

Es ist nicht ganz so wie Live Meeting und kann auch nicht alles was Live Meeting kann (Voice Übertragung, Aufzeichnung etc.). Und die Geschwindigkeit ist auch nicht soooo der Kracher.
Aber Microsoft Shared View ist auf jeden Fall für mich eine heiße Entdeckung und ein Tipp für all diejenigen, die evtl. auch mal dem/der 80 jährigen Vater/Mutter am PC Remote unterstützend unter die Arme greifen wollen, weil der was am PC nicht versteht 😉 und gerade keinen NetViewer oder Live Meeting Account haben und es erscheint mir einfacher und effektiver als die Windows Remoteunterstützung.

Hier ein paar Features und Möglichkeiten:

  • Jeder Nutzer entscheidet welche Programme er freigibt, oder ob er gar (für einen Supportfall) den ganzen Desktop freigibt. Nicht nur derjenige, der die Session gestartet hat.
  • Jeder Nutzer verfügt automatisch über die Steuerung seiner freigegebenen Anwendung oder des freigegebenen Desktops.
  • Es ist möglich das jeder Sitzungsteilnehmer die Steuerung anfordern kann, sodass man aktiv beitragen und eingreifen kann.
  • Derjenige, der die Freigabe gestartet hat, erhält automatisch die Steuerung wieder wenn er mit der Maus klickt oder eine Taste auf der Tastatur betätigt.
  • Jeder Teilnehmer hat einen personalisierten Mauszeiger, mit dem er auf Bereiche hinweisen oder auch Bereiche hervorheben kann – ideal geeignet, um jeden Teilnehmer einzubeziehen und sicherzustellen, dass keine Details übersehen werden.
  • Und es gibt ein weiteres praktisches Feature: jeder Teilnehmer kann so genannte „Handzettel“ bereitstellen. Das sind einfach Dateien, die sich andere Teilnehmer sofort herunterladen können.
  • SharedView integriert sich in den Messenger

Mehr hier unter diesem Link:
http://www.connect.microsoft.com/site/sitehome.aspx?SiteID=94

Es lohnt sich wirklich einen Blick auf dieses Stück Software zu werfen ❗

C++CommunityProgrammierenMartin Richter - Do 03 Apr 2008 18:10

Der folgende Community Event findet in Bad Homburg statt und nicht wie angekündigt in Frankfurt.

C++ Community Event in Bad Homburg mit Microsoft Program Managern
Ich habe den entsprechenden Artikel geändert.

Termin & Ort:

  • Datum: 17.4.2008, 16 – 19 Uhr

  • Ort: Steigenberger Hotel Bad Homburg
    Kaiser-Friedrich-Promenade 69-75
    61348 Bad Homburg v. d. Höhe

Anmeldung erfolgt per Email über den offizieller Link für die Veranstaltung:
http://blogs.msdn.com/softwarehersteller/pages/cpp2008-4-ffm.aspx

C++CommunityProgrammierenMartin Richter - Di 25 Mrz 2008 17:59

Bei Microsoft passiert wieder mehr zum Thema C++.
Nachdem sich Dariusz Parys schon über volle C++ Vorträge bei dem Launch in Frankfurt wunderte und er nach Interessenten gefragt hat, die an weiteren lokalen Events für C++ interessiert sind tut sich nun was!

Am 17. April bietet Microsoft für die C++-Entwickler-Gemeinschaft eine dreistündige Veranstaltung zum Thema C++ in Visual Studio 2008 und dem VS2008 Feature Pack für C++ in Frankfurt/Main an.

Es wurden zwei Program Manager aus der Product Group eingeladen und sie einiges zum Thema C++ vortragen:

  1. What’s new in Visual Studio 2008
    • walkthrough new C++ features
    • VSTS for C++ developers
  2. A deeper look into the VS2008 Feature Pack for C++
    • demo of improvements to MFC
    • the value of TR1
  3. A brief glimpse into the future of Visual C++
    • highlights from what we’re building for the next version of C++

Termin & Ort (Update 31.03.2008):

  • Datum: 17.4.2008, 16 – 19 Uhr

  • Ort: Steigenberger Hotel Bad Homburg
    Kaiser-Friedrich-Promenade 69-75
    61348 Bad Homburg v. d. Höhe

Die Teilnahme an der Veranstaltung ist kostenfrei ❗

Anmeldung erfolgt per Email über den offizieller Link für die Veranstaltung:
http://blogs.msdn.com/softwarehersteller/pages/cpp2008-4-ffm.aspx

Anmerkung (31.03.2008):
Der ursprüngliche Veranstalltungsort war Frankfurt. Wurde am 31.03. endgültig auf Bad Homburg festgelegt!

C++CommunityProgrammierenMartin Richter - Sa 10 Nov 2007 19:52

Eigentlich ist es ja schön, dass Microsoft sich endlich mal zu etwas mehr durchgerungen hat, als nur partieller Kosmetik im Bereich der nativen Softwareentwicklung mit C++.

Nach meiner Meinung kommt das ganze allerdings um Jahre zu spät! Ich hätte spätestens mit VS-2005 erwartet, dass Microsoft den verbalen Bekenntnissen, dass es weiterhin auch native Entwicklung mit C++ geben wird, auch Taten folgen lässt.

Microsoft hat sich mit der einfältigen Umbenennung von Visual Studio in ein VS.NET 2002 keinen Gefallen getan. Die Verunsicherung unter den vielen C++ Entwicklern durfte ich damals in Neuss beim großen Launch des VS.NET 2002 als ATE (Ask the Expert) am eigenen Leib erfahren.

Geändert hat sich nicht viel in den Jahren danach. Die Verunsicherung ist geblieben und Vertrauen wurde keines zurück gewonnen. Ein vorbehaltloses Prüfen der neuen Compiler und Visual Studio Versionen hat in vielen Firmen nicht stattgefunden. Die Änderungen waren gravierend sicherlich, wenn man den Compiler und die IDE von VC++ 6.0 mit der von VC++ 2005 vergleicht, da liegen einfach Welten dazwischen.

Irgendwie hatten zu viele Firmen und Entwickler das Gefühl „nun stirbt C++“, „jetzt  ist die vielfach totgesagte MFC wirklich tot“. Zuversicht in die bestehende Technologie zu setzen war einfach nicht da.

Das Micrsoft natives C++ nicht abschreibt wurde zwar ab und zu gesagt, aber das hörte sich eher wie Pfeifen im dunklen Wald an. Die ganze Situation machte es C# und .NET Entwicklern leicht auf C++ Entwicklern herumzuhaken und sie zutiefst zu bemitleiden (natürlich immer mit einem hämischen Grinsen). Und teilweise geschah dies sogar aus den eigenen Reihen von Microsoft. Hatte man auf einmal mit C++ keine zukunftsweisende Technologie mehr?
Die Tracks bei Kongressen füllten sich mit .NET Beiträgen. Und was sich in C++ getan hat (und es hat sich noch einiges getan) wurde kaum veröffentlicht oder nicht gehört. Auch was Dokumentationen betrifft, hat sich die C++ Gruppe nicht mit Ruhm bekleckert.

Noch „besser“ wurde es als schwachsinnige Aussagen die Runde machte, dass die nächsten Betriebssysteme nur noch .NET erlauben würden, und demnächst alles, bis zum Treiber mit .NET entwicklet würden. C++ braucht man nicht mehr.
Schaut man sich heute an, wieviel .NET in Vista und Windows 2008 Server steckt, dann merkt man, wie blödsinnig diese Annahmen waren und das es kaum Ersatz gibt für native Entwicklung in C++.
Fakt ist: bis heute wurde keine wirklich weitreichende und wichtige Schnittstelle in Win32 geschaffen die nur aus der managed Welt anzusprechen wäre. Und selbst wenn, so ist die Brücke aus C++ in die managed Welt ist kurz…

Warum wurden keine Walkthroughs und Dokumentationen geliefert , die einem bei der Umstellung von Code der unter VC6 entwickelt wurde auf VC++2003/2005 erklären und leichter machen? Walkthroughs, die gezielt auf die speziellen Warnungen eingehen, die einem um die Ohren fliegen, oder konstruktiv bei Problemen mit dem Umstieg helfen, finden wir heute höchstens in der Community entsprechende Beiträge.

Wäre es zu viel verlangt gewesen, zum Beispiel sofort bei der Umstellung eines VC6 Projektes bestimmte Projekteinstellungen so zu gewährleisten, dass möglichst wenig Warnungen entstehen, aber der Programmierer auf die Änderungen, die seinen Code sicherer und kompatibler machen, klar hinweisen?

Es ist verschlafen worden! Ja es wurde Jahre lang geschlafen. MFCnext ist schön, nett. Das TR1 kommt ist prima. Ich frage mich aber ob es wirklich genügt das verloren gegangene Vertrauen wieder zurück zu gewinnen?

Just my 2 cents…

ProgrammierenSonstigesSupportMartin Richter - Do 03 Mai 2007 18:29

Aktuell packt mich so richtig die Wut. 👿 (und ich habe ziemlich viel Geduld)

Ich habe in den letzten Wochen zig-Fehler in den Compilern und Libraries von VC gefunden. Das fängt mit VC-2003 an und den hier geschilderten Fehlern in der MFC (siehe CPropertyPage Bug).
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=270493

Dann habe ich schon mehrere Bugs in VC-2005 gefunden. Unter andrem einige Probleme mit Attributed ATL.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=98753
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=275256

Oder auch Fehler im Resource Compiler in allen VC-Versionen.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=252616

Ganz zu Schweigen von so netten Sachen wie nicht funktionierende MT.EXE etc.
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=258108 

Diese Liste ist bei weitem nicht vollständig, sondern zeigt nur die Erfahrungen der letzten beiden Monate. Ganz schweigen möchte ich von den Bugs, bei denen ich mich eingemischt habe, weil ich sie bestätigen konnte.

Meine Erfahrungen der letzten Zeit machen mich absolut frustig:

  1. Extrem viele Bugs werden einfach so geschlossen als „Nicht reproduzierbar“
  2. Bugs werden geschlossen ohne auch nur einen Kommentar!
  3. Bugs aus VC-2003 werden grundsätzlich abgewiesen, wenn sie in VC-2005 gelöst sind. Meistens werden sie als „nicht reproduzierbar“ gekenzeichnet.
  4. Bugs aus VC-2005 werden auch nicht mehr angenommen, wenn diese in Orcas gefixt sind. Meistens werden auch sie als „nicht reproduzierbar“ gekenzeichnet.
  5. Ideen, werden oft sofort abgetan, erst wenn man etwas mehr Druck als MVP dahinter legt (was ein normaler User nicht kann), wird etwas mehr darüber nachgedacht.
  6. Liefert man einen Workarround zum Bug eines anderen, wird der Bug oft sofort als gelöst geschlossen.

Stellt sich die Frage: Was gehört denn nach Connect?
Na es gibt ja eine Beschreibung. Auf der Seite: https://connect.microsoft.com/availableconnections.aspx
lesen wir zumindest noch folgenden Text:

Visual Studio and .NET Framework Visual Studio and .NET Framework

Bleibt aber die Frage warum VC-2003 und VC-2005 nicht mehr in diese Kategorie zu fallen scheinen. Ist also nur noch das neueste VC (also Orcas) das eigentliche VC, selbst wenn sich das noch in der Beta befindet?

Für was ist also http://connect.microsoft.com noch gut?

Scheinbar weiß bei Microsoft selbst auch niemand so genau, welche Bugs bei Connect eigentlich eingereicht und wie bearbeitet werden dürfen. Aktuell habe ich eine Anfrage laufen, die klären soll, welche Policy eigentlich hinter Connect steht.

Mein Rat: Verwendet den direkten Weg über den Support. Als MSDN-Abonnement  hat man einige Support-Anfragen frei. Als Certfied Partner 5. Nutzt diese, alles andere scheint aktuell eher Zeitverschwendung und bringt einen nur zur Weißglut.

Es ist frustig, frustig, frustig…

« Vorhergehende Seite