stijnsanders

I haven't done code signing before, can you use any certificate for it? Would one of these people work? https://www.gandi.net/en/security

Yes! try/except on everything and optionally store the exception's Message (and ClassName) in a string that you make available with a dedicated function xxxGetLastError: PChar;

With the little experience I have with loading DLL's to and from newer and older Delphi versions (for a certain project) I think I can say that the exception handling between older Delphi's (5,6,7) and newer Delphi's (roughly those that started using WideString for string), is that they're binary incompatible. Raising in an 'old' DLL and handing in a 'newer' DLL, will typically re-raise an access violation instead. The best advice I could give is how I solved it: keep all exceptions 'within DLL boundaries' if at all possible.

Oh my god what happened to IIS! I knew it was fickle (It's one of the reasons I created xxm, just to get the install right just once (this is what it took way back) and then use its auto-update) but 32/64-bits and all the newer versions haven't made it easier. Apparently there's also a 'native module API', but it's for C++ only (and this unavailable for Delphi?) sad! Aside from David's suggestions, I would also advise to check the Application Pool settings, as you can make important changes there that affect the required permissions on the file system. Also that some errors end up in the Windows Event Logs, not a place you'll readily think about looking for errors!

One of these? https://github.com/Fr0sT-Brutal/awesome-pascal?tab=readme-ov-file#game-dev

I read this blog post: https://blog.dummzeuch.de/2024/06/04/an-improved-abstract-error-handler-for-delphi/ and noticed I had something similar, but noticed that Delphi since some recent version introduced a function ReturnAddress that is generally available, it doesn't even have code in System.pas so I suspect it's something the compiler introduces. I also notice older Delphi versions don't have this yet so I'm not sure at what version this got introduced. Does anybody know or can check? (Also I guess using ReturnAddress would future-proof your code in case the [ebp+...] offset changes again, and also should be available on other processortypes?)

I have never done much 3D (which I regret), I haven't done any Vulkan, but I just happen to remember something from when I was trying to port the old pixelcity to Delphi, that the wglCreateContext and wglMakeCurrent calls are used for more than only OpenGL. Could it be that they are the key to get Vulkan working with VCL?

The site is asking me to log in (into Jira??!!) Can you post here what the workaround is?

If I recall correctly, the environment data is stored in files here: %APPDATA%\Embarcadero\BDS\22.0\*.dst but I'm still on Delphi 11, I'm not sure what BDS version Delphi 12 is on.

What are you using to use SQLite from a Delphi project? I'm using a really thing wrapper around sqlite3.dll and haven't found any trouble with integer types. (Also, good to know is that SQLite handles column type a bit different.)

Help! I read that future versions of Windows may put NTLM out with the old unwanted stuff, so, I thought I'd check the alternatives that are proposed. There's AcceptSecurityContext (Negotiate) that looks like it works identically like what I was using before for NTLM. It looks like that works just great on my laptop here... But at work, it doesn't ofcourse! Negotiate is supposed to automatically switch between Kerberos and NTLM, and at work I do indeed notice other and longer binary buffers, get two SEC_I_CONTINUE_NEEDED responses, but strangely enouch a third time. When the browser (Chrome in this case, I haven't been able to test others, but if they also call InitializeSecurityContext like you're supposed to, there should be no difference) returns the request for the third time, there's no extra data in the Authorization: Negotiate header, en it fails. Even if I try another AcceptSecurityContext, it gives SEC_E_INVALID_HANDLE ofcourse. I can't seem to find what's wrong. I can't notice any difference to the data in the buffers, or the flags set in pfContextAttr... I've been checking if it's something with AcquireCredentialsHandle, but that one seems all correct... I can't think of anything more I could check for what's going wrong... Should I try to build the same in IIS and have a close look at the data that is passing between IIS and Chrome to compare to my data? (In case you were willing to debug, the code is here, let me know if you need help setting up a debugging environment as I know the xxm project registry is not self-explanatory.)

Believe it or not, it actually started because I was trying to implement Internet Explorer's IInternetProtocol interface! And I did! For a while it worked and I had URL's working in IE that started with "xxm://"! Because so much was similar to the work I've been doing before on Apache httpd and ISAPI Extensions, I started IxxmContext and concentrated on keeping everything working in whichever environment...

Oh my yes! How i dream about a 64-bit version of Delphi 7!!! (Are the Lazarus people listening?) You need to pay attention to details, when trying to keep a project working over Delphi 7 and 'modern' Delphi! Apparently some Explicit* properties bled through from 'modern' Delphi, and Delphi 7 only at run-time doesn't seem to be able to handle them. I'll fix this by xxm's next release. I've only included xxmProject.exe to demonstrate that there is a UI to edit project configuration, but in theory you can make all edits with notepad to Web.xxmp (it's just JSON actually). Oh, I'm missing quotes (") in the command line somewhere. I guess you can it's fixed by editing the compileCommand in Web.xxmp to this: dcc32 "-U[[HandlerPath]]public" -Q "[[ProjectName]].dpr" The path isn't part of [[ProjectName]], it's [[HandlerPath]] that gets split up, and dcc32 is trying to find the part after the space as if it was a Delphi project... But I'm glad you got it to work! Have a try making changes to see if you can extend the demo projects with whatever! Demo 04 should work just fine, but 09 is throttled yes, look at line 21 xxm_demo\09 Upload Progress\aAdd.xxm ... (It's to demonstrate the upload progress thing...) Let me know if you need anything. (Should we start a separate thread on this forum? We're no longer talking about the Negotiate:Kerberos thing anymore...)

I remember when I checked out Atom.io a few years ago, I was wowed at what's possible and where the state of the art was going. I understand it kind-of was the open-source answer to Sublime Text. Then I switched to Visual Studio Code, and again was wowed, this time because of how much more things could get better. It's really fitting for a (huge!) community of developers that they're all cooperating to push a single development environment forward. (Even though it's a big for-profit company that acts as the project's steward. It shows how Microsoft itself also evolved...)

Ok, first thank you again for the suggestion! It was due time that I put some effort in those demo projects again, some were broken since a few releases, and I found a nasty bug that I'll be able to fix by the next release. So, please head over to https://sourceforge.net/projects/xxm/files/v1.2.7.477/ and check out the file "xxm_demo_with_binaries.zip" (the exe's in them may be 1.2.8 pre-release versions, but have the bug fixed... but that shouldn't matter if you just want to see xxm in action) I've explained how to get things working in the file "readme.html", just extract the folder "xxm_demo" from the zip to somewhere, and everything should work with relative paths.

(Oh one more thing on ORM's: what I do do with databases resulted in this, and if you want to see an example xxm project that uses this extensively, see here)

I'm glad we fully agree on ORM's. There's something very important you need to know about xxm: it is not a scripting engine. It uses (the speed and power of) the Delphi compiler to compile a DLL, based on pure-Delphi code it generates from your xxm files that have both HTML and server-side code mixed much like PHP/ASP/ColdFusion script does, but it does not interpret these scripts. So, to answer your question how exceptions are handled: the compiled DLL is run in the web-environment of your choice, either within xxmHttp.exe that is a HTTP/1.1 server in itself, or by xxmIsapi*.dll that you need to configure properly in IIS. (or the SCGI handler, or the Apache httpd module...) So if your Delphi logic raises an exception, and it doesn't get handled, it traverses into the 'higher layer', either the default exception handling the xxm handler provides, or worse the system's fallback and the 'default' system exception handling. Because you build 'real' delphi DLL's with xxm, you have access to anything you would have access to from a 'normal' Delphi project (since, well, it is, it's just auto-generated for you and hidden away in the 'src' folder). Which is a blessing an a curse, because you're supposed to know what you're doing, take care of security on the server-side, and know that some things are different when running from a DLL inside of a NT-service process... (But don't let that discourage you, most things just work the same.) But your suggestion is a really good one. I'll put a demo package together with xxmHttp.exe and a xxm.json with all the demo projects, to show off how it works. Then, as a first demo you delete some demo*.xxl files, switch to xxmHttpDev.exe and (provided you've got a working DCC32.exe available on your system) see that it really can regenerate the source files and compile the same xxl from source for you...

Thank you for the feedback!!! It's great to finally have someone looking at xxm. I've been trying to find anyone that wants to combine Delphi and web (back-end) in a specifically different way than trying to force RAD-form design onto web-pages (yuck) and also steer clear from ORM's, but that's still something else than the basic project that indeed needs some work just to get it to be more welcoming for new users... 1) I have been sticking to Delphi 7 for a very long time, (and trying to keep xxm working for both Delphi 7 and 'modern' Delphi) so I was not sure where exactly the switch to NativeInt was. I'll update the $IF's to <30, I guess. 2) That may be by design, I've got the 'main' projects in the dpg/groupproj, and some periferal projects serve some specific tasks, or are not ready for primetime yet... 3) I'm in the process of removing xxmConvert*, and may have missed a few dpr/dproj, please check my most recent commits 4) You're right, I completely forgot to commit an example "xxm.json". xxmProject should be able to add to an empty file named "xxm.json" when you're using the "Register with xxm.json..." button, I should look into that, at least update the documentation (I had xxm.xml before, but the same problem applied...) For now you should be able to get going with something like this: { "projects": { "xxm": { "path": "D:/Data/xxm/Delphi/demo2/listprojects/listprojects.xxl" } } } Also I would suggest to limit yourself to xxmHttpDev (or just xxmHttp), the other projects are for other web-environments (IIS, SCGI, Apache httpd...)

Haha, apparently setspn is available in most Windows'es, and on my laptop: C:\Users\User1>setspn -l User1 FindDomainForAccount: Call to DsGetDcNameWithAccountW failed with return value 0x0000054B Could not find account User1 that's an oddly specific error! Arent those function calls with two letter prefixes ntdll.dll internal kernel calls? To get a proper environment set up to test this, I guess I'll have to get a developer license of Windows Server from somewhere, probably in a virtual image...

Well, yes with some extensive googling web searching, I learned that the problem is probably something with the domain. I replicated the configuration in IIS, removed "NTLM" and "Negotiate" from Windows Authentication, and only added "Negotiate:Kerberos", and had the same behaviour as I was having: Chrome tries Negotiate, but seems to fail and pops up the username and password dialog. I guess I'll have to ask the domain admin at work if he can add "http/"+computername. I would like to have seen a windows event log item clearly stating what's wrong, but didn't find any. I guess those get sent to a gigantic log on the domain server somewhere I don't have access to. Or I need to set up a full test-environment here, but not sure if you can on a 'plain' Windows or need a Windows Server instance...

I don't think they're related. I use Ctrl+Shift+F a lot to search over all files in a project (when I'm not using DirFind) and was baffled at first I wouldn't find things that I was sure were somewhere in the project, just to notice this "Whole words only" checkbox was checked! I type control hotkeys sometimes by mistake, but I don't think I'm typing Alt+W every time... Someone should launch an Embarcadero QC ticket, if there isn't one already.

No, not al all. Remember a few decades ago, when most personal computers had only one processor? We had multiple threads then, the operating system cycles them for you nicely, even over the several processors if your system has more. If you're running really intensive work in the threads, you may cause slowdowns by having more threads than processors (it's interesting to learn about thread affinity as well), but as soon as you're doing I/O from these threads (and the system handles device calls on your threads) you may get an increase of total performance, because the system can let more threads work while some threads are 'waiting'. There's more to the story when you're using completion ports, or do overlapped IO calls... But only remotely related to your question about threads.

Looks like normal behaviour like you describe it: Windows will 'white out' applications and show them as non-responsive, when they stop reading messages from the message queue. In Delphi applications, there are two main ways to solve this: either call Application.ProcessMessages from time to time from the code that does the processing. There's some special care you'll need to take for the case when the user wants to abort the importing, or close the application. This will 'unfreeze' the application, because messages get handled, but may slow down the importing a little. The second way is to write the importing code so it uses background threads. There are libraries and solutions that can help you with this, or the hard way is inheriting from TThread yourself, but then you need to know how to synchronize between the main thread to output progress and results from the importing.

What I typically do to get it right, is open the dproj in a text editor, and remove all of the `<Ver`* elements that are not inside of the <PropertyGroup Condition="'$(Base)'!=''">` element, then only change the version info in the IDE with 'Target' set to 'All Configurations'

If you need to capture and process the output of the cmd, I would even advise to use CreateProcess with STARTF_USESTDHANDLES. I have an example here, but it's a bit of a confusing sample because the reading of the pipes happens in the DoCommand procedure, I should take some time to write a cleaner example...