# Native Code > برنامه نویسی در Delphi > برنامه نویسی در Delphi Prism >  Galileo IDE Framework

## Inprise

Allen Bauer از مردان اصلی و تصمیم ساز بورلند ؛ طی دو نوشته جالب تو وبلاگش ؛ نکات مهمی در مورد تصمیمات بورلند و روند های آتی نوشته که مطالعه اش خالی از لطف نیست :

<span dir=ltr>OK.. I've have a few days to digest, mull over, and otherwise consume Julian's post regarding the reasons Delphi should be migrated into Visual Studio.آ  All in all it was a well reasoned article and on the surface it looks like a “no-brainer.”آ  However, I'm going to toss the proverbial “spanner” into the works.

First of all, does anybody really think that Borland hasn't ever looked into what it would look like for Delphi to be hosted in the Visual Studio IDE?آ  I mean, we're in business to make money.آ  And as much of it as we think we can.آ  It only makes sense to explore every avenue of opportunity, no matter what you're emotional ties are to a particular way of doing things.آ  Of course I cannot comment on anything specific regarding any kinds of future plans regarding Delphi and Visual Studio.آ  I will however outline a few things in order to dispell several myths surrounding the notion that moving to VS somehow magicallyآ gives us a huge boost.

First, lets outline some rules of engagement.آ  First of all, I'm not talking about a “Delphi language plug-in.”آ  On the surface that seems like a very simple andآ “no-brainer” kind ofآ thing to do.آ  However, I'm not interested in having Delphi be simply another “also-ran” in the sea of Visual Studio plugins and third-party languages.آ  Delphi has an identity all its own,آ both in its market and its overall look and feel.آ  Delphi would have to retain a lot of this identity.آ  This raises the bar to a level beyond simply installingآ Delphi into an existing VS installation.آ  Yes, Microsoft does offer a program that allows third-parties to deliver and install the core VS bits in addition to that vendor's specific enhancements.آ  The problem is that it still has the Microsoft identity plastered all over it in such a way that Delphi would still be relegated to “also-ran” status.

OK, so we've outlined some of the up-front intangible costs associated with moving Delphi into VS.آ  Now lets looks at some of the real costs.آ  Let's define what Visual Studio really is.آ  Basically, VS is simply a shell that provides some core services,آ such as a text editor, menu and window/docking management, some core-debugger services, and some core project management services.آ  Other things like the compilers, expression evaluators, syntax highlighting, Intellisense, etc.. are all items that are pushed out to the “language plug-in”آ  These are things Borland would have to provide.آ  What about the designers, like the WinForm, آ ASP.NETآ  and let's throw in the CF designers?آ  So far it is unclear whether or not these items are actually part of the core VS redist bits.آ  Especially the CF designer bits.آ آ You know that it won't include any kind of support for VCL (Win32 or .NET), so that is something only Borland can provide.آ  Then there is the notion of the smart device emulators (for running and debugging CF applications without the need for a physical device).آ  These don't come with the core VS redist bits.

So far, you might be saying, “So? Just require that the user purchase VS to get all those extra bits.”آ  Hmm... good idea... not! How can we, with a straight face, tell our customers, you, that you need to toss a chunk of cash at MS and at Borland?آ  No, you want to buy one product, install it, and be good to go.آ  So then we're stuck with selling into VS shops, which has it's own brand of issues... well you get the picture.

So let's do a little math and check the score:

Visual Studio Core

Editor 
Debugger (Win32/.NET/CF) 
Menus/Windows/docking 
Project Manager 
Galileo Core (present Delphi IDE core)

Editor 
Debugger(Win32/.NET). 
Menus/Windows/docking 
Project Manager
I'm sure that's not quite an exhaustive list, but you get the idea here.آ  There are probably several things that the Galileo core provides that the VS core does not, and vice versa.آ  Now let's look at what Borland must supply:

Visual Studio Core

Delphi Compilers (.NET &amp; Win32) 
Delphi language bindings (syntax highlighting, error insight, Intellisense, etc...). 
ASP.NET Designer 
WinForm designer. 
Expression evaluator (for debugging). 
VCL design-time package management 
VCL/Win32 Designer 
VCL/.NET Designer 
CodeDOM 
ECO 
Modelling 
Refactoring engine and code for specific refactorings
Galileo Core

