qubits

Searching for Delphi Winsta. I found this. Looks old, but got allot in it.

Nothing new, use to be Norton and McAfee, that would mess with ALL Delphi apps, haven't seen any troubles with the big ones in a while. It's only a few that have their patterns wrong, i wouldn't worry, anti-virus is a double edge sword, cuts both ways sometimes. If it does affect you, then contact the anti-virus makers and get them straight. rename your exe to .txt and then zip it up, just maybe it might get through email, but it's a big maybe, easier to drop it in some cloud storage.

lol, a test.. ok, i'll stab.. if the top works. then VString is in fact a point and has to be de-referenced hence the ^, but the bottom does not treat VAnsiString as a pointer and it fails, so maybe it's also a pointer too.. make the bottom look just like the top except VAnsiString instead of VString and give it a wirl.. note, only commenting on //works fine //not working because it all looks like one big IF to me.. 🙂

Did you get this going? noticed the 64 bits too, but then your copying 10 chars into the str1, so could potentially overflow a 32 bit integer, unless maybe str1 fails on the conversion and the error is silenced somehow. use a local var and do the conversion before updating pb1, wrap it in a try except and catch it.

set break points here, examine Position, if all is good and you see it update while debugging, then maybe all you need is Form7.pb1.Refresh; a bit messy, good luck!

not usre how you got there, this is whats in the demo, i expanded the comments procedure TMainFrm.SendString; var aHdr:tPacketHdr; aStr:String; aBytes:TBytes; aBuff:TBytes; begin aStr:='Hello from client!!';//string could be sent into procedure if Length(aStr)>0 then begin FillPacketIdent(aHdr.Ident);//fill our indent aHdr.Command:=CMD_STR;//tell server its a string aBytes:=TEncoding.ANSI.GetBytes(aStr);//encode string to array of bytes SetLength(aBuff,SizeOf(tPacketHdr)+Length(aBytes));//make our transmission buffer big enough for header and string aHdr.DataSize:=Length(aBytes);// size of string, always use length instead of size of on dynamic sizes Move(aHdr,aBuff[0],SizeOf(tPacketHdr));// move the header into buffer Move(aBytes[0],aBuff[SizeOf(tPacketHdr)],Length(aBytes));//move string into buffer just after header PacketClntDm.cliSock.Send(aBuff,Length(aBuff));//send it off SetLength(aBytes,0); SetLength(aBuff,0); end; end;

nothing obvious.. wondering though looks like _WINSTATION_REMOTE_ADDRESS might have changed back in windows 8.1 Noticing that here maybe This showed up in my search too. <-pascal anyways.. and here<- looks like you have to enumerate through all sessions, don't think you can pass -1

added this into the demo i did previously for you.. now you can send/recv a jpeg, a single string (can be as long as you wish) or a record structure.

i can also second ae's approach, especially if you wanted some automation. app launches, check Application.ExeName, if it's the orig, copy orig to newname, launch newname, then exit. now you can update orig exe as needed. Launcher app approach is typically just another application that executes the other after checking for and applying updates.

No more like.. TMyRec = packed record Header:TPacketHdr; FirstName: array[0..39] of byte; LastName:array[0..39] of byte; Message:array[0..499] of byte; end;

If you still sending your own packets, then strings need a header too, then converted to array of bytes just like the jpeg. added a send/recv string to the packet client and server demo, so you can see one way to do this. also generalized the server a bit, changed from q of jpeg to tPacketData which is DataType then array of bytes. Updated server example to show simple method of determining incoming array data. i tend to treat my strings as fixed arrays of bytes and those are in larger records of data. don't typically just send one string. i'll update the demo to show how to send record structures in a few days.

if it's an application, the easiest answer is in the first sentence.. make a launcher that checks for updates then launches main app, then exits.. I can also second Dave's recommendation as I've used TMS as well and it works great, no second app to maintain.

quick test, worked straight away with elegant changes recommened .. no python, but gave me a dir listing.. ufrmMain.pas

You're welcome, was a nice break from my robot wars. Which by the way, I used the demo ics packet server to test my cross platform packet client. Put a working demo of this up, should also compile for Berlin. Does the same, but pic recv is used as texture for cube which you can spin around, so it's like cooler. 🙂 TJpegImage doesn't exist in FMX, this shows how to save a jpeg stream. Caution, did demo in my crazy 3d world, looking at the code too long may have adverse side affects. robots-ics have fun! ~q

