Why .NET?
-
Thanks, Marc! Now this is the most sensible thing I've read about .NET anywhere. And I'm not being ironic one bit (hard to tell in these posts). Thanks!!! You've actually made me quite interested in trying out these .NET things after all. And I can still go on writing any amount of stuff I want to in unmanaged code, right? Suddenly it doesn't seem like such a bad thing after all ... It still sort of bugs me that they had to build a virtual machine to do it though, but perhaps that was the best choice to be able to support more than just one language? Why couldn't they have done all of this with DLLs and some nice changes to the C++ standard (which seems to be barking up the wrong tree with all the template meta-programming stuff, if you ask me) ... Well that's what they tried with Java (change the standard) and it wasn't the way to go so they had to do come up with some new stuff I guess. Or is there some other profound reason behind the VM stuff? Why else make a VM and not just a framework? :confused: /Simon This is not a signature.
Simon Hofverberg wrote:
And I can still go on writing any amount of stuff I want to in unmanaged code, right? Suddenly it doesn't seem like such a bad thing after all ...
Yep. You can call into standard dlls. There's some overhead involved but as long as you keep your design reasonable (ie if calling DoFoo() a million times in a loop put the loop in a native function and only make a single marshalled call isntead of looping in C# and making a million of them) you can still get the bleeding edge native code performance where it's needed most. The biggest problem with adding more stuff to c++ is that after several decades of adding new features onto the specification the langauge itself's gotten extremely bloated with massive numbers of ways to do anything. Starting from scratch let them clean the spec up significantly, granted creaping featuritis is building again, but it's still a far cleaner spec than c++.
-
Thanks, Marc! Now this is the most sensible thing I've read about .NET anywhere. And I'm not being ironic one bit (hard to tell in these posts). Thanks!!! You've actually made me quite interested in trying out these .NET things after all. And I can still go on writing any amount of stuff I want to in unmanaged code, right? Suddenly it doesn't seem like such a bad thing after all ... It still sort of bugs me that they had to build a virtual machine to do it though, but perhaps that was the best choice to be able to support more than just one language? Why couldn't they have done all of this with DLLs and some nice changes to the C++ standard (which seems to be barking up the wrong tree with all the template meta-programming stuff, if you ask me) ... Well that's what they tried with Java (change the standard) and it wasn't the way to go so they had to do come up with some new stuff I guess. Or is there some other profound reason behind the VM stuff? Why else make a VM and not just a framework? :confused: /Simon This is not a signature.
Simon Hofverberg wrote:
And I can still go on writing any amount of stuff I want to in unmanaged code, right?
Yes, that's my understanding, though I've shied away from doing that myself because, if I recall correctly, the managed extensions specifications for C++ have changed. I may be totally wrong here, but I think they are now an official standard. Somebody else can give you more info on that than I.
Simon Hofverberg wrote:
It still sort of bugs me that they had to build a virtual machine to do it though, but perhaps that was the best choice to be able to support more than just one language?
That, and the JIT compiler can then generate native assembly code tuned to the processor you're using. That's the vision, who knows what the reality actually is. But it's a slick idea, abstracting the "compiler" output until the code is actually needed for execution.
Simon Hofverberg wrote:
Why couldn't they have done all of this with DLLs and some nice changes to the C++ standard
Because VM doesn't really have anything to do with the language, but the tool that converts the language into machine code.
Simon Hofverberg wrote:
Why else make a VM and not just a framework?
* Processor independence * One IL to rule them all (as you pointed out) * Possibly because it's intertwined with how managed code works Look at it this way. Let's say I write a GC framework in C++. You'd then have to use that framework to instantiate your classes. So, instead of saying
Foo foo=new Foo();which is the same in C# and C++, in C++, you'd have to say something likeFoo foo=ManagedFramework.MakeAFoo();. C++ doesn't specifically make type information available, does it? I guess that's what RTTI is good for. In C#, I could write a general instantiatorFoo foo=InstantiateMyClass(typeof(Foo));, and use the framework's reflection engine to create it (which is what XAML does, and my own MyXaml). I haven't looked at C++ in ages now and so I may be behind the times, but I really don't have a good idea of how that would be done in C++, not to mention all the stuff that has to go on to count the references of Foo and figure out when the things referencing Foo also go out of scope. The point is, there are things that simply can't be done with a framewo -
Airports or air traffic controll systems. If you mean the latter please tell me which airport because I will never fly there. Nunc est bibendum
-
I posted this in the General discussion forum, but it didn't quite stir up the flame war I expected. After seeing Vista and .NET and Microsoft's Response to Vista and .NET I figured this is the place to go. So ... I use MFC (though I don't particularly like it) and VC++ 6.0 (which I like very very much). I've spent a lot of time trying to figure out why Microsoft (and a whole lot of people affiliated or not affiliated with them) think that everyone should switch from native Win32 C++ development to .NET Framework-based development ... and I just can't figure out why. Things I know: Yes - the .NET framework has a load of nifty classes that I would have access to. Yes - it's quite possible to write native code mixed with .NET code in various ways. Yes - .NET code is/will be portable to other platforms. Yes - I understand fully that .NET is the way to go for a large range of applications (if I hear "web" or "business" bells start ringing). Things I don't know: But - why must Microsoft push it as the future for ALL applications? But - why should everyone be writing VM (Virtual Machine) code? It's quite possible to write a very good framework (platform independent even) that doesn't use a VM. Why doesn't Microsoft do that? And: And - I'm aware of the benefits of VMs. It's just that I'm also aware of the benefits of non-VM code - and to be honest I must admit that I really prefer non-VM code. /Simon This is not a signature.
Simon Hofverberg wrote:
why should everyone be writing VM (Virtual Machine) code?
I actually ignored the whole .Net and VM thing for a very long time, basically until recently. It doesn't cross over my job very often given speed of 3D graphics under .Net is significantly slower, I had to ignore it. However, technology changes, and techniques and software advance with lessons learned. After a recent presentation of Microsoft for using C# to write combo processing technology using the GPU as a streaming processor and the CPU as support processing, the idea caught on. I have used some of the streaming processor compilers for the GPU, they work well, but require two compilers and two different (slightly different) C varients for CPU/GPU and a lot of annoyances to combine them. By utilizing the same language, although not a public release of "accellerator", Microsoft took this to a level that caught my attention. I have always said I would learn another language "if" it had some value added it to it beyond just another syntax to learn. Microsoft Research did that, so I am learning. That being said, I still use C++ in native code for 3D graphics. I doubt that will change anytime in the future. I'll be going up against several other big-names in 3D graphics visualization this year and performance is my strongest selling point. But I will also be learning C# and .Net finally, it's become something that will be valuable even in the specialty work I do. http://research.microsoft.com/research/pubs/view.aspx?type=technical%20report&id=1040[^] who knows? maybe I will put together a 4 dual-core processor machine with 4 GPUs and have my own mini super-computer solution solver.... :rolleyes: _________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Depends on how you define mission critical, if your aircraft maintenance system goes down, the planes dont get maintained. If your air traffic control system goes down, people start dying. Thats my definition of mission critical. You obviously dont have much Windows experiance, or SW experience; Windows does not randomly change data. So a plane would not get the wrong amount of fuel. What Windows does do, particularly with hardware, and particularly because of the plug and play system, is occaisonally do something very odd like not see a device, or randomly autoplay a USB device, or something like that. It is for that reason I would never trust windows for a mission critical system. Nunc est bibendum
fat_boy wrote:
If your air traffic control system goes down, people start dying.
Wrong, resort to other means.
fat_boy wrote:
What Windows does do, particularly with hardware, and particularly because of the plug and play system, is occaisonally do something very odd like not see a device, or randomly autoplay a USB device, or something like that.
What a strange reasoning for not choosing windows for a mission critical system, I blame the author of device drive myself. Blogless
-
fat_boy wrote:
If your air traffic control system goes down, people start dying.
Wrong, resort to other means.
fat_boy wrote:
What Windows does do, particularly with hardware, and particularly because of the plug and play system, is occaisonally do something very odd like not see a device, or randomly autoplay a USB device, or something like that.
What a strange reasoning for not choosing windows for a mission critical system, I blame the author of device drive myself. Blogless
-
Well, looks like you're homebound. Anyway for somebody who writes 'Device drivers for Windows' you seem a bit negative towards windows :confused: Blogless -- modified at 9:39 Thursday 16th March, 2006
With very good reason. I spend a lot of time in the guts of windows, and I have seen some of the strangest behaviour. Some due to windows, some to third party software, and some due to hardware (there is a lot of variety among the architecture of laptops compared to desktops). We also find bugs in the kernel. We found two this year. One resulting in a blue screen, the other, the PC wouldnt suspend. Microsoft owned up to both of them. I think windows is an excellent OS for general use. It isnt well suited to hardware control though, its interrupt latency is too long compared to other OSs. For a mission critical system I would deffinitely look elsewhere. I might even considder NT4, at least it hasne got PnP and power management, the two real problems in XP, but even it isnt perfect. Nunc est bibendum
-
Yeah, the Ndis driver is really neat. The cards have a PPP stack on then to mimic an ISP to get windows dial up working, although over the network, it is actually GSM RF protocol etc. So, the Ndis driver stokes up the PPP stack on the card, does all the LCP, PAP, CHAP, IPCP stuff, then, tells the system the cable is connected. It then gets DHCP messages from the PC which the driver responds to with the IP address it got from IPCP. It also satisfies ARP messages with faked MAC addresses. Also, it has to do Ethernet to PPP reframing of the data packets, so, IP, PPP, UDP check sum calculation, escaping chars below 0x1F, MD5 encryption for the CHAP data, etc. The LCP/CHAP/IPCP handling code alone is 4000 lines! Yep, there is a lot of real coding there, protocols, constructing packets, real maths, and windows system knowledge. Thats what I call real software engineering! Nunc est bibendum
Have you ever had to place a work order with your employer to have the doors widened so you could move from to room? ;P All kidding aside, some of that stuff sounds absolutely fun. My Programming Library 'Even a good developer can easily write bad code in VB.NET'.--Off The Record
-
Have you ever had to place a work order with your employer to have the doors widened so you could move from to room? ;P All kidding aside, some of that stuff sounds absolutely fun. My Programming Library 'Even a good developer can easily write bad code in VB.NET'.--Off The Record
-
Yeah, the Ndis driver is really neat. The cards have a PPP stack on then to mimic an ISP to get windows dial up working, although over the network, it is actually GSM RF protocol etc. So, the Ndis driver stokes up the PPP stack on the card, does all the LCP, PAP, CHAP, IPCP stuff, then, tells the system the cable is connected. It then gets DHCP messages from the PC which the driver responds to with the IP address it got from IPCP. It also satisfies ARP messages with faked MAC addresses. Also, it has to do Ethernet to PPP reframing of the data packets, so, IP, PPP, UDP check sum calculation, escaping chars below 0x1F, MD5 encryption for the CHAP data, etc. The LCP/CHAP/IPCP handling code alone is 4000 lines! Yep, there is a lot of real coding there, protocols, constructing packets, real maths, and windows system knowledge. Thats what I call real software engineering! Nunc est bibendum
fat_boy wrote:
IP, PPP, UDP check sum calculation
Doesnt your hardware support checksum offloading ? Actually it is a pain to work with NDIS for non-ethernet type networks (for example 802.11) We wanted to scan the 802.11 medium for beacons for monitoring purposes - we cant write a standard NDIS miniport. I assume you are working directly with the vendor and writing a custom miniport with private interfaces. In any case your work sounds cool, nothing like driver development.
-
With very good reason. I spend a lot of time in the guts of windows, and I have seen some of the strangest behaviour. Some due to windows, some to third party software, and some due to hardware (there is a lot of variety among the architecture of laptops compared to desktops). We also find bugs in the kernel. We found two this year. One resulting in a blue screen, the other, the PC wouldnt suspend. Microsoft owned up to both of them. I think windows is an excellent OS for general use. It isnt well suited to hardware control though, its interrupt latency is too long compared to other OSs. For a mission critical system I would deffinitely look elsewhere. I might even considder NT4, at least it hasne got PnP and power management, the two real problems in XP, but even it isnt perfect. Nunc est bibendum
fat_boy wrote:
at least it hasne got PnP and power management, the two real problems in XP
We'll these issues would of been addressed in Vista, maybe Microsoft, should come up with a version of Windows which is Clean, that is all the unnecessary application features have been removed and maybe a streamlined kernel, just a thought Blogless
-
fat_boy wrote:
IP, PPP, UDP check sum calculation
Doesnt your hardware support checksum offloading ? Actually it is a pain to work with NDIS for non-ethernet type networks (for example 802.11) We wanted to scan the 802.11 medium for beacons for monitoring purposes - we cant write a standard NDIS miniport. I assume you are working directly with the vendor and writing a custom miniport with private interfaces. In any case your work sounds cool, nothing like driver development.
No, The device actually responds top AT commands untill ATDT*((# is sent, whereupon it switch es to PPP mode, and all it will accept is PPP packets, so no task offload there.
Vivek Rajan wrote:
802.11
We had a driver too for 802.11 for NT 4. OK, so Ndis 4 doesnt know about 802.11, but, with a custom protocol driver, custom app, and 802.11 to 802.3 reframing, it worked great.
Vivek Rajan wrote:
directly with the vendor
Yep, custom miniport driver, talks to the bus driver on the bottom edge, so read/write/control Irps, 802.3 on the top edge, with a custom IOCTL interface to get connection data to the driver, and trace data back up to the app. I am on site almost all the time, and its an on going deal. For example, there is Vista, 64 bit XP, new hardware, new speeds etc. Its a fast moving business. Nunc est bibendum
-
fat_boy wrote:
at least it hasne got PnP and power management, the two real problems in XP
We'll these issues would of been addressed in Vista, maybe Microsoft, should come up with a version of Windows which is Clean, that is all the unnecessary application features have been removed and maybe a streamlined kernel, just a thought Blogless
-
Simon Hofverberg wrote:
And I can still go on writing any amount of stuff I want to in unmanaged code, right?
Yes, that's my understanding, though I've shied away from doing that myself because, if I recall correctly, the managed extensions specifications for C++ have changed. I may be totally wrong here, but I think they are now an official standard. Somebody else can give you more info on that than I.
Simon Hofverberg wrote:
It still sort of bugs me that they had to build a virtual machine to do it though, but perhaps that was the best choice to be able to support more than just one language?
That, and the JIT compiler can then generate native assembly code tuned to the processor you're using. That's the vision, who knows what the reality actually is. But it's a slick idea, abstracting the "compiler" output until the code is actually needed for execution.
Simon Hofverberg wrote:
Why couldn't they have done all of this with DLLs and some nice changes to the C++ standard
Because VM doesn't really have anything to do with the language, but the tool that converts the language into machine code.
Simon Hofverberg wrote:
Why else make a VM and not just a framework?
* Processor independence * One IL to rule them all (as you pointed out) * Possibly because it's intertwined with how managed code works Look at it this way. Let's say I write a GC framework in C++. You'd then have to use that framework to instantiate your classes. So, instead of saying
Foo foo=new Foo();which is the same in C# and C++, in C++, you'd have to say something likeFoo foo=ManagedFramework.MakeAFoo();. C++ doesn't specifically make type information available, does it? I guess that's what RTTI is good for. In C#, I could write a general instantiatorFoo foo=InstantiateMyClass(typeof(Foo));, and use the framework's reflection engine to create it (which is what XAML does, and my own MyXaml). I haven't looked at C++ in ages now and so I may be behind the times, but I really don't have a good idea of how that would be done in C++, not to mention all the stuff that has to go on to count the references of Foo and figure out when the things referencing Foo also go out of scope. The point is, there are things that simply can't be done with a framewoMarc Clifton wrote:
So, I hope I'm not totally munging the understanding of the reasons/technology for you
Definitely not. Thanks again! The good thing about MS is that quite often they've done some very right things. :wtf: The really bad thing about MS is that every single time they refuse to tell you why they have done something and instead they drown you in a flood of marketing ******** and hope that you are going to do what they say because they say it instead of doing it because you agree with them ... X| /Simon This is not a signature.
-
Depends on how you define mission critical, if your aircraft maintenance system goes down, the planes dont get maintained. If your air traffic control system goes down, people start dying. Thats my definition of mission critical. You obviously dont have much Windows experiance, or SW experience; Windows does not randomly change data. So a plane would not get the wrong amount of fuel. What Windows does do, particularly with hardware, and particularly because of the plug and play system, is occaisonally do something very odd like not see a device, or randomly autoplay a USB device, or something like that. It is for that reason I would never trust windows for a mission critical system. Nunc est bibendum
fat_boy wrote:
If your air traffic control system goes down, people start dying. Thats my definition of mission critical.
But for an airport manager that is only a part of the job, getting the right things and the right passengers to the right planes every time and all the time is also mission critical. Or a JIT car production line making sure the right parts are available at the right time, neither to soon nor too later, is mission critical. Or many other types of applications that have to do their job correctly all the time and for very long periods of time.
fat_boy wrote:
Windows does not randomly change data. So a plane would not get the wrong amount of fuel.
No it doesn't, and that's precisely why it's used such software. But suppose the somewhere in the software, written in some native language, someone forgets to initialize a variable. That could cause random values to end up who knows where, or not? Or suppose somewhere in the software something causes a small memory leak? It could take a long time before such a bug causes a problem but give it enough time, and some management applications run non-stop for years, and it will be a problem. Suppose it's an application controlling a factory production line, would you go to the factory manager and say "I'm sorry, could you stop the factory for a few minutes while we reboot the server?" Or what if someone assumed some string would never have more than say 5 bytes and some user types in 20, crashes the application and brings the airport to an halt? And in many cases performance isn't an issue so there's little or no advantage in choosing C or C++ over Java or C#, especially since with Java or C# development times are usually shorter, which, for bussiness, is a huge advantage. Quidquid latine dictum sit, altum viditur.
-
I posted this in the General discussion forum, but it didn't quite stir up the flame war I expected. After seeing Vista and .NET and Microsoft's Response to Vista and .NET I figured this is the place to go. So ... I use MFC (though I don't particularly like it) and VC++ 6.0 (which I like very very much). I've spent a lot of time trying to figure out why Microsoft (and a whole lot of people affiliated or not affiliated with them) think that everyone should switch from native Win32 C++ development to .NET Framework-based development ... and I just can't figure out why. Things I know: Yes - the .NET framework has a load of nifty classes that I would have access to. Yes - it's quite possible to write native code mixed with .NET code in various ways. Yes - .NET code is/will be portable to other platforms. Yes - I understand fully that .NET is the way to go for a large range of applications (if I hear "web" or "business" bells start ringing). Things I don't know: But - why must Microsoft push it as the future for ALL applications? But - why should everyone be writing VM (Virtual Machine) code? It's quite possible to write a very good framework (platform independent even) that doesn't use a VM. Why doesn't Microsoft do that? And: And - I'm aware of the benefits of VMs. It's just that I'm also aware of the benefits of non-VM code - and to be honest I must admit that I really prefer non-VM code. /Simon This is not a signature.
I started on C/C++ in the early 80's and continued until the second beta of .NET 1.0 when I switched to C#/.NET. Well, "switched" may be putting it lightly, I have had complete dread to even work on anything C/C++ related after spending just a few weeks with .NET 1.0. The two most important features of C#/.NET, the first is the clean framework classes which handle just about anything I would want to do and the second is the lack of debugging my applciations require. You could always build a nice framework that may handle most of .NET in a C/C++ world, but you would STILL be in a C/C++ world. There is no way to count the number of hours spent in C/C++ code searching out simple little typos that caused the application to crash with little if no clue as to where the problem was at. Shoot, just not paying attention to a change in DLL would crash you every which way and possibly cause you hours if not days to troubeshoot in a production system. I bet in the last four years in C#/.NET I have spent less than 50 hours in total, actually debugging anything, where in C/C++ that would be hit on apps of any decent size in just a month or two. Talk about time savings! There are some gotchas when you first start, but after you are past those, development comes pretty smoothly. In short, it is the productivity that I have gained in C#/.NET that is of value to me above all, followed closely by security and expandability. There are many reasons that I am hard core dedicated C#/.NET after about two decades of C/C++, but these are the most important. Rocky <>< Latest Post: SQL2005 Server Managemnet Studio timeouts! Blog: www.RockyMoore.com/TheCoder/[^]
-
fat_boy wrote:
If your air traffic control system goes down, people start dying. Thats my definition of mission critical.
But for an airport manager that is only a part of the job, getting the right things and the right passengers to the right planes every time and all the time is also mission critical. Or a JIT car production line making sure the right parts are available at the right time, neither to soon nor too later, is mission critical. Or many other types of applications that have to do their job correctly all the time and for very long periods of time.
fat_boy wrote:
Windows does not randomly change data. So a plane would not get the wrong amount of fuel.
No it doesn't, and that's precisely why it's used such software. But suppose the somewhere in the software, written in some native language, someone forgets to initialize a variable. That could cause random values to end up who knows where, or not? Or suppose somewhere in the software something causes a small memory leak? It could take a long time before such a bug causes a problem but give it enough time, and some management applications run non-stop for years, and it will be a problem. Suppose it's an application controlling a factory production line, would you go to the factory manager and say "I'm sorry, could you stop the factory for a few minutes while we reboot the server?" Or what if someone assumed some string would never have more than say 5 bytes and some user types in 20, crashes the application and brings the airport to an halt? And in many cases performance isn't an issue so there's little or no advantage in choosing C or C++ over Java or C#, especially since with Java or C# development times are usually shorter, which, for bussiness, is a huge advantage. Quidquid latine dictum sit, altum viditur.
Well, we are discussing Windows's suitability for Mission Critical situations, not .Net. As for the rest of your post, regardless of the OS, bad code is bad code, for example, a 16 bit overflow brought down the Arianne rocket some years ago. Still, Windows is not good enough for mission critical applications. The US Navy tried with NT4 (and its a lot better than XP), and still their Friggate was dead in the water for days. And anyway, XP is a user oriented, game oriented, hot plugging hardware, kind of machine. This in itself is almost useless in a mission critical situation, or, even a producrtion line for cars. So why do it? Why not just run a minimal 'something else', PDP11, AS400, Unix, even, perhaps, NT4. Any of these will offer all you need for process control, (Unix is better than NT4 for the reason of interrupt latency, and for some process controll situations this is inmportant). Nunc est bibendum
-
Marc Clifton wrote:
So, I hope I'm not totally munging the understanding of the reasons/technology for you
Definitely not. Thanks again! The good thing about MS is that quite often they've done some very right things. :wtf: The really bad thing about MS is that every single time they refuse to tell you why they have done something and instead they drown you in a flood of marketing ******** and hope that you are going to do what they say because they say it instead of doing it because you agree with them ... X| /Simon This is not a signature.
Simon Hofverberg wrote:
is that every single time they refuse to tell you why they have done something and instead they drown you in a flood of marketing ********
:-D That's what sites like this are for. To get you grounded with useful info. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
-
It's a tool, not a religion. Use the tool you feel appropriate for the job, but know how to use all the tools in your toolchest. Marc Pensieve Functional Entanglement vs. Code Entanglement Static Classes Make For Rigid Architectures
-
I posted this in the General discussion forum, but it didn't quite stir up the flame war I expected. After seeing Vista and .NET and Microsoft's Response to Vista and .NET I figured this is the place to go. So ... I use MFC (though I don't particularly like it) and VC++ 6.0 (which I like very very much). I've spent a lot of time trying to figure out why Microsoft (and a whole lot of people affiliated or not affiliated with them) think that everyone should switch from native Win32 C++ development to .NET Framework-based development ... and I just can't figure out why. Things I know: Yes - the .NET framework has a load of nifty classes that I would have access to. Yes - it's quite possible to write native code mixed with .NET code in various ways. Yes - .NET code is/will be portable to other platforms. Yes - I understand fully that .NET is the way to go for a large range of applications (if I hear "web" or "business" bells start ringing). Things I don't know: But - why must Microsoft push it as the future for ALL applications? But - why should everyone be writing VM (Virtual Machine) code? It's quite possible to write a very good framework (platform independent even) that doesn't use a VM. Why doesn't Microsoft do that? And: And - I'm aware of the benefits of VMs. It's just that I'm also aware of the benefits of non-VM code - and to be honest I must admit that I really prefer non-VM code. /Simon This is not a signature.
Well, arrival of .NET was obvious since most of the % of developers on MS platform was of VB developers which had limitations though. But .NET removed the problems and complaints about VB developers. Everyone know that its .NET which breaked the market of Java and its really powerful. But every application has to choose a language/technology. C++ is still good for low level applications like device drivers etc. Maybe, only that knows the pain who has felt it. Sameers Need custom software? Contact DevelopersINN[^] Need to add reminders for your Outlook emails? Try Outlook Personal Assistant[^]