Delphi Compilers (.NET &amp; Win32) 
Delphi language bindings (syntax highlighting, error insight, Intellisense, etc...). 
ASP.NET Designer 
WinForm Designer 
Expression evaluator (for debugging). 
VCL design-time package management 
VCL/Win32 Designer 
VCL/.NET Designer 
CodeDOM 
ECO 
Modelling 
Refactoring engine and code for specific refactorings
Hm... That's interesting.آ  I'm not seeing the advantage here.آ  The VS core and the Galileo core are essentially done.آ  They're sunk costs.آ  What the above list doesn't depict is the team cost involved in just moving what we have today onto VS.آ  Thatآ would be a very large task to just get to where we are today.آ  That doesn't include any new features.آ  Sure, there would be some increase in feature-set simply from the move to VS, but what those features would be I can't sayآ because I don't know.آ  Yes, we'd be freed from the task of maintaining the IDE core, but to put that into perspective, in the Delphi 2005 product release, I imagine that there was only about 1-2 man-months of real core IDE work.آ  There was some core work to add some features, but quite honestly these were features that would not have come fromآ some VS core either.

Now comes the argument, “what about all those third-party VS add-ons you can now leverage?”آ  Sounds great, in theory, however in practice I'm much more skeptical.آ  I know how development works and I know developers.آ  I can see that the following scenario would become all too common:آ  I install some whiz-bang VS add-on and point it at some Delphi source file.آ  I tell the add-in to “do it's thing”... Now I watch in horror as I see C#‎ or VB code injected into my Delphi source code module!آ  Then there's this one, I try and pointآ some hot new add-in at the VCL form designer, and all it can do is sit there twiddling it's thumbs.

How about, “what happens if MS slips the next release of VS?“آ  Well that's a good question.آ  Borland has a fiduciary responsibility to its stockholders to be profitable.آ  Much of that ability to make a profit is being in control of one's own destiny.آ  If we cannot meet revenue targets, we let down not only ourselves and our customers, but also our stockholders.آ  So now we're relegated into always delivering on the previous rev of VS.آ  Not a very attractive prospect in today's market.آ  Of courseآ we may end upآ wrestling withآ a very similarآ issue with the recentآ unsubstantiated rumorآ that MS has slipped the delivery of .NET 2.0 into late summer or early fall of 2005!

Here's another one I've heard, “Oh that Allen guy is the Galileo IDE architect.آ  He's just protecting his code and his job.”آ  No.آ  I'd like to think that I'm not that shallow or egocentric.آ  Sure I have an ego, and it can be bruised, but I'm also very pragmatic.آ  As soon as I see the benefit toآ Delphi, the product, and to Borland the company, you bet I'd be on board.

Finally, and I hesitate to even mention this because it tends to bring out the worst in folks, there is the notion of whether or not our existing Delphi customers would accept a Delphi release built on VS?آ  What would they be willing to pay?آ  What if they already have VS, do they pay the same price?آ  These are not questions I'm prepared to answer or even profess to to answer.آ  I know what my gut tells me.آ  I'm a developer, so I'd like to think I know developers and have a little insight into what makes them tick.آ  We share much of the same passions and ideas.آ  I don't know, maybe the Delphi folks will surprise me.

Oh.. BTW, Julian used to work for Microsoft in the Visual Studio group... but, he, as am I, are certainly not biased in any way ;-)..</span>


و در ادامه :

<span dir=ltr>One item in my previous post that I specifically didn't address is the notion of using Eclipse instead of VS.  Again, this is something we'd be remiss to ignore.  However, the primary ding against Eclipse is its reliance on a JVM.  Were it not for the fact that we are trying to support the .NET platform, this might be a reasonable path to persue.  I just don't see how we could create a reasonable tool that hosted not only the JVM, but also the CLR in the same process!  Yes, Eclipse would be much less encumbering from a business perspective than VS, but I have to think about the developer experience.  I, as a developer, would find it very hard to swallow if I had an IDE that fired up both the JVM and CLR in process.

Much of the same issues surrounding what does Eclipse give us and what we'd still have to build.  In fact you can substitute Eclipse for VS in much of this post.  Of course some of it doesn't apply, but you can get and idea of the scope of things involved.

Finally there is the shear fact that there is nearly 12 years invested in a lot of the current Delphi/Galileo IDE codebase.  It's not perfect.  It has some rough edges.  However, I will point out that it was also the first IDE framework ever released by Borland that supports multiple languages out of the box.  I owe a lot of this to the dedication and talent that we have and have had on the Delphi team.  Now we've announced our intention of folding C++‎Builder into the Galileo IDE, which has only been made possible due to the work we'd been doing over the past 2-3 years.</span>


موفق باشید

----------


## vcldeveloper

> folding C++‎Builder into the Galileo IDE


انشاء الله کی؟  :موفق:      توی Delphi 2005 که خبری از ++C نبود

----------


## Vahid_Nasiri

ترکیب دلفی با VS.NET ، ترکیب جالبی خواهد شد.  :evil2:

----------


## مهدی کرامتی

> <span dir=ltr>I, as a developer, would find it very hard to swallow if I had an IDE that fired up both the JVM and CLR in process.</span>


من یک چیزی رو متوجه شدم. IDE دلفی 2005 در خیلی از موارد Unicode رو پشتیبانی نمیکنه، و این شاید بخاطر اینه که با Win32 Framework نوشته شده و Win32 هم یونیکد رو خوب پشتیبانی نمیکنه. 

