Re: Alternate file types for RUN ?

JF Mezei wrote:

What I was suggesting is first look for .EXE, and only if it fails, then
look for architecture specific type (.EXE_VAX, .EXE_ALPHA, .EXE_8086 etc)

Once the executable (main) image is activated, I would assume you want everything else downstream to select that same architecture, right?

Accordingly, work through what you would want to see done for RUN, for $creprc, lib$find_image_symbol, and for the secondary image activations for shareable images and for user-written system services, and there'd have to be provisions made for and within the debugger(s) and for the image traceback processing, in DCL (for DCL$PATH) and within the INSTALL utility, and submit it to HP as a feature request.

And since this is -- I assume -- a request for the same architecture and not a cross-architecture operation, this enhancement would not need nor require rewritten debuggers and traceback support. It would require searching for image defaults around the operation, and I expect there are a bunch of tools around that look at or default to this -- ANALYZE/IMAGE, for instance. If you were to add architecture translations, things would get really interesting...

As for selecting the architecture at activation, I'd initially tend to think there would have to be a process-level setting for the image activation based on the main image, and which would obviously have to be reset either at image rundown and/or at main image startup.

The discussions of this area I'm familiar with have traditionally all ended up being "but hey, logical names can do that...". And if you use facility name prefixes on your image(s), you can also define a set of logical names that translate(s) as the full path -- that technique can also help with installed images and installed image activations, too. (There are similar techniques used for a couple of the OpenVMS RTLs, where certain of the RTLs are/were built with specific and microprocessor-(semi-)specific compilation techniques, and selected using logical names.)

Or ask nicely for the source code, and port it all to x86-64 and fix it or extend it for yourself for your specific needs. Or -- when you're fixing it -- forget the whole user-specified and variously-defaulted filename extension scheme, and re-code this whole area using far more modern techniques and designs. The file extensions are, well, an ugly and weak and primitive solution to the basic problem of identifying the particular file contents, after all.


.

Relevant Pages

  • Re: Code density and performance?
    ... > Looking at what Intel and AMD did with the 386 architecture, I am> convinced that it is technically possible to design competetive VAXen;> I don't see any additional challenges that the VAX poses over the 386> that cannot be addressed with known techniques; out-of-order execution> of micro-instructions with in-order commit seems to solve most of the> problems that the VAX poses, and the decoding could be addressed> either with pre-decode bits, ... Many important senior VAX implementors disagreed. ... mileage from the same techniques. ... In my view, also bearing in mind the investment by Digital, it would have been far better to implement the VAX IS on a Mips core, much in t5he same manner as IBM has exploited the Power PC architecture. ...
    (comp.arch)
  • Re: whats the future of Object Oriented Programming
    ... and they also have OO techniques to draw on. ... nimble/local database engines are provided to suppliment big-iron ... will require solutions that coordinate functionality from multiple ... centralized database architecture is that it can't always meet the ...
    (comp.object)
  • Re: whats the future of Object Oriented Programming
    ... and they also have OO techniques to draw on. ... nimble/local database engines are provided to suppliment big-iron ... will require solutions that coordinate functionality from multiple ... centralized database architecture is that it can't always meet the ...
    (comp.object)
  • Re: Disadvantages of Inheritance, Polymorphism and Encapsulation
    ... with performance related to a micro-kernel architecture do not have ... intrinsic to the OO techniques being used? ... > Genera a successful operating system? ... language". ...
    (comp.object)
  • A width agnostic hash function
    ... I've been doing reading on hash functions (with C implementations), ... I've noticed that all the techniques used have made certain assumptions ... about the architecture width. ...
    (comp.lang.c)