Xeffort site to be archived

[Steve_Lionel]

Back in 2007, Jugoslav Dujic, whom long-time members here will remember, created:

Xeffort library (previously known as XFT) is used for easy building Win32 GUI applications with Compaq and Intel Visual Fortran compilers. It seamlessly integrates with Microsoft Visual Studio (.NET) IDE providing:

• Application wizard, for quick creating of skeleton MDI, SDI or dialog-based applications

• Handler wizard, for creation of prototypes of most-frequently used routines

• Online help, which can be run from Visual Studio "Tools" menu

He made the library and its documentation freely available as open source. In 2013, Jugoslav handed over the Xeffort site to me, and I made it available as xeffort.info, where it sits today.

Unfortunately, the code is highly bound to the 32-bit architecture, so is unusable with today's Intel Fortran. I did spend some time a few years ago to try to update it to 64-bit but found it overwhelming as there was too much hardcoded for 32 bits.

My intention is to take the xeffort.info site offline, but at that point I'll keep the files available in a folder under stevelionel.com (there will be a redirect for a while).

If someone wants to take on updating Xeffort for 64-bit, feel free to download the sources and have at it.  Someone did contact me some years back offering to do this but did not follow up.

I think the library is valuable and would prefer to see it live on.

[David_DiLaura1]

Is Jugoslav still around?  I've not seen a post from him in a very long time.

[Steve_Lionel]

He no longer participates here.

[JohnNichols]

This sounds like a good board.  Steve:  Do you know what was his industry, steel plastics etc...

Just looking at the 1085 views, this board must get a lot of people who just read the board.  Does intel track that sort of thing?

Plus the old Intel NUC's and there are four on my desk and several on the floor, sold to ASUS, there is a new ASUS one for about 1000 USD with an Intel Core7 (the AI one) inside, it looks really neat.  Great machines. 

[Steve_Lionel]

Jugoslav's "About" page indicates that he was (and maybe still is) an electrical engineer. I doubt Intel tracks view counts.

[thismarkjohnson]

Thanks for keeping this alive — Xeffort was genuinely valuable back in the day. It’s a shame about the 32-bit lock-in, but making the sources available is the right move in case someone wants to modernize it. Hopefully a motivated dev with time can pick it up and port it to 64-bit; it would still fill a real niche.

[Neels]

Xeffort is the main reason why I am not using IFX, my programming skills are not good enough to update Xeffort to 64bit. If someone does update it I will be very grateful.

[andrew_4619]

At the weekend I had a look at some downloads from the XEFFORT site Steve hosts. I though it would be an interesting to have a look at it as an interesting challenge an to maybe learn a few things in the process.  I have done a lot of work on using the window SDK with Fortran  so  much was already known to me. I have to say that  on and off I have spend a good couple of days making many hundreds of edits but as of a few minutes ago I had a first successful  64 bit build of XEFFERT.lib and then built the LVTest sample program. That seems to do that same things as the 32bit version  so a good start.

It will need a lot of testing to exercise all the features and I do not think the samples provided come close to fully testing it

[Neels]

This is great thank you Andrew!

[andrew_4619]

There is quite a way to go with this project I think.

1] I have been working using IFORT rather than IFX as with IFORT you can switch between 32bit and 64bit builds of the same code. When the x64 port is 'complete' the switch to IFX should be simple.

2] The XEFFERT library builds in x64 IFORT. There are many hundreds of edits and there are bugs. Some due to bad edits some due to things that are missed e.g. I am finding some instances where a 64bit function return is assigned to a 32bit variable and if that variable is not directly passed to something that is expecting a 64bit variable there is no compiler error, in these cases it just may crash or worse not function correctly. There are several other types of errors also. Even if I had spent much more time than the lighting speed conversation bugs would exist. That is reality!

3] There are also some instances (I have fixed a couple) where a call handler is being passed a 32bit variable. In some instances it is used as a 32bit variable and in others it is being is as a used as an integer pointer to something (e.g. a bitmap handle) the distinction being controlled by other passed parameters. Clearly that does not work for both 32 and 64 builds and the solution adopted is additional routines (within the generic interfaces) that handle the case with a 64bit value in a 64bit build. The other options would be to change the user facing XEFFERT interface but that would not be compatible with existing XEFFERT applications, so to my mind that is not the way to go.

4] I have done some testing with the LVtest and XYamb XEFFERT sample programs as a start. The 32 bit versions of the new code run but some things work incorrectly. The 64 bits version work less well as would be expected. The next step is to set up 32bit builds of the original codes (a few minor edits are needed for language violations), I had this originally but foolishly did not make a safe copy! I can to do side by side debugging of the 32bit versions to see where XEFFERT structures as not being correctly initialised and other anomalies. I think that will flush out most of the errors.