دلیل انتخاب این Framework هم این بوده که با توجه به نقل قول فوق ترجیح داده شده که IDE برای بالا آمدن نیازی به هیچ چیز دیگری مثل CLR یا JVM نداشته باشه.

اما عدم پشتیبانی یونیکد، بخصوص در IDE ای که قرار با دات نت و بخصوص ASP.NET کار کنه مشکل بزرگی محسوب میشه.

گذشته از این، من هنوز نمیتونم برای خودم توجیه کنم که چرا درایورهای BDP یونیکد رو پشتیبانی نمیکنند.

----------


## Inprise

> IDE دلفی 2005 در خیلی از موارد Unicode رو پشتیبانی نمیکنه


چند تا مثال میزنی ؟




> شاید بخاطر اینه که با Win32 Framework نوشته شده و Win32 هم یونیکد رو خوب پشتیبانی نمیکنه.


Galileo مبتنی بر دات نت است . نسخهء Wی تمام API ها برای سازگاری با یونیکد توسعه داده شده اند و با توجه به عدم حمایت مایکروسافت از ویندوزهای قبل از 2000 و حتی توقف حمایت امنیتی از ویندوز 2000 سرور ، به نظر میرسه توسعهء Unicode با Win32 مشکل خاصی نداشته باشه . ( فی الواقع دات نت هم روی چیزی بجز Win32 و COM ساخته نشده ) خطی که نقل قول کردی ، عکس العمل آلن نسبت به کامنتهای وبلاگش است . او سعی کرده با مقایسهء Eclips و VS بگه ، بورلند بجای این دو مسیر ، روش خودش رو ادامه میده . یعنی بجای نوشتن پلاگین ، محیطهای توسعه مجتمع خواهد ساخت ؛ این تلاش به نظر حقیر حداقل روی جاوا موفقیت آمیز بود . آلن معتقده محیط توسعهء دلفی مزیتهای خاصی نسبت به VS داره ( که در برخی از موارد واقعا" هم همینطور هست ) و ضمنا" اعتراف میکنه این ، هنوز یک چیز نهائی برای تکیه کردن نیست . در واقع بورلند مایله یه IDE Framework داشته باشه که بشه بدون "اختصاص یافتن مطلق" به CLR یا JVM ، بشه ازش استفاده کرد ؛ و بخش آخر مطالبش هم ناظر بر همین مطلب است که : نسخهء آتی BCB روی همین IDE Framework سوار خواهد شد .

نظرات شخصی من :

قبلا" نظرم رو در مورد دات نت گفتم . خوبه ؛ اما فقط کسانی رو شگفت زده میکنه که قبل از اون "حداکثر" یک توسعه گر ویژوال بیسیک بودند . تلاش بورلند برای حمایت دات نت ؛ بیشتر تجاری است تا فنی . قبلا" به تفصیل در موردش حرف زده شده ؛ بورلند همیشه یک لشگر مشتری ِ راضی ِ جاوا کار داشته و داره ؛ طبیعیه که حمایت قوی از دات نت که بهر حال آیندهء سیستمهای شخصی - که با ویندوز پیوند خورده اند - را تحت تاثیر قرار خواهد داد ، یک تصمیم اقتصادی دوراندیشانه است . همونطور که از ظواهر حرفهای آلن میشه فهمید ، اونها به چیزی که فعلا" میفروشند اعتقاد خاصی ندارند . در واقع لحن آلن در مقابل انتقاداتی که تو کامنتهای وبلاگش وجود داره ، یک لحن توجیه کنندهء " بابا حالا بیخیال"- گونه است . اگر بخوام ارزیابی ام از فعالیتهای دو سال اخیر بورلند رو توی چند خط بنویسم : حمایت از JSF و توسعهء ECO پر رنگترین روندهای مثبت ، و عدم شفاف بودن سیاستها در مورد محصولاتش و پاسخگوئی مبهم و غیر مسئولانه ، و گشاد بازی در زمینه رفع نواقص ذاتی VCL از موارد پر رنگ منفی خواهند بود . درک ارزش و اهمیت ECO منوط به درک ارزش توسعه مبتنی بر مدل و طراحی است و من نمیتونم ندیده اش بگیرم . سرعت توسعه برنامه های دات نت هم با دلفی دات نت فوق العاده بالاست . در واقع میتونم ادعا کنم هر کاربردی رو با دلفی دات نت ؛ میشه سریعتر از Managed C یا سی شارپ توسعه داد . خیلی از دوستانم این روزها در مورد دلفی دات نت ازم سوال میکنن و من دقیقا" ایدهء خودم رو بهشون پیشنهاد میکنم ؛ یعنی بررسی و کاربرد Educational . حتی اگر در مورد دات نت هم از من سوال کنند ؛ برای شروع یک پروژه بزرگ توصیه اش نمیکنم ؛ دلیلش رو اگر خاطرت باشه تو یه بحثی با حضور حضرت حاج کامبیز (ع) بررسی کردیم . دو تا واقعیت آزار دهنده تو ذهن من وجود داره ؛ اول : هر چیزی که به نوعی به مایکروسافت و تکنولوژیهایش مربوط میشه ( از یک سرویس RPC ناقابل گرفته تا یک بستر برای توسعه نرم افزار ) یکنوع حماقت / سردرگمی ذاتی توش وجود داره . دوم : همیشه یک اقلیت هوچی گر و کم مایه ، با استفاده از ظواهر و الفاظ ، بر اکثریت آدمها حکومت کردند ؛ گویا این یک سنت همیشگی است . جمع این دو واقعیت ، من رو همون ایدهء قدیمی میرسونه که توان اصلیم رو به چیزهائی که بهشون "اعتقاد" دارم معطوف کنم ؛ و در کنار اون از چیزهائی که - بهر حال - باید پذیرفتشون غافل نباشم . فکر میکنم رویکرد صحیح در این مورد خاص - دلفی و دات نت و تلفیق این دو و ...- هم همین باشه ؛ و البته :

 :sorry:

----------


## Inprise

ویژگیهای نسخهء بعدی BCB از BDNRadio :

- حمایت از Win32
- مبتنی بر گالیلئو
- افزایش حمایت از COM و ویژگیهای جدید ویندوزهای اکس پی و 2003
- افزایش کیفیت کامپایلر و لینکر
- افزایش حمایت از توسعه Device Driver ها

بورلند مدعی است محصول بعدی اش ؛ بصورت همزمان از Delphi و #C و BCB حمایت میکنه و امکان توسعهء Mixed Code اونجا موجود خواهد بود . این قولیه که شش ماه قبل ، برای اول سال میلادی جاری داده بود ؛

----------


## مهدی کرامتی

> چند تا مثال میزنی ؟


در کامپونتهای DataAdapter از سری BDP روی گزینه Preview Data (از منوی Popup اش) کلیک کن و سعی کن بانکی که اطلاعات یونیکد (فارسی) در آن ذخیره شده را مرور کنی.

همچنین سعی کن داده های یونیکد موجود در بانک رو توسط Data Reader های BDP بخونی.

----------


## vDelphi

در مورد #C آیا بورلند قصد ساخت یک کامپایلر اختصاصی برای #C را داره؟

----------


## Inprise

> سعی کن بانکی که اطلاعات یونیکد (فارسی) در آن ذخیره شده را مرور کنی.


الان امکان تست ندارم اما از یک دوست که برنامه هاش رو به زبان روسی مینویسه سوال کردم و گفت دادهائی که بصورت یونیکد ( روسی ) تو اینتربیس ذخیره کرده قابل جستجو و پیمایش هستند ؛ از کدام بانک استفاده کردی و اطلاعات رو چطوری ذخیره کردی ؟




> بورلند قصد ساخت یک کامپایلر اختصاصی برای #C را داره؟


خیر .

---

 
Delphi 2005 - Top Ten Reasons to Buy

----------


## مهدی کرامتی

> از کدام بانک استفاده کردی و اطلاعات رو چطوری ذخیره کردی ؟


از SQL Server و بصورت UTF-8 with Signature

----------


## hr110

سلام
جناب اینپرایز،
ببخشید که من میان بحث وارد شده ام، ولی هنوز برای من یکسری از مطالب کاملاً روشن نشده و سوالاتی در ذهنم باقی مانده است، که امیدوارم با درایت و اطلاعات کاملی که دارید این جانب و افراد دیگری که در برزخ گیر کرده اند راهنمایی بفرمایید؛

با توجه به بررسیهایی که از طریق سه نفر از دوستانم که در امریکا و اروپا در زمینه نرم افزار کار و تحصیل مینمایند، داشتم.همگی به این مسئله اعتراف میکند که دلفی اواخر عمر خود را میگذراند و تیمهای بسیار کمی در این زمینه فعالیت میکنند و بیشتر پروژه ها بعد از جاوا با استفاده از VC انجام میشود؟ البته نه اینجانب و نه کس دیگری شک در قدرتمند بودن بورلند نداشته و نخواهیم داشت، ولی گویی دستهایی در پشت صحنه مشغول به فعالیت میباشند و قصد از دور خارج کردن دلفی را دارند.

----------


## Inprise

> گویی دستهایی در پشت صحنه مشغول به فعالیت میباشند و قصد از دور خارج کردن دلفی را دارند


من اینطور فکر نمیکنم .





> همگی به این مسئله اعتراف میکند که دلفی اواخر عمر خود را میگذراند


بسیاری از نرم افزارهائی که بصورت روزمره ازشون استفاده میکنی با دلفی نوشته شده اند ؛ از آنتی ویروسی مثل پاندا تا نرم افزارهای مدیریتی مثل محصولات GFI تا برنامه هائی مثل MySQL Manager و ...بسیاری از برنامه های کاربردی متداول . شرکتهائی مثل اریکسون و موتورولا هم حداقل روی ویندوز بطور کامل از محصولات بورلند استفاده میکنند ( BCB و دلفی ) اما بازار جدی کاربرد دلفی محصولات مبتنی بر بانکهای اطلاعاتی است ؛ بی تعارف حداقل بین محصولاتی که من خارج از ایران از نزدیک زیارتشون کردم و از محیط توسعه شون خبر دارم ؛ VC هیچ رتبه ای نداره و جاوا رو روی پروژه های کوچک و متوسط استفاده نمیکنند . کاربرد دلفی فوق العاده وسیعتر از اونه که حتی با اغراق بتونی تصورش کنی . به عنوان مثال "ناتو" نرم افزارهای فوق العاده قدرتمندی برای پردازش تصویر و صوت داره که با ترکیب دلفی و BCB و راه حلهائی که Boian Mitov توسعه داده است ( حتما" میدونی کدوم بسته ها رو میگم ) تولید شده اند ؛ در واقع کسانی که با دلفی و BCB آشنا هستند میدونن که کیفیت و سرعت توسعه رو بصورت همزمان فقط همین جا میتونن پیدا کنن . توسعه گران راه حلهای امنیتی هم به استفاده از دلفی تمایل زیادی نشون میدن . سه تا از خطرناکترین Rootkit های موجود ( معروفترین شون هکر دیفندر است ) با استفاده از دلفی نوشته شده اند ؛ حتی Madshi ناچار شده از تو بخواد موقع استفاده از نسخه رایگان کامپوننتهاش ( خصوصا بسته Kernel و Disassemble و Hook ) قول بدی که ازشون در تولید یک چیز بد استفاده نکنی ؛ چون کمپانیهای توسعه گر ضد ویروس به کرات بهش تذکر دادن که از کامپوننتهای او در توسعه ویروسها و روتکیتها استفاده میشه ؛ در یک کلام کاربرد محصولات بورلند خیلی وسیعتر از اونه که اصلا" بتونم به تموم شدن عمر اونها فکر بکنم . تو ایران خودمون هم همین چند نرم افزار بزرگ موجود با دلفی نوشته شده اند ؛ از راه حلهای جامع تحت ویندوز شرکت همکاران سیستم تا ERP شرکت کاوا کامپیوتر و سری محصولات برلیان و ...؛ در واقع دنیا اونقدر جای بزرگیه و اونقدر دیدگاه های متفاوت و سلائق متعدد توش وجود داره که نمیشه با سوال کردن از دو نفر ، به تمام ابعادش رسید . من دوستان زیادی داخل و خارج از کشور دارم که مثل خودم بصورت جدی درگیر پروژه های کنترلی/سخت افزاری بوده اند و به حسب نیاز توانائی هاشون رو به سایر حوزه ها توسعه دادن و جالب اینه که توی این حلقه ، نمیتونم کسی رو پیدا کنم که توی یک بحث یا ارائه مشاوره ، "دلفی" همیشه به عنوان یکی از گزینه هاش مطرح نباشه . وقتی مقیاس پروژه از یک حدی میگذره ، کسانی که تجربه دارن نمیتونن به چیزی غیر از جاوا فکر کنن ؛ مسئله انتخاب نیست ؛ مسئله اینه که انتخابی غیر از جاوا وجود نداره . دلفی یا دات نت یا هر چیزی مبتنی بر Win32 ، برای پروژه های فوق العاده بزرگ فقط یک جک هستند ؛ اما تعداد پروژه های واقعا" بزرگ همیشه کم بوده و خواهد بود و هزینه توسعه یک راه حل کوچک با جاوا واقعا بالاست ، ضمن اینکه در این مقیاس ، مزیتی بر راه حلهای Win32 نداره ! من سالهاست که با دلفی مانوسم . پروژه لیسانسم رو با دلفی 3 نوشتم  و بارها و بارها برای کاربردهای مختلف ( خصوصا چندکاربرد حساس نظامی ) توصیه اش کرده ام و حالا داره به خوبی به توسعه گرانش جواب میده . ارزش و توانائی این محصول رو فقط من و تو نیستیم که درک میکنیم ! از بین محصولات لگسی مایکروسافت ، ویژوال سی و از محصولات جدیدش ، دات نت ، هم بصورت گسترده استفاده میشن . در بسیاری از موارد با دلفی یا BCB قابل مقایسه هستند ، حتی ممکنه بشه شرایط خاصی رو در نظر گرفت که برتر هم باشند ؛ اما اینکه چه کسی در "تصاحب" بازار موفق میشه ، باید منتظر آینده بود . در حال حاضر میزان پروژه های مبتنی بر VCL اونقدر زیاده که حتی جرات نمیکنم با MFC مقایسه اش کنم . ( مایکروسافت رسما" اعلام کرده حمایت از MFC رو قطع نخواهد کرد ؛ و ضمنا" در هر نسخه ویژگیهای جدیدی هم به اون اضافه میکنه ؛ مثل ویژگیهائی که در MFC 2005 وجود خواهد داشت ) برای سالها توسعه گران در مقابل طنزی مثل ویژوال بیسیک و غول سینگین و کندی مثل VC ، ابزارهای سریع و توانائی مانند دلفی و BCB داشته اند و ؛ حتی اگر خنگ بازیهای بورلند باعث بشه ؛ توسعه گران قدیمی اش ؛ به سراغ راه حلهای جدید برن ؛ برای نگهداری از میلیونها خط کد موجود ، همچنان باید به دلفی و BCB فکر کرد . شاید تو مملکت ما که نرم افزار هم مثل خیلی چیزهای دیگه یک محصول لوکس و فانتزی است این معنای خاصی نداشته باشه اما اون طرف آبها ، نرم افزار یک کالای مهندسی است که فقط محاسبه و دو دو تا ، چهار تا ، ملاک و معیار برخورد با اونه .

اگر بخوام از کاربردهای عمومی محصولات بورلند بگذرم ، در کاربردهای خاص هم من عموما" ترجیحشون میدم . فی المثل علیرغم اینکه توسعهء درایورهای سطح کرنل با ویژوال سی ، سابقهء زیاد و قابل اتکائی داره ، اما من استفاده از BCB رو ترجیح دادم و میدم . خروجی اش داره با صحت و سلامت کار میکنه و توسعه گرش ، از اینکه تونسته با صرف وقت کمتری ، به نتیجه مطلوب برسه ، خوشحاله ! بورلند میتونست دلفی رو به Ring0 ببره ، میتونست ویژگیهای مفید و جالبی به VCL اضافه کنه ؛ میتونست در تولید IDE هوشمندی و ظرافت بیشتری به خرج بده ؛ میتونست بجای لاس زدن با اینتربیس ، وقتش رو روی توسعهء یک نسخه مدرن و قابل قبول BDE بذاره ؛ میتونست DBX رو ( که ADO .NET مطلقا" از اون تقلید کرده ) کاملتر و جامعتر کنه ؛ میتونست ...میتونست . اما حداقل بعد از حمایت از وب سرویسها ؛ ( از ECO که بگذریم ) من هیچ حرکت مثبت و امیدوار کننده ای در بورلند نمیبینم . دلقک بازیهایش در مورد کایلیکس و BCB ، واقعا" نا امید کننده بود . سردرگمی موجود در مدیریت بورلند رو اصلا" درک نمیکنم . همین احساس بد ، قطعا" به خیلیها منتقل شده/میشه/خواهد شد و این در انتخاب مسیر برای محصولات آینده قطعا" مؤثر خواهد بود ؛ فی المثل با اینکه روزهای خوبی با کایلیکس داشتم اما خیلی سخت به خودم جرات میدم به کسی توصیه اش کنم ؛ اگر از من بپرسه تاریخ انتشار آخرین به روز رسانی چه بوده چی بگم ؟ و اگر بپرسه چرا یه سری آدم متفرقه دارن براش Patch مینویسن و اگر ... ؟؟ چیزی که داره بورلند رو به محاق میبره ، نقصان در محصولات یا توانائی سایر رقبا نیست . انتخاب یک راه حل برای توسعه نرم افزار منوط است به وجود یک روند منطقی و جوابگوی قبلی ، یا یک مشاوره فنی جدید . که در مورد دوم ، مشاور ، اگر حرفه ای باشه ، نمیتونه به خودش جرات بده بورلند رو توصیه کنه . وقتی یکی از مدیران بورلند ، جان کستر ، به دفعات در مورد محصولات مختلف میگه " ما هنوز خودمون هم در موردش به نتیجه ای نرسیدیم" ؛ چطور میشه به تصمیمات آینده شون اتکا کرد ؟ دلفی و BCB و VCL عالی هستند ، اما این به تنهائی کافی نیست .

یادمه حدود یک سال قبل ، تو یک فروم در محضر جمعی از اهالی بلاد کفر و نفاق و فساد و الحاد ؛ یکی میگفت ، اگر قرار باشه بورلند اینطوری به ایده های خوبی که یه وقتی بوده و خیلیها روش حساب کردن ، گند بزنه ؛ مت ترجیح میدم بشنوم یه روزی محصولاتش رو با لیسانسی مثل MPL منتشر کرده ؛ تا حداقل اونهائی که میتونن با نظرات و ایده هاشون مفید باشن قدرت عمل پیدا کنند . این اتفاق خوبیه که تو دنیای سورس آزاد داره می افته و انتشار هر نسخه از یک ابزار توسعه ، با مقدار زیادی پیشرفت همراهه . بورلند بخشی از CLX رو با عنوان FreeCLX منتشر کرد ، اما ای کاش این اتفاق برای تمام کایلیکس می افتاد ؛ و ای کاش اگر توانائی مدیریت بقیه مسیر رو نداره ؛ این تصمیم رو برای راه حلهای ویندوزی هم بگیره و خانواده ای رو از نگرانی نجات بده . *رهرو آن نیست که گه تند و گهی خسته رود - رهرو آن است که آهسته و پیوسته رود* .


 :sorry:

----------


## hr110

سلام

جناب اینپرایز 
از جواب بسیار کامل و بینهایت دقیق شما سپاسگذارم. منهم به عنوان یک کد نویس مبتی حرفهای شما را در مورد win32 قبول داشته و محصول delphi مخصوصاً 7 رو به عنوان تنها نرم افزاری که برای نوشتن درایور، مالتی مدیا، بانک اطلاعاتی و کامپوننتهای سمت سرو مخصوصاً MTS و وب سرویسها و ... برگزیده ام و شاید تا جایی که ویندوزهای اتی خروجیهای انرا به عنوان برنامه قبول داشته باشند هم کنار نخواهم گذاشت. ولی نگرانی من و شاید مابقی دوستان از آینده ایی است که میکروسافت با زورچپانی ( :mrgreen: ) برای دات نت خود در حال رقم زدن است.
  البته من جواب سوال خودم را گرفتم و از شما نیز بسیار سپاسگذارم


خوش باشید
 :flower:

----------


## مهدی کرامتی

> بورلند میتونست دلفی رو به Ring0 ببره


این کار رو با دو خط کدنویسی Inline Assembly هم میشه انجام داد  :wink: 
بنابراین لازم نبوده بورلند خودش این کار رو انجام بده.

----------


## Inprise

> این کار رو با دو خط کدنویسی Inline Assembly هم میشه انجام داد  
> بنابراین لازم نبوده بورلند خودش این کار رو انجام بده.


نه . با استفاده از دلفی ( و Inline Assembly ) تو نمیتونی یک کد سطح کرنل بنویسی . برای اینکار کامپایلر باید توانائی تولید درایورهای مربوطه رو داشته باشه . بورلند سی ( کامپایلر BCB ) این امکان رو داره ؛ اما دلفی نه .

_( یعنی با دلفی نمیتونی دیوایس درایور بنویسی ؛ نمیتونی به امکانات سطح پائین پردازنده دسترسی داشته باشی ؛ نمیتونی دیباگر کرنل مود بنویسی ؛ و ...قدرتنمائی دلفی روی Ring3 است نه پائین تر ؛ شاید خیلیها بگن این مهم نیست ؛ اما من تصور میکنم واقعا" مهمه . درکش منوط به درگیر بودن با بدبختیهای کدنویسی محض با DDK است ؛ بدون داشتن هیچ Class Library و هر کوفت دیگری که وقت آدم رو نجات بده ...)_

----------


## مهدی کرامتی

> با استفاده از دلفی ( و Inline Assembly ) تو نمیتونی یک کد سطح کرنل بنویسی


اما میشه بخشی از کد رو در هنگام اجرای برنامه در سطح کرنل اجرا کرد.

----------


## Inprise

> اما میشه بخشی از کد رو در هنگام اجرای برنامه در سطح کرنل اجرا کرد.


این غیر ممکنه . اصولا" Kernel Space برای خروجیهای دلفی غیر معتبر است . ( کدهای کرنل مود هم فقط در سطح کرنل اجرا میشن و به User Mode دسترسی آدرسی مستقیم ندارند . یعنی برنامه ای که بطور همزمان روی هر دو مود کار کنه وجود نخواهد داشت . برنامه یا در فضای آدرسی Rin3 کار میکنه یا کرنل ؛ موقع کامپایل برنامه این ویژگی مشخص میشه و بعد از اون Loader مطابق نوع برنامه اون رو فراخوانی میکنه . چون برنامه های اجرائی دلفی برای Ring3 طراحی میشن و هیچ راه حلی برای دسترسی به Ring0 در دلفی تعبیه نشده - چه مستقیم چه به کمک اسمبلر - نتیجتا" امکان توسعه برای کرنل وجود نداره . گذشته از اینها ، دلفی به DDK دسترسی نداره . راه حلهائی مثل _Jungo WinDriver_ دقیقا" به همین دلیل طراحی و توسعه داده شده اند  )

 :)

----------


## M.GhanaatPisheh

> مثل ویژگیهائی که در MFC 2005 وجود خواهد داشت


Inprise عزیز میشه بگید اون ویژگیها چیا هستند؟

----------


## مهدی کرامتی

این رو یک نگاه بیانداز:

<span dir=ltr>*Privilege 0 execution through IRing0 interface*

Component Download: http://web.vip.hr/inga.vip/r0code.zip

*Question/Problem/Abstract:*
Execute your class procedures like kernel does! 
[through interrupt 60 gate] 
Enjoy on BSD while debugging!!!! 

*Answer:*

download complete article: 

http://web.vip.hr/inga.vip/r0code.zip </span>

unit ring0proc; 

interface 

uses classes; 

type IRing0=interface 
  &#91;'&#123;C6185103-C73B-4086-8E0C-1BB91A4A6AB0&#125;'&#93; 
function Privilege0 &#40;Param&#58;pointer&#41;&#58;cardinal; 
end; 

type ClassCall=record 
IR0&#58;IRing0; 
param&#58;pointer; 
end; 


function Ring0 &#40;const CC&#58;ClassCall&#41;&#58;cardinal;stdcall; 

function InitializeDriver&#58;boolean ;stdcall ; external 'ring0provider.dll'; 
procedure UninitializeDriver ;stdcall ; external 'ring0provider.dll'; 
procedure EnableInt60Gate&#40;&#41;; stdcall; external 'ring0provider.dll' name 'EnableInt60Gate'; 
function Ring0Int&#40;FAddress&#58;Pointer;Param&#58;cardin  al&#41; &#58; cardinal ; stdcall; external 'ring0provider.dll' name 'Ring0Int'; 

type TBaseDriverLoader=class 
IsInit&#58;BOOLEAN; 
public 
constructor Create; 
property DriverInitialized&#58;boolean read IsInit; 
end; 

type TRing0=class &#40;TBaseDriverLoader&#41; 
public 
function Execute&#40;I0&#58; IRing0;Param&#58;pointer;var Return&#58;cardinal&#41;&#58;longbool; stdcall; 
end;


implementation 

constructor TBaseDriverLoader.Create; 
begin 
IsInit&#58;=boolean&#40;InitializeDriver&#41;; 
if IsInit then EnableInt60Gate 
end; 


&#123; TRing0 &#125; 

function TRing0.Execute&#40;I0&#58; IRing0;Param&#58;pointer;var Return&#58;cardinal&#41;&#58;longbool; 
begin 

asm 
and dword ptr &#91;Result&#93;,0 
end; 

if &#40;not DriverInitialized&#41; or not assigned&#40;I0&#41; then exit; 
   asm 
   lea eax,&#91;I0&#93; 
   push eax 
  push offset Ring0 
  call Ring0Int 
   mov ecx,dword ptr &#91;Return&#93; 
   mov dword ptr &#91;ecx&#93;,eax 
   or dword ptr &#91;Result&#93;,$FFFFFFFF 
   end; 
end; 

function Ring0 &#40;const CC&#58;ClassCall&#41;&#58;cardinal; 
begin 
//DONT PUT BREAKPOINT HERE AT ANY COST &#40;BSD follows!&#41; 
result&#58;=CC.IR0.Privilege0&#40;CC.param&#41; 
end; 


end.

----------


## Inprise

> این رو یک نگاه بیانداز


کدهای مثل این دقیقا" مشابه Jungo WinDriver عمل میکنند . یعنی با استفاده از یک کامپایلر سازگار مثل VC یک کانتاینر مینویسند ، بعد کدهای زبانهای مثل دلفی رو بهش پاس میکنند .  درایور کد مثالی که گذاشتی هم دقیقا" همینطوره . ( فراخوانی درایور کرنل مود موجود هم داخل DLL پنهان شده ؛ ) یعنی نهایتا" این برنامه دلفی نیست که به Kernel Space میره ؛ درایوری که از قبل ساخته شده اونجا قرار میگیره و کدها رو توی اون فضا اجرا میکنه ؛ اما حتی این روش هم محدودیتهای خاص خودش رو داره که اگر بعدا" فضای مناسبی ایجاد شد در موردش مینویسم .




> اون ویژگیها چیا هستند؟


- تغییراتی در مدل مدیریت حافظه ( تکمیل ویژگیهای اضافه شده به MFC 7 در VS 2003 )
- تغییرات ساختاری و افزایش امکانات ( مانند بهبودهای قابل توجه MFC 7 نسبت به MFC 6 )
- افزایش حمایت محیط VS از توسعهء MFC
- نزدیکی بیشتر MFC به ATL
- و ...

---

دربارهء هر چیزی حرف زدیم الا بندهء خدا ؛ گالیلئو  :wise1:

---

بعد از تحریر : DLL و درایور با VC6 / MASM کامپایل شده اند .

----------


## مهدی کرامتی

از توضیحات ات متشکرم.

----------

