From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1a794e8ed8953f4d X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: Very elementry query Date: 1999/11/02 Message-ID: <381F2A58.47A1002D@pwfl.com>#1/1 X-Deja-AN: 543598593 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <7vn60o$6km$1@nnrp1.deja.com> To: rishikeshjha@my-deja.com X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: e108678@pwflcom Newsgroups: comp.lang.ada Date: 1999-11-02T00:00:00+00:00 List-Id: rishikeshjha@my-deja.com wrote: > I am an absolute newbie to ADA. I have been assigned the task of sizing > a project wherein a ADA app. has to be ported from Solaris to NT. Can > someone tell me how complicated such efforts are. > Please note that the language is "Ada" - named after Ada Byron and not "ADA" (Americans with Disabilities Act? American Dental Association?). For some reason we have a tendancy to be touchy about this. :-) I don't think your problems are going to be Ada specific. My experience in porting Ada between PC's and Unix has been very positive. But then, the applications were simple command-line-interface driven and made little to no system calls. Given that GNAT exists on both platforms, I found that compilation had zero problems and things ran mostly identically. (Some problems with byte sex differences in external, custom built data files, but this may be avoided if the Ada code is structured to detect this possibility.) With a large number of applications I've built/ported, the effort was near zero - just recompile and go. Your real problem is going to be in the area of OS dependencies. You will want to assess how much of the application performs GUI functions, asks for OS services, manipulates files with unusual design, etc. That's the code you will need to worry about and the level of porting effort will depend on the skill of the programmers, the portability/isolation of the original design and so on. If it were me, I'd assess what portion of the app has such sensitive features and count up the SLOCs. Anything that does more or less general computational stuff ought to port very easily. Since our organization has several years of productivity data (counting SLOCs per fortnight) I could take a SWAG at how many hours would be needed to review/rewrite that portion of code which may be bound to the OS. If you have similar data for your organization, this would be a major help. (There is no way that one organization's productivity measures will have anything to do with another organization's behavior, so it wouldn't be much use for me to share that data) If you have more information about the nature of the app, and you are free to post it here, its possible you may get more helpful answers. MDC -- Marin David Condic If you act quick, you may still find me at....... Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.mcondic.com/