5] Then the next step is debugging of a X64 builds of these two samples.

6] The (final?) step after that would be trying more XEFFERT examples that exercise all (or at least much of) the code.

As this is 'hobby work' I have limited time to spend on this so I am unsure of the timescales it might be some weeks. Has anyone got any information on the original author Jugoslav Dujic, University of Novi Sad, Serbia/ Institute for Power, Electronics and Telecommunications? His digital footprint seems to be non-existent in recent years, I made some searches. It is of course possible he is no longer living. The code has open licence however is would be disrespectful/wrong do do something with it without some recourse to the author if that is possible.

I am personally interested in this project as a bit of 'fun' but it might be useful to find any people that have a real interest, I suspect those will be few.

Regards
Andrew

[GVautier]

Hi
Have you seen here https://deet.ftn.uns.ac.rs/zaposleni/dujic-jugoslav/ there is an email address and a phone number.

[andrew_4619]

Those contacts are the University of Novi Sad, Serbia and are not valid (unknown user name).

[JohnNichols]

The University is no longer part of Yugoslovia,  and he no longer works there,  

I found his name on an enterprise doing something completely unrelated to programming, but there were no contact details, or I would have emailed him.  

Somethings are just lost. 

[mecej4O]

See University of Novi Sad - UNIVERSITY .

[JohnNichols]

He is not present at the University that was in Yugoslavia and is now not.   I found him on a site but there were no contact details.

It would be nice to find him, but I ran into a brick wall.  It happens. 

Is there a way to pick up plain text coming across a Serial USB port if I know the port number and the port details?

I have a new instrument that will do that but it has no real software.  

[mecej4]

See University of Novi Sad - UNIVERSITY .

[Neels]

Andrew,

Thank you for your efforts. Steve looked at converting it to X64 some time ago but came to the conclusion that it was more work than he had time for. Over the years as the compiler became more strict some code had to be updated but that was a while ago.

I used to communicate with Jugoslav when he was still active on this forum but since he left his contact addresses has also stopped working. He did agree with Steve that Steve could preserve his web site on another host. I am not sure what licensing agreement there was.

I do not know enough to really help you with the coding or proper testing, I am just a mechanical engineer that uses it to create simulation software.

Kind regards

Neels

[Steve_Lionel]

Basically, Jugoslav turned over the whole thing to me to do what I wanted with it. The biggest hurdle was that Jugoslav used hard-coded KIND values everywhere, rather than named constants such as HANDLE. Reading the code, it is not always obvious what should be a handle or address and what should not. 

[andrew_4619]

"Reading the code, it is not always obvious what should be a handle or address and what should not. " Yes indeed, many are obvious, many can be determined by  looking at the usage in a little detail and some fly under the radar, I am sure there are some I have missed but not ones that inhibit compilation. That is the debugging task. There were zero "handle" kind declarations in XEFFORT lib, there are now in excess of 1,300!  

[Neels]

Dear Andrew,

Are you continuing with this update and do you need someone to start testing?

[andrew_4619]

I built a new XEFFORT library and have also built the following samples:

LVTest
TbTest
XGraph
XHello
XYamb
XTabEditor

If I build the new library in X86 these all sample build and run seemingly OK, which is good as it means I have not badly broken it! If working in X64 they all build and run but some have issues, for example currently hovering over toolbars causes TbTest to crash. This is seems connected to the "tooltips" feature however the crash is in a standard windows handler not an Xeffort one which indicated that either it should have been handled and wasn't or that the associated feature setup has bugs. Debugging such things is not is not so easy, you need to understand how the SDK feature works, understand how Xeffort handles the features and then find where is it broken. Some of the bugs I am finding are quite subtle, all the obvious ones are sorted!

Found and fixed this little beauty yesterday that seems to causes later stack corruption crashes in some cases.

RECURSIVE FUNCTION XItem(xFoo) RESULT(xI)
TYPE(X_ITEM):: xI
!DEC$ATTRIBUTES NO_ARG_CHECK:: xFoo
INTEGER::      xFoo
xI%lpItem = LOC(xFoo)
END FUNCTION XItem

It is an interesting hobby project and I am learning a few new things on the SDK which I will undoubtably make use of. Every time I have a session on this I eventually find and fix a problem and move onto the next one. Until all the samples work OK there is no point in looking at any third party evaluation.

I am also of the opinion that the samples do not fully test all the library features.