compiled with berlin 10.1 and ics version 8.62 Revised: August 6, 2019. i used Getit inside berlin to download the ics. try the latest version.

you know, sorry.. noticed this on berlin too ,thought it was a wad (working as designed), it stopped if i coded faster. was going to ask if they could make this audible, some times late nite coding, i nod off, be nice to have my ide beep at me when i fall asleep.. 🙂

Yes, it's a bit tricky and Rome was not built in a day.. 🙂 thought we be sending jpegs.. but you should be able to bend this to your will.. Custom Packets Good Luck!

yep, and keeps adding to the client buffer and updates count, once all is recvd i processes it. works well for me.. sorry..

i was using the threaded server, you can probably omit the Thrd and try TWSocketClient, pretty sure it works the same just not threaded..

Winapi.Windows, Winapi.Messages,System.Types,System.SysUtils, System.Classes, System.SyncObjs, OverbyteIcsWndControl, OverbyteIcsWSocket,OverbyteIcsWSocketS, OverbyteIcsWSocketTS, OverbyteIcsUtils; in one of these units.. 🙂

no worries, your close, just remember, it's not a string or anistring, it's bytes. type TMyClient = class(TWSocketThrdClient) public Buff : array[0..9999999] of byte; Count:integer; ConnectTime : TDateTime; ClearToSend :boolean; GoodHeader :boolean; end; procedure TServerCommsDm.SocketDataAvailable( Sender : TObject; Error : Word); var Cli : TMyClient; Len:integer; aPacketHdr:TPacketHdr; begin Cli := Sender as TMyClient; //recv bin data into our buffer.. Len:=Cli.Receive(@Cli.Buff[Cli.Count],SizeOf(Cli.Buff)-Cli.Count); //did we get some!! if Len <= 0 then Exit; //count it.. Cli.Count:=Cli.Count +Len; //see if we got enough for a packet if Cli.Count>=SizeOf(TPacketHdr) then begin Move(Cli.Buff,aPacketHdr,SizeOf(aPacketHdr)); if CheckIdent(aPacketHdr.PacketIdent) then begin Cli.GoodHeader:=true; Display('Recvd Valid Header:DataSize='+IntToStr(aPacketHdr.DataSize)); //packets can have extra data.. check for a datasize.. if Cli.Count>=(aPacketHdr.DataSize+SizeOf(aPacketHdr)) then begin Display('Received packet from ' + Cli.GetPeerAddr); ProcessData(Cli); end; end else begin Cli.GoodHeader:=false; Display('Received bad header from '+Cli.GetPeerAddr); Cli.Count:=0;//start it all again FillChar(Cli.Buff,SizeOf(Cli.Buff),#0);//zero the buffer end; end; end;

Buf should be an array of byte. Also should be big enough to grab your image and get rid of the additional #0. But like the other have pointed out, this will only work if it's all your sending. Really, you should make a packet header with a fixed known size that should at least let you know the size of the additional data to recv. Then, you just recv packet header, see data size and keep receiving unit you get it all.

Ok, very strange. This is on my project I ported from Berlin. Made a new folder. c:\d11 then my common units c:\d11\common then my proj c:\d11\proj project folder only has 1 main form frmMain.pas, and a datamodule. all the rest is in my common folder as I share these, haven't since I started porting, but kept same folder structure. everything seems fine, port moving along nicely. was doing a backup this morning and noticed that everything in my common folder seemed old. All the file date/times are pre D11?? checked contents and they are correct, can open unit in ide make a change, save it, but no change in file date/times. tried deleting .history thinking something jammed up from berlin, no luck. file date/times in my proj folder are updating as I change and save them. also made a new unit, saved it in \common -date/time is now waited a few minutes, changed and saved, no change in date/time now the strange part, had some troubles at the start of the port, so made a test project. same basic folder structure and that project seems to update file date/times just fine. and I should add, with the bump at the start of the port, I recreated the project file in D11, so project source and files should only be from D11. the only diff between test proj and actual is amount of units in the common folder, Test had about 7 Actual over 50 No forms, just units. Not causing me any issues, except for brief moment of confusion when backing things up, just strange. Thanks, sorry.. ~dave

lol, never mind.. had a pic in that folder.. windows changes the default date displayed.. 🙂

poking around, if I show the Date Modified, it looks correct. still strange